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 21:24:10 GMT
Sean Wheller wrote:
> On Tuesday 26 October 2004 20:25, Ross Gardler wrote:

I've snipped an awful lot from this post as we seem to be digressing 
from the important point of how to build the Docbook plugin. If I 
snipped something that actually requires comment, please bring it back in.

> IMHO it is better to harness the power the community (I mean other projects) 
> than to do it ourselves.

I would agree with this wherever a communities goals are aligned with 
our own. Where they start to diverge we look at ways to build upon other 
communities work. You and I seem to have agreed that we can, at least in 
the first instance, utilise the Docbook generated XHTML. Now we are 
trying to find out if we can also utilise the other output formats or if 
we will need to move the XHTML1 output to our intermediate format before 
that can work.


>>This coupled with the problem above (you cannot output consistent PDF
>>documents with the skin I choose to use) means that, as I have always
>>maintained, bypassing the intermediate format will be a mistake.
> Perhaps. But customization of the look and feel is not a problem. We just need 
> to decide on a standard look. In XHTML it's CSS that does the work. In PDF 
> etc. its the xsl:fo. Once we have custom layers we can enjoy the power of 
> packaged transformations and focus on making them look the same.

I assume you are not prescribing a standard look for all users of 
Forrest? Each user needs to be able to define their own look using the 
skinning system.

We also have to be sure that things like wholesite.pdf still work as 

>>We have agreed that we should be able to skin the XHTML output
>>accordingly. However, have not, as yet, found a way of skinning the
>>other output formats in a manner that is consistent with a projects
>>chosen skin.
> It is possible. Anything is possible. Yet, if it was easy, everyone would be 
> doing it. If we do it then that would really make forrest outstanding. Don't 
> get me wrong. I think forrest is good. It could be great, that is why I am 
> here.
> I am looking into the other formats. I will return on this subject soon.

I look forward to your ideas on this.

> The difference between our thinking is that I don't believe the current 
> transformation system is:
> a) strong enough to support complex requirements.

use cases please (but please be sure to read the previous discussions on 
intermediate formats and understand why we are planning a move to a 
subset of XHTML2)

> b) easy to manage as requirements and standards change (thinking XSLT 2.0)
> c) an efficient use of development time.

I'm afraid I still do not understand how your proposal makes it easier 
to manage formats other than Docbook, and I still don't see how we get 
the integration of Docbook source materials with other source materials.

If you can provide a summary of exactly what you are proposing and 
illustrate exactly how it makes maintenance of *all* formats easier and 
more efficient it would be a great help.

>>In true open
>>source fashion, if you provide what you need, I will build on it to
>>provide what I need.
> Great!!! Hopefully you can contribute it back.

Of that you can be sure, that is why I am here.

>>>All in all, I think that the XHTML mech will also be good, as I see from
>>>other messages.
>>I disagree and the fact that you cannot produce all the relevant output
>>formats convinces me of the fact. 
> This is not a fact. We have not proven this. Those pipelines are powerful 
> things. We just need to join the pipes in the best manner.

True, poor wording on my part I should have said "the fact we have not 
found a solution yet", I eagerly await your ideas on a suitable solution.


View raw message