I think there are a few issues to be considered here.  Essentially, what 
is FOP?

There may be a number of requirements of an XSL-FO processor.  The basic 
one is, "Show me this on a page or screen."  Any kind of renderer, using 
any approach whatsoever, will achieve this, more or less.  The so-called 
"structure renderers", like the rtf and mif renderers, do this with a 
useful side-effect; the file they produce can be not only viewed, but 
edited.  It seems to me that what you are proposing is to use iText as a 
basic "structure renderer," mapping the fo structures into 
iText-compatible structures.

With all of the structure renderers, however, you are at the mercy of 
the individual layout engines.  Anyone who has tried to produce a 
complex document using two versions of MS-Word will have an acute 
understanding of what it means to be at the mercy of someone else's 

The spec itself defines a layout engine in the production of the area 
tree from the fo tree.  Admittedly, there are a number of grey areas in 
layout, especially when constraints conflict, in which the final 
decision is up to the User Agent.  Effectively, it's up to the 
implementation.  The area tree, though, defines the position of every 
mark on every page.  It inherently holds out the prospect of producing 
identical layouts from every renderer downstream of the area tree.

I was initially skeptical about this, because of the dependency of the 
layout on the font characteristics.  It was pointed out to me, though, 
that as long as a renderer honoured the metrics of the design font then, 
even if individual glyphs were considerably different, the *layout* 
would still be identical down ot the position of individual glyphs on a 

It seems to me that that is what a full implementation of the spec 
implies, and that such a search for consistency in the position of marks 
on page or screen is one of the most desirable features of the spec. 
 What may not be achievable across different implementations, we may 
still seek to achieve within a single implementation.

With that in mind, we can probably conclude that a true structure 
renderer cannot achieve this cross-renderer consistency.  That wouls 
also be true of iText, used in such a way.  If however, the interface to 
iText were defined such that the position and size of al marks to be put 
on the page could be rigorously determined, it could meet the 
requirement.  I, for one, would like to see such a precise and 
relatively low-level pdf library.


Nicola Ken Barozzi wrote:

>Given what has been said on the mailing lists of FOP and iText, and given
>the current scope of the two projects, I feel reasonably sure that this
>could be a proposal accepted by bot communities.
> FOP uses iText as a PDF generation library
>This could have greater benefits than a merger and keep intact the strenghts
>that these two projects have (remember AOL+Time Warner? is the result we
>iText could continue to be an excellent PDF (and RTF AFAIK) generation
>package with a good java API.
>FOP could concentrate on FO2AreaTree and use iText as the last step.
>Given the licences, nobody is prohibited to cross-collaborate. iText
>developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>when the time is right.
>FOP can distribute iText jar as it's MPL, and both projects would cross-link
>in a clear way.
>AFAIK iText is already able to produce PDF using an XML file. If FOP could
>make a transformation step from FO to this format, we could get this up
>running in a short time.
>And IText can also output to html, which is not bad at all.

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

Reply via email to