which document2fo.xsl, pdf-output plugin

[Johannes Schaefer <jo...@uidesign.de>]

Hi!

I recently got confused about which document2fo.xsl file
is beeing used (in order of precedence, I believe):
* My local copy in the skins directory (if present)
* The one below main/webapp/skins/<skinname>
* The one below main/webapp/skins/common
   (which normally gets included from <skinname>)
* The non-existent one in plugins/...pdf-output/resources

Then I asked myself
* Why does the pdf-output belong to a (HTML) skin?
* Wouldn't it be nice to have separate HTML, PDF, ... skins?

Finally: How do skins and output-plugins interact?
I see that the pdf-output simply gives a pipeline from
fo to pdf. So,
* Output plugins do not need to work directly from
   forrest-document format?
* Does fo generation then belong to forrest core?
* What happens if we add the other FOP targets
   (postscript, RTF, SVG, PCL, ...)?

A lot of questions pretty early?!
Thanks for any clarifications!

Johannnes


-- 
User Interface Design GmbH * Teinacher Str. 38 * D-71634 
Ludwigsburg
Fon +49 (0)7141 377 000 * Fax  +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * 
Lehrer-Götz-Weg 11 * D-81825 München
www.uidesign.de

Buch "User Interface Tuning" von Joachim Machate & Michael 
Burmester
www.user-interface-tuning.de

Besuchen Sie uns auf der Hannover Messe 11.-15. April 2005
Halle 2, Stand C14 auf dem MMI Gemeinschaftsstand
www.uidesign.de/hmi2005

Nächstes TAE-Seminar zu User Interface Design
Ostfildern-Nellingen, 07.-08. April 2005
www.tae.de TAE-Veranstaltung Nr. 31189

Re: which document2fo.xsl, pdf-output plugin

[Ross Gardler <rg...@apache.org>]

Johannes Schaefer wrote:
> Hi!
> 
> I recently got confused about which document2fo.xsl file
> is beeing used (in order of precedence, I believe):
> * My local copy in the skins directory (if present)
> * The one below main/webapp/skins/<skinname>

Yes

> * The one below main/webapp/skins/common
>   (which normally gets included from <skinname>)

It will only use this one if included from one of the other two.

> * The non-existent one in plugins/...pdf-output/resources

No, it never looks here. At the moment all final presentation logic is 
in skins. Thorsten is working on forrest:views which will allow us to 
move it out into plugins.

> 
> Then I asked myself
> * Why does the pdf-output belong to a (HTML) skin?
> * Wouldn't it be nice to have separate HTML, PDF, ... skins?

Skins are not HTML only they are presentation of any kind. This may 
change in 0.8 with Thorstens work on forrest:views (nee fbits).

> Finally: How do skins and output-plugins interact?

They don't (or shouldn't).

The intended behaviour is that output plugins provide the content to be 
skinned, this is passed back to core which then handles the final skinning.

However, this gets a little confused with the current skinning system 
because in some cases (such as PDF) the final skinned output is sent 
back to an output plugin for serialisation.

This is wrong (see below).

It is a hack forced by our current skinning system. Enter Thorsten with 
forrest:views which moving all the skinning into a new type of plugin - 
search archives for fbits and forrest:views.

(Thorsten you will be pleased to know that Johannes question has made 
the penny drop - I now understand why you think skins are bad, or at 
least I understand one reason why they are bad).

> I see that the pdf-output simply gives a pipeline from
> fo to pdf. So,
> * Output plugins do not need to work directly from
>   forrest-document format?

Yes they do, everything in Forrest works with the intermediate format. 
If we start messing with this then we will remove all the power that is 
Forrest.

It is possible to create plugins that do not work with the intermediate 
format but I would be -1 on Forrest hosting these and I would argue 
against them being included in our plugins.xml file (not sure how I 
would vote, I'd want to hear the arguments first).

Of course, what I just said contradicts the current PDF situation. Funny 
how you live and learn isn't it? Thank goodness I knew Thorsten would 
come up with forrest:views ;-)

> * Does fo generation then belong to forrest core?

No. It has always been my intention to remove the fo stuff to its own 
plugin. Plugins can chain and will do so automatically as long as your 
matchers are carefully written. I just haven't had the time and noone 
else has got the itch yet.

Are you itching? Feel free to scratch ;-)


 > * What happens if we add the other FOP targets
 >   (postscript, RTF, SVG, PCL, ...)?

See the RTF-output plugin (which unfortunately has a few bugs in it and 
doesn't work with a huge number of documents). This may help illustrate 
why we need separate plugins. The RTF plugin has an extra library, the 
idea of plugins is that we can strip out all the optional libraries from 
core and put them in plugins. This makes core much more lightweight.

> A lot of questions pretty early?!

Yes, but this morning I have my first brew in-hand and baby didn't get 
me up in the night, so I think I coped OK. Man it is hard working from 
home with a baby in the house - but a great stress reliever too :-))

Ross