forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Docbook as forrest-plugin
Date Mon, 25 Oct 2004 16:48:20 GMT
Sean Wheller wrote:
> On Monday 25 October 2004 16:53, Ross Gardler wrote:
>>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
> Sent in message off-list.

Wow, that was a huge example, glad you sent it off list.

I've glanced through and, as expected, it is pretty good code. There are 
only a couple of things that would get in the way of our skinning and 
they are trivial, in the vast majority of cases they will not cause a 
problem (if ever), e.g.:

<ul type="disc" compact="compact">

<table border="0" width="100%" cellspacing="0" cellpadding="0"
                                     class="blockquote" summary="Block 

<td width="80%" valign="top">

<td align="left">S20acct</td>

So, what needs to be done is the plugin needs to be able to add CSS 
classes into a skin. If there are no name clashes between current 
forrest skins and the Docbook XSLT generated code then I have a 
suggestion, however, I have not considered the issue  in this response, as I'm 
still getting my head around it, but others, more familiar with that 
issue may want to speak up, nor am I particular familiar with the way 
XSL is used to generate the skins at present - so please consider this a 
set of random thoughts to elicit comments.

We cannot use the  <extra-css> element of skinconf.xml as this would 
require the plugin to modify a file in the project. Besides we would 
still want the skinconf.xml to override the formatting provided by the skin.

The options I see are:

1) plugins only output Forrests intermediate format
2) style definitions can be embedded in the body-html document
3) plugins can provide an extension.css for each skin it supports
4) skins can provide an extension.css for each plugin it supports
5) a combination of 3 and 4

Option 1 is what we have been doing successfully until now. However, as 
Sean points out it is forcing us to duplicate some work done by other 
projects (in this case Docbook to XHTML stylesheets, same is true of 
Open documents)

Option 2 is the hack solution I have in the 
plugin, it is not a pretty solution, but it does work.

Option 3 and 4 both have the effect of splitting the skin definition 
across multiple locations. In the case of option 3 it is the plugin that 
takes responsibility for ensuring skins are supported, in option 4 it is 
the skin that is responsible for supporting the plugin.

Option 5 allows the maximum flexibility but also the maximum confusion 
(what takes priority skin or plugin?)

Regardless of which option is taken, skinconf.xml settings should 
override the default settings (not possible with option 2).


View raw message