On Saturday 16 March 2002 14:52, Peter B. West wrote:
>. . .
>The last stage of the FOP process translates one page
> description (the area tree) into another (the input to the target
> renderer.)


> So why would anyone want to interpose another translation step into
> this tightly coupled arrangement?  Who knows?  
>. . .
For page-based renderers where FOP has to compute the layout (like for 
PDF output), I don't see a need for another translation step either. 
IMHO asking "who knows" is usually a sign that a feature is not needed 
*at this stage of development*...

OTOH, for structure-based renderers like RTF and MIF, I think the only 
parts of FOP that are reusable are the first two stages: parsing and 
property resolution (apart from infrastructure like logging, config, 
etc. which might come from Avalon in the future?).

Last week we had a talk about using XML to communicate between FOP 
pipeline components, but for me this currently would only make sense 
between the "property resolver" and "structure renderers" components.

The deal is being able to reuse FOP's property resolution (p.res) in 
different contexts. I think the following usage scenarios could greatly 
benefit from reusing FOP's front-end (parser + p.res).

In the following I call "pr.fo" an XSL-FO document where all properties 
(fonts, sizes, etc.) are explicitely written, for example when 
inherited from parents:

a) XSL-FO to RTF conversion:
FOP parser -> FOP p.res -> pr.fo -> jfor converter

b) XSL-FO to MIF conversion
FOP parser -> FOP p.res -> pr.fo -> yet-to-write XML-to-MIF converter 

c) automated testing of first FOP stages
FOP parser -> FOP p.res -> pr.fo -> XML testing tool

Keeping in mind that RTF and MIF are formats where the page layout is 
left to the client software to compute (word processor or FrameMaker), 
keeping these converters independent of FOP instead of integrating them 
has several advantages:

b) Helps keep FOP focused on its main task: generating great PDF from 
XSL-FO documents

c) If FOP is ever rewritten in another language for performance, these 
converters, being much less compute-intensive, can stay in java and 
keep the same interface to the FOP components that they use

d) assuming I want to write a MIF converter, basing it on XSL-FO input 
instead of on a FOP API allows me to easily include MIF-specific 
constructs for applications where XSL-FO conformance is not needed but 
precise control of the generated MIF is (often a requirement for MIF 
when producing "half-finished" documents that are typographically 
reviewed before printing).

In conclusion, I think an interface based on XML documents (possibly 
this "pr.fo" discussed above) is the best choice to use between the FOP 
"property resolution" stage and the "structure renderers" like RTF and 
MIF renderers.

OTOH I agree that using XML between the layout and rendering stages 
doesn't make sense at this stage of FOP development.

Due to many other commitments, I don't have time right now (sorry, 
I know you're getting used to hear this) to implement this "pr.fo" 
interface, but if we agree on its usefulness I'll put this high on my 
list and hopefully give it a shot in the next few weeks...

 Bertrand Delacrétaz (codeconsult.ch, jfor.org)

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to