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 Wed, 27 Oct 2004 11:36:44 GMT
Sean Wheller wrote:
> On Wednesday 27 October 2004 12:01, Nicola Ken Barozzi wrote:
>>It looks like a picture about how Forrest works today along with the
>>plugin system that is being developed.
> Yes, except most processing is done by external stylesheets.

This is the only difference between the way we currently do things, but 
I see a very big drawback - it breaks the (existing) skinning system.

You are doing the skinning in the plugin, so each plugin must have a set 
of stylesheets for skinning. I would be -1 for this unless you can 
devise a way of skinning all the plugins in one go without demanding 
that skin authors write code for every single plugin in existence 
(already we have 4 and that's just what I've done).

I already asked if the Docbook stylesheets are configurable enough to do 
this *and* maintain functionality like wholesite.pdf (which incidentally 
is another step *after* the intermediate format.

> 2. We can define consistant look and feel in the FO skin. As we get further we 
> will perhaps have to find an even easier method of maintaining a common cust 
> layer for all FO transformations, not just Docbook, and manage that in one 
> place.

Please explain how this would work.

> 4. Source can be managed under a Document Management System (DMS) and output 
> to Forrest in accordance with the "workflow" of the DMS.

Please expand (I've just bid on a contract that will use Forrest in such 
a way - I'm *very* interested in this particular comment)

> 1. The Docbook is heavy. It may not be well suited to "servlet."

One of the key reasons why it was not adopted in the first place.

> 2. The install download payload is large. We may have to provide the framework 
> and let users install the package sources on their own. Ideally we would 
> provide a script in the Docbook Plug-in install that will let the user define 
> the components for their "Tool Chain." Go get it for them or allow then to 
> specify locations of existing "Tool Chain." With Docbook this could be many 
> components including MathML, SVG extensions, Slides etc.

I never worry about such things at such an early stage - there are 
always ways around these things (as you suggest)


View raw message