forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <>
Subject Re: Docbook as forrest-plugin
Date Tue, 26 Oct 2004 14:58:34 GMT
On Tuesday 26 October 2004 14:54, Ross Gardler wrote:
> > 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?

Oooops, nope. I don't think the Docbook XSL's will work on the OO files.
They are modular and configurable. You can overide and custom any template. 
But I think the difference between OO and Docbook XML structure is a big one.

> > 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.

Can't see why. This is a "Docbook Plugin" for Forrest. It does not impact 
directly on forrest. The extensions are java and proven to work with xerces, 
xalan, and fop. All are Apache.

> > 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.

Hey. It will work in the plugin. :-) The file sample I sent you is made from 5 
first level xi:includes each with X number of subnested xi:includes. What 
forrest gets from the Docbook plugin is what I sent you. So there is no need 
for forrest to expand &entities; or xi:include. In PDF that is over 1400 A4 
or Letter sized pages.

> > 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
> ours.
> 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.

I don't think it is a problem. Either way. The current solution is stunted. As 
I said before, it's a partial support for a standard. People can continue to 
use this option, or they can move to the plug-in. In addition, I see no 
reason why the Docbook Plug-in cannot be extended to include stylesheets for 
other formats. At first I would add existing packages like docbook2latex, and 

I think that once a docbook2pod is developed, it can be moved out to where development thereof will be accelerated. The same for 
any other format.

I *think*, I don't say for sure, you may find that the docbook community (a 
large one) will put support behind it. I also *think* that the Docbook 
plug-in will increase the usage of Forrest by other Open projects, in turn 
increasing the number of developers who may contribute to the project.

All in all, I think that the XHTML mech will also be good, as I see from other 

Sean Wheller
Technical Author

View raw message