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 Tue, 26 Oct 2004 12:54:20 GMT
Sean Wheller wrote:
> On Tuesday 26 October 2004 01:13, Ross Gardler wrote:
>>This could be made to work, but it does not deal with clashes between
>>class names in stylesheets. We could avoid these by prefacing forrest
>>classes with "forrest.", but we'll worry about that if it becomes a
> Yes, you're right it does not deal with clashes. I was also thinking about 
> pre-pending current classes though I thought that just "for" was enough, but 
> then I always try to make things shorter than they should be.

That would have to be handled in the skins, so we'll worry about that 
later. Lets sort everything else out first (looking at the sample you 
sent I don't think it will be an issue at first). Besides, as you see 
from my mail in response to Dave B (in this thread), I still intend to 
go to the internal Forrest format eventually, which could remove this 

>>So it seems that the major hurdles of handling XHTML are pretty much
>>covered (apart from all the stuff I've missed ;-))
>>My next problem with doing it this way is how do we generate other
>>output from the XHTML, i.e. PDF, RTF etc. I believe I raised this in
>>another message in this same thread so if you already answered no need
>>to answer again.
> In the case of Docbook, the transformation to PDF, RTF, PS is via XSL:FO. The 
> stylesheets for fo are already in the Docbook distribution and FOP is already 
> in Forrest. Again, use the FO from the Docbook stylesheets and pass it to 
> FOP. For now we will assume that we are transforming a complete book. Later 
> we will use functions already available in Docbook to transforms smaller 
> granularity. Let's keep it simple for now.

But there is a real problem with this. If I have a site with Docbook 
files and files will they both be formatted the same? 
This is very, very important as it is one of the goals of Forrest to 
have consistent output from various inputs. Just how configurable are 
these stylesheets?

> The other thing is to try use Saxon or Xalan, as this is forrest I think we 
> need to use Xerces and Xalan. My custom stylesheets call to extensions, these 
> extensions are also a part of the Docbook stylesheet distribution. I 
> especially call fop.extensions. There is much that FOP does not handle, this 
> extension helps to smooth life with a better output result and less errors 
> during transforms. IOW, it's faster.

Hmmm.... I'm not entirely sure we would want to go this way. Extensions 
cause a problem with tool independence, and I *think* Forrest wants to 
be tool independent. If we have to go this way we will need to ask this 
in another thread to ensure all devs see it.

> We will then come back to the XInclude problem, but this time I have a 
> solution. We will switch the Xerces XInclude mechanism ON and not rely on the 
> Cocoon patchy implimentation thereof.

Does that actually work? If so please submit a patch, I don't think 
there are any side-effects from this as long as it does not prevent 
CInclude from working.

> Let's get that far and then discuss 
> POD, WIKI, DVI, TXT, etc

We have to know the route we are taking will produce a fully functional 
plugin in the end. You are proposing bypassing much of the important 
parts of Forrest in order to achieve what *you* need to achieve, but it 
is important that we ensure it also achieves what other users want to 
achieve. There are already users who use the existing Docbook 
functionality, we cannot remove any existing functionality.

However, it is not all bad news. There is nothing to stop you working on 
an another Docbook plugin. As long as you call it something different 
from the one we have you can use your own and our existing users can use 

I have every intention of helping you get this plugin working, but I 
also have every intention of making sure it conforms to the way we do 
things here. As you know we are not stuck in our ways, we are flexible 
but any new solution needs to be better than the old, without those 
intermediate formats we are just making more work for future developers 
(see my mail and Dave B's mail in this thread about why we use an 
intermediate format).

Since we (Forrest) are going to a subset of XHTML2, and you are starting 
with XHTML1 the creation of our intermediate format in your plugin will 
(eventually) be a fairly easy thing to do (see Dave B's comments in this 
thread). I therefore propose that I create a Docbook plugin with the 
existing functionality (renamed "docbook-subset"), and you work on a 
brand new plugin called "docbook-full", in the docs we can make it clear 
that the docbook-full plugin does not provide all output formats. Once 
we have the XHTML1->intermediate format converters we can deprecate 
docbook-subset and rename docbook-full to docbook.


View raw message