Nicola, 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 renderer. 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 page. 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. Peter 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 >want?). > >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]
