Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 58157 invoked from network); 25 Oct 2004 14:53:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 25 Oct 2004 14:53:54 -0000 Received: (qmail 53630 invoked by uid 500); 25 Oct 2004 14:53:52 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 53586 invoked by uid 500); 25 Oct 2004 14:53:52 -0000 Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@forrest.apache.org Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 53573 invoked by uid 99); 25 Oct 2004 14:53:52 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [212.23.3.142] (HELO rutherford.zen.co.uk) (212.23.3.142) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 25 Oct 2004 07:53:52 -0700 Received: from [82.69.78.226] (helo=[192.168.0.2]) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1CM6EH-0008Jb-CB for dev@forrest.apache.org; Mon, 25 Oct 2004 14:53:49 +0000 Message-ID: <417D137C.4030406@apache.org> Date: Mon, 25 Oct 2004 15:53:48 +0100 From: Ross Gardler User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@forrest.apache.org Subject: Re: Docbook as forrest-plugin References: <200410242043.28765.sean@inwords.co.za> <417C60BD.5070504@apache.org> <200410250906.20353.sean@inwords.co.za> <417CEC80.9020601@apache.org> <1098710319.417cfd2f28856@secure.solidusdesign.com> In-Reply-To: <1098710319.417cfd2f28856@secure.solidusdesign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Rutherford-IP: [82.69.78.226] X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Dave Brondsema wrote: > Quoting Ross Gardler : > > >>Sean Wheller wrote: >> >>>On Monday 25 October 2004 04:11, Ross Gardler wrote: >>> >>> >>>>How would Forrest be able to skin these files if it does not conform to >>>>the internal structure of Forrest. All we could do would be to embed the >>>>output XHTML, we would lose all skinning features. Since the whole point >>>>of Forrest is to produce consistent output from various input formats >>>>wouldn't this method prevent Forrest from achieving it's goals? >>> >>> >>>I don't believe so. We need to devise a way to skin any output that >> >>originates >> >>>from the transformations provided by another framework. >> >> >> >>>CSS can do the formatting under forrest skinned site, as it does today. >> >>Again, >> >>>most projects already have CSS, so it's just a case of "cascading" to >> >>include >> >>>the framework specific CSS for formatting of the body. A forrest plugin >> >>would >> >>>therefore extended forrest core to provide the configurations and >>>customizations required in order that output from a base framework may be >>>piped into forrest. >>> >>>When XSL's don't exist for the base frameworks the plugin will provide >> >>XSL's. >> >>>Does anyone think this can work? >> >>In the past I have looked at the Docbook XSL and decided it is way to >>big and too complex to try and integrate into the skins since many >>people would not be using it. However, life would be much easier now >>with the ability to extend CSS through skinconf.xml and the plugin >>architecture. >> >>At present there is no way of a plugin adding information to a skin. I >>suspect that you would need to be able to do this in order to provide >>full Docbook support. I think I know how we could do it, I'll look at it >>with you if/when you reach this point. >> >>Ross >> > > > Do you mean skinconf values per-plugin? Yes > See FOR-144 (including the discussion linked from there) about a new skinconf > format. I think for output format plugins to work best, we will need to > implement that first. > > Making this change will also require a backwards compatibility translator, and > modifying our current skins to use the new skinconf names/values. Ahhh yes, I vaguely remember getting lost in the middle of that thread. I suspect this is why I wrote "I *think* ... I'll look at it with you if/when...". My subconcious must have been telling me there was something not right about what I was planning. I agree this needs resolving. So, Sean, can you provide a simple sample output from a typical Docbook tranformed into XHTML using the stylesheets. This will help me understand if the problems I envision are really there or not (unrecognised CSS styles that the skins must be extended in order to handle). Ross