From: "Peter B. West" <[EMAIL PROTECTED]> > Nicola, > > I think there are a few issues to be considered here. Essentially, what > is FOP?
Good point. > 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. As a start, yes. > 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. I think the POI team (http://jakarta.apache.org/poi/) would have something to say about this, but it would not be appreciation for the MS file formats ;-) > 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. This implies AFAIK that the creation of the area tree is the crucial point, the pivotal scope of FOP. > 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. Yes. > With that in mind, we can probably conclude that a true structure > renderer cannot achieve this cross-renderer consistency. And this is taken in account for in the spec as you know, which defines many tags as optional and hints on how to downgrade gracefully. > That would > 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. In the proposal, the hint to active collaboration is there to achieve this synergy. Itext can give FOP a boost in rendering, and the FOP community can give iText greater precision in rendering. The iText community has shown IMO sincere quest for an active collaboration, and even donation of the code to FOP. As both communities pointed out correctly, just merging two project usually doesn't make a bigger project, but a bigger mess. So it seems that this thing can start :-) There is no need for a VOTE, since plain discussion and sharing of views is free, of course. Although I'm subscribed to this mailing list for quite some time now, I didn't really understand the status of the works that are going on to get to FOP2 or whatever you are going to call it. AFAIK, changing codebase requires a notice of this, a branch in CVS (no vote is necessary), and a final VOTE if the codebase is to switch. This is how Tomcat, Xalan, Xerces and many other projects did it, and how the priject guidelines advise. (http://xml.apache.org/source.html) What's the current status? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
