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- (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- (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 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]
