Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On 2002.03.14 09:00 Nicola Ken Barozzi wrote: What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. IMHO, the best way to get this thing going *quick* is to use Cocoon as a pipeline. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. Firstly the Area Tree is unavoidable. We must have a place to do the layout and to store the page information. If you want this area tree turned into sax events, it really seems like an unecessary step but there is an xml renderer (admittedly simply writes text at the moment but you get the idea) if you want to add this extra step. The FO Tree - Layout - Area Tree are the three core issues. This is what needs to be done first. For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
From: [EMAIL PROTECTED] Nicola Ken Barozzi wrote: 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. Advance warning: I didn't follow possible discussions on the iText list regarding this issue. IF the integration FOP-iText is done in a way where PDF output via iText is not just an option but a replacement for the existing PDF output - or even for the other renderers, too, then I'd say this step contradicts the intention though not the letters of the Apache license. This is a strong opinoin. Remember that the Apache license is a *license*, not the community. Apache values the community, and the license is there to help the community. Why? If FOP - under Apache license - can no longer be used for essential purposes without using an additional component (iText) under MPL or LGPL, then in effect FOP is no longer Apache licensed, though technically speaking it still is. ? This boils down to a question: what is FOP? From http://xml.apache.org/fop/: FOP is the world's first print formatter driven by XSL formatting objects and the world's first *output independent* formatter. Currently FOP is not totally output indipendent, in the sense that it doesn't even output without going through a FOP renderer. The goals of the Apache XML FOP Project are to deliver an XSL FO-PDF formatter that is compliant to at least the Basic conformance level described in the W3C Recommendation from 15 October 2001, and that complies with the 11 March 1999 Portable Document Format Specification (Version 1.3) from Adobe Systems. FOP is currently two things: -formatter -renderer Nobody has ever thought to ditch the current FOP renderers. It would be illogical. The proposal is to focus on the formatting part, that is somethind that no other project does AFAIK, and make the rendering accessible to other projects, like iText, jFor and POI. Fop renderers would be just another possibility, and now there are no alternatives I see for PCL, for example. This way different working groups could focus indipendently on different parts. Separation of concerns can help keep working groups more focused and productive. This would reduce the usefulness of FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). I fail to see how this reduces usefulness. My personal favourite would be a FOP renderer implementation that makes use of iText. Then, time could tell whether there are enough people interested in keeping Apache-licensed PDF output alive. Basically, this is the idea :-) I remember that iText has already proposed to be put in the FOP codebase, thus gaining Apache license. But several reasons advise us to be cautious and defer it for now. It's not codebases that would merge, but communities, and we have to avoid stalling while in the process. If the decision goes toward a full replacement, I'd say that at least all existing FOP committers and possibly the major contributors to FOP should agree to this step as it - in one respect - decreases the value of their work so far. IMO, it's the opposite. This can give FOP another opportunity, not make it go back. -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:00, Nicola Ken Barozzi wrote: . . . 1. FopParser parses and validates the input XSL-FO document Not needed if using Cocoon as a pipeline. . . . Right, but it's so easy that we might as well keep it for easier testing. . . . What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. . . . Yes, but IMHO resolving (in the sense of resolving FO object properties like I think is meant by FOP) is part of the core functionality. I'm talking about computing presentation attributes for child elements based on their parent's attributes. . . . This can big opportunity also for other projects to collaborate in the rendering. JFor, for example (I don't remember who maintains it ;-P) . . That's me by the way ;-) (but I haven't done much lately) -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
From: Keiron Liddle [EMAIL PROTECTED] On 2002.03.14 09:00 Nicola Ken Barozzi wrote: What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. IMHO, the best way to get this thing going *quick* is to use Cocoon as a pipeline. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. Firstly the Area Tree is unavoidable. We must have a place to do the layout and to store the page information. Right. And flush it ASAP, as FOP already tries to do now to some degree. If you want this area tree turned into sax events, it really seems like an unecessary step but there is an xml renderer (admittedly simply writes text at the moment but you get the idea) if you want to add this extra step. I think that a SAXrenderer could be the solution. SAX is based on calling a method when a tag begin-content-end is reached. It can be used to communicate the Area Tree to the renderer in a clean way, whith a standard interface. To make a renderer use by FOP in this way, you just need to say:We give you this xml area tree that conforms to this schema via SAX. Render it. No knowledge of FOP internals is needed. The FO Tree - Layout - Area Tree are the three core issues. This is what needs to be done first. Can't agree more :-) For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. Hmmm... AFAIK FO is about layout, not semantical structure. Bold is just Bold, and not emphasis or strong. Maybe I don't get the point. Could you elaborate more please? Thank you. -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:19, Keiron Liddle wrote: . . . Firstly the Area Tree is unavoidable. We must have a place to do the layout and to store the page information. . . . Unavoidable for Layout rendering, isn't it? I thought structure-based rendering wouldn't need the area tree. . . . For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. . . . How hard would it be to render the FOTree in XSL-FO (based on SAX events) with all possible attributes resolved? Speaking specifically about the jfor RTF converter, this would allow it to be used as a FOP renderer without needing as much code changes as an API-based integration. Might be a little slower but much more flexible. This would allow the parser and property resolver (is that the right term?) components of FOP to be reused by jfor and future structure-based renderers. -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: . . . Hmmm... AFAIK FO is about layout, not semantical structure. Bold is just Bold, and not emphasis or strong. Maybe I don't get the point. Could you elaborate more please? . . . The term structure renderer (as you could find by searching the list archive probably ;-) is used here for yet-to-be renderers that don't do any layout by themselves. If you're generating RTF or MIF formats, for example, you usually don't need to know on which page a given FO element will go, you leave this to the word processor or desktop publishing program that will use the generated document. So these renderers will be plugged in right after the parsing and property resolution stages, before the layout stage. -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: . . . I think that a SAXrenderer could be the solution. SAX is based on calling a method when a tag begin-content-end is reached. It can be used to communicate the Area Tree to the renderer in a clean way, whith a standard interface. . . . Won't work I think, print-based layout (as opposed to structure-based) requires two-way communication between the layout engine and the renderer (to compute the width text runs, for example). -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)
Nicola Ken Barozzi wrote: IF the integration FOP-iText is done in a way where PDF output via iText is not just an option but a replacement for the existing PDF output - or even for the other renderers, too, then I'd say this step contradicts the intention though not the letters of the Apache license. This is a strong opinoin. Remember that the Apache license is a *license*, not the community. Apache values the community, and the license is there to help the community. Yes, I agree to all of this (including the strong opinion). Still, I think you underrate the importance of the license. In marketing terms: what is it that makes Apache and GNU a brand, while SourceFourge is not widely seen as a brand. I think it's the license. If I take something from the Apache projects, I know - because of the Apache license - that I can do most everything with it as long as I mention the origin in an appropriate way. This makes its very simple to use Apache projects in commercial projects in medium-size and large companies. Basically it boils down to this: If I want to use open-source components in a customer project, I can use Apache-licensed stuff with no problems. MPL, LGPL and GPL licensed components give me so many headaches when used in commercial customer projects that I no longer even try to use them (with the exception of internal-use-only projects). I just want to design and implement software, not fuss with legal departments, you know... 8-) Warning: Strong opinion follows The Apache project just would not be the same if it adopted the MPL, LGPL or GPL. Also, a number of contributors would quit in that case. If this is true, the Apache license is still a *license* but not *only a license*. In a sense, the license defines what persons the community consists of. FULL STOP Philosopical issues aside, if the integration/collaboration is planned as you say, then most points of my original mail become moot. Remember, my mail started with an uppercase IF. The discussion here on fop-dev showed that it was NOT clear that PDF via iText would only be an option, not a replacement. And one more thing - I recite your citation: The goals of the Apache XML FOP Project are to deliver an XSL FO-PDF formatter that is compliant to at least the Basic conformance level described in the W3C Recommendation from 15 October 2001, and that complies with the 11 March 1999 Portable Document Format Specification (Version 1.3) from Adobe Systems. From this, it's clear that as soon as FOP no longer outputs PDF by itself, but using a non-Apache-licensed component, then it not longer fulfills the original goal. This may be good: it makes a lot of sense to separate formatter and renderer if the abstraction layer is done well (this won't be an easy task, I'm pretty sure of that). Technically, it's very tempting to do what you propose. In fact, technically, I'm all for it. Let's just be aware that the license problem is not only a philosophical issue. There is a real reason why there are different types of licenses. And as for this: This would reduce the usefulness of FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). I fail to see how this reduces usefulness. If n persons are using FOP now and some of these can no longer use FOP because a part of FOP they need has a license they can't use, then I'd say this reduces FOPs usefulness for these some persons, despite being more useful to others. Arnd Beissner -- Arnd Beißner IT-Engineering Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
From: [EMAIL PROTECTED] Technically, it's very tempting to do what you propose. In fact, technically, I'm all for it. Let's just be aware that the license problem is not only a philosophical issue. Of course. I think we agree. And as for this: This would reduce the usefulness of FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). I fail to see how this reduces usefulness. If n persons are using FOP now and some of these can no longer use FOP because a part of FOP they need has a license they can't use, then I'd say this reduces FOPs usefulness for these some persons, despite being more useful to others. Apache is very clear in the licencing terms. *GPL libraries cannot be distributed by Apache. So this rules them out. The iText developer are maing it possible now to redistribute the jar with the MPL license only. AFAIK, MPL is compatible with APL. Which means that the MPL -jar- can be used in *every* condition in which APL -code- or -jars- are used. Who cannot use MPL jars in APL code? Maybe I'm wrong, but I cannot come up with an example. -- 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]
RE: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
If n persons are using FOP now and some of these can no longer use FOP because a part of FOP they need has a license they can't use, then I'd say this reduces FOPs usefulness for these "some" persons, despite being more useful to others. Arnd Beissner --Arnd Beißner IT-EngineeringBahnhofstr. 3, 71063 Sindelfingen, GermanyEmail: [EMAIL PROTECTED]Phone: +49-7031-463458Mobile: +49-173-3016917 My company, for instance, would have to stop usingFOP; we would not even take the time to go into studying legal aspects, because, as a medium-sized company, we don't have the time and money and personnel to do this... Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
From: Matthias Fischer My company, for instance, would have to stop using FOP; we would not even take the time to go into studying legal aspects, because, as a medium-sized company, we don't have the time and money and personnel to do this... I think you are exaggerating a bit. Are you using Apache license software? And did you study it with this scrutiny? If you are using the Apache license and are confortable with it, then there is no problem. If Apache can distribute it with APL code, you can do the same. It's simple as that. Apache admits only compatible licenses in the CVS for this reason; some weeks ago there has been a check in the CVS to check this, and you can be sure that there is zero tolerance on this issue, it is applied very strictly. Look at the descriptions on the main apache site and on Jakarta; there are very important pages IMO that explain as clearly as possible the position Apache has on this point. -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Keiron Liddle wrote: On 2002.03.14 09:00 Nicola Ken Barozzi wrote: What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. IMHO, the best way to get this thing going *quick* is to use Cocoon as a pipeline. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. Firstly the Area Tree is unavoidable. Hear, hear. We must have a place to do the layout and to store the page information. If you want this area tree turned into sax events, it really seems like an unecessary step but there is an xml renderer (admittedly simply writes text at the moment but you get the idea) if you want to add this extra step. Agree strongly. At various times the notion of flattening the area tree has been wrestled with in these pages. At some point the tree model of pages loses all relevance. Trees are very useful to describe the structure of the stuff being squirted onto the page. At the end of the day, though, the stuff is rendered as a series of marks on a flat surface, and, to the renderer of last resort, all of the data structures that generated the marks are irrelevant. I am utterly ignorant of any particular page description languages, so imagine such a language that provides for the drawing of certain sorts of marks on the page at certain co-ordinates. That, essentially, is the output of the area tree. If you want to express that page definition language in xml, go right ahead. Xml output would indeed be loosely coupled. It's a data stream. SAX events are about as loosely coupled as tree roots. It's an API, after all, and an API which is inimical to pipelining processes. However, if you want to be able to feed the area tree into various renderers, you have to use some sort of PDL to transcribe the area tree, and the description is linear set of random access instructions, whether expressed in an xml file or an API. The FO Tree - Layout - Area Tree are the three core issues. This is what needs to be done first. Yes. For the FOTree to structure document it is a different issue, that I hope we will solve one day. Maybe sax events could be used here. My own approach is an API-based pipeline. As you say, these three, FO Tree - Layout (Tree?) - Area Tree, are the tightly coupled core issues. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Bertrand, Aside from my low opinion of SAX for process coupling, there should be no need for communication back from the renderer. The Area Tree should just give orders to the renderer. All of the layout decisions have been made by the time the Area Tree is constructed. The feedback is within the layout process, and the particulars of that are the cause of much wailing and gnashing of teeth. Peter Bertrand Delacretaz wrote: On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote: . . . I think that a SAXrenderer could be the solution. SAX is based on calling a method when a tag begin-content-end is reached. It can be used to communicate the Area Tree to the renderer in a clean way, whith a standard interface. . . . Won't work I think, print-based layout (as opposed to structure-based) requires two-way communication between the layout engine and the renderer (to compute the width text runs, for example). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Hi Peter, Aside from my low opinion of SAX for process coupling, there should be no need for communication back from the renderer. . . . cool - I thought the Area Tree code needed to know about font metrics and the like, but if this communication is one-way all the better. Regarding SAX events, I really meant that for structure renderers. What I envision (in the context of RTF rendering through jfor) is the possibility of using the FOP front-end only to resolve XSL-FO properties, like an XSL-FO preprocessor if you want. That's for this preprocessor-to-StructureRenderer interface that I think using XML makes sense, for loose coupling of the StructureRenderers which would then not necessarily be part of the FOP code base. If we agree that XML is good for this, I think generating this XML through SAX events allows the preprocessor component to be efficiently integrated in Cocoon (for example) later on, without having to serialize and reparse the XML. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
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. What do you think? Shall we pull this off? -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
I'm wondering if marying FOP +iText would sacrifice the -awt -print -ps options. (Same question for -text, but i'm personally not interested in that.) At 10:58 AM 3/13/02, you 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. What do you think? Shall we pull this off? -- 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] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)
Nicola Ken Barozzi wrote: 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. Advance warning: I didn't follow possible discussions on the iText list regarding this issue. IF the integration FOP-iText is done in a way where PDF output via iText is not just an option but a replacement for the existing PDF output - or even for the other renderers, too, then I'd say this step contradicts the intention though not the letters of the Apache license. Why? If FOP - under Apache license - can no longer be used for essential purposes without using an additional component (iText) under MPL or LGPL, then in effect FOP is no longer Apache licensed, though technically speaking it still is. This would reduce the usefulness of FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). My personal favourite would be a FOP renderer implementation that makes use of iText. Then, time could tell whether there are enough people interested in keeping Apache-licensed PDF output alive. If the decision goes toward a full replacement, I'd say that at least all existing FOP committers and possibly the major contributors to FOP should agree to this step as it - in one respect - decreases the value of their work so far. Arnd Beissner -- Arnd Beißner IT-Engineering Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: mergingtwo libraries)
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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote: . . . - FOP uses iText as a PDF generation library - . . . Maybe the following scenario could help making FOP more pipeline-oriented, making it easier to plug in various renderers, layout engines, debugging tools, etc. I'm just making up component names, hopefully understandable 1. FopParser parses and validates the input XSL-FO document 2. FopPropertyResolver does its job, attributes inheritance, etc. Then two options: 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout and produces PDF 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the XSL-FO vocabulary but with all attributes explicity specified (as far as possible, I know there are some issues here). After 3b, various XSLT transforms and/or XML-to-something converters can be plugged in using the well-defined and loosely-coupled SAX/XML interface. I think using XML/SAX to interface between future pipeline components (ParsingAndPropertyResolving - Layout - Serialization) opens up much more options than using java APIs for this, and could help keep FOP small and focused. If using Cocoon, being able to just resolve properties and pass the result on to various transforms opens up new horizons for XSL-FO processing. At the other end of the pipeline, what about an XML-to-MIF converter, for example, much more generally useful than a tightly-coupled MIF renderer for FOP. Implementing 3b should be fairly easy (isn't that a serialization of the FOTree?), and we can go from here to reuse important parts of FOP as individual components. How does this sound? -- 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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
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]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
From: Bertrand Delacretaz [EMAIL PROTECTED] On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote: . . . - FOP uses iText as a PDF generation library - . . . Maybe the following scenario could help making FOP more pipeline-oriented, making it easier to plug in various renderers, layout engines, debugging tools, etc. I'm just making up component names, hopefully understandable 1. FopParser parses and validates the input XSL-FO document Not needed if using Cocoon as a pipeline. 2. FopPropertyResolver does its job, attributes inheritance, etc. Then two options: 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout and produces PDF 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the XSL-FO vocabulary but with all attributes explicity specified (as far as possible, I know there are some issues here). 3b After 3b, various XSLT transforms and/or XML-to-something converters can be plugged in using the well-defined and loosely-coupled SAX/XML interface. I think using XML/SAX to interface between future pipeline components (ParsingAndPropertyResolving - Layout - Serialization) opens up much more options than using java APIs for this, and could help keep FOP small and focused. If using Cocoon, being able to just resolve properties and pass the result on to various transforms opens up new horizons for XSL-FO processing. This is the proposal I made, and I think it stands even stronger now. If FOP is pipeline driven, any renderer can be quite easily plugged in. AFAIK, the pipeline architecture is one of the major design differences that in some way has been agreed on. What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. IMHO, the best way to get this thing going *quick* is to use Cocoon as a pipeline. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. At the other end of the pipeline, what about an XML-to-MIF converter, for example, much more generally useful than a tightly-coupled MIF renderer for FOP. Implementing 3b should be fairly easy (isn't that a serialization of the FOTree?), and we can go from here to reuse important parts of FOP as individual components. I agree. This can big opportunity also for other projects to collaborate in the rendering. JFor, for example (I don't remember who maintains it ;-P) And POI. At POI, we are going to do a Word .doc format writer. It could fit easily in this picture. -- 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]
