Re: Combine FOP PDFBox efforts?
Great, I will start updating PDFBox to use the FOrayFont, I believe this will go pretty smoothly because FOrayFont is already being used for PDF creation. More details on the FOray list. We have had some recent discussions about supported JRE's, from the main page of FOray[1] it says that 1.4 is used. There is a desire among the FOP developers to maintain compatibility with 1.3. Do you know if FOrayFont compatible with 1.3? Ben [1]http://foray.sourceforge.net/ Hi Ben, hi All, I finally have some time to chime in, sorry for the delay. Thank you for your interest in the font subsystem. My goal is to adapt the FOrayFont library to Fop. The main advantage of FOrayFont over the Fop code is its ability to directly parse font files, whereas currently with Fop there is a two-step process: first convert the font metrics into an xml file, then use it within Fop through a configuration file. You can have the process in [1]. I've submitted a first patch in december [2], that was refused because of unacceptable shortcomings of FOrayFont. The main reasons were: * lack of a default config file; * configuration too complicated. You will find all the details in [3]. Since that I'm working with Victor on FOrayFont's improvement. We have recently ended the design phase and have agreed on a set of changes that I still have to apply (you will find the discussion on the FOray-dev mailing list archive from the last two months. I'll add more on this on FOray-dev.). After that I believe that the main shortcomings will be corrected and that an updated patch can be submitted. PDFBox is pretty independant of my work. I currently rely entirely on the Fop PDF library for PDF outputs, and I'm only adapting necessary things to make it use FOrayFont. FOrayFont is a low-level library that tries to be independent of any output format, and thus may be used by whatever renderer. So if PDFBox were to be used by Fop, for me it would just mean that I would have to adapt PDFBox instead of the Fop library. For FontBox this is different, and I think there is a possibility to share resources in this area. I'll put more details on FOray-dev, but in short it would be great if we could achieve the following: * merge the best of FontBox and FOrayFont to obtain a good font library; * agree on a common interface (i.e., an API) for the font library, that would be used conjointly by Fop, PDFBox and FOray; * adapt PDFBox to make it use this resulting library; * make it work with Fop in some manner. I would like to work with you on the two first points. As you have probably already noticed the discussion will be mainly held in the FOray area. We will chime in here for Fop-specific things and to notify Fop devs of advancements of the adaptation work. I'm glad to see that there is place for collaboration. I'm sure that we will be able to achieve Great Things ;-) Cheers, Vincent Current way to configure fonts in Fop: [1] http://xmlgraphics.apache.org/fop/trunk/fonts.html Patch for the adaptation of FOrayFont to Fop (now outdated): [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=35948 Reasons of the patch refusal: [3] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop- dev/200512.mbox/browser Ben Litchfield a écrit : Jeremias, I'll start by answering your questions 1)What is minimum JDK required by PDFBox? PDFBox currently requires 1.4, because it uses ImageIO and a couple other things that make development much easier. PDFBox was compatible with 1.3 for a long time, but I made a decision that sticking with 1.3 would cost too much in development time versus using existing stuff in 1.4. In addition 1.3 is now two major versions old and in the EOL phase. As this effort will take some time before it could be released would it be reasonable to move the minimum requirement up to 1.4 for Batik and FOP at that time? 2)Does PDFBox require log4j? PDFBox used to be dependent on log4j, 0.7.2 has an optional dependency, the soon to be released 0.7.3 version will not use log4j at all. Currently PDFBox's only dependency is FontBox(see comments below), although bouncy castle will soon become an optional dependency for certificate based encryption and rhino(looks like Batik uses this as well) will also be an optional dependency for Javascript execution. Some additional comments, *After the 0.7.2 release, PDFBox split the font infrastructure into another project, so aptly named FontBox. No official version has been released yet but the project was created and all font parsing logic was separated from PDFBox. As far as I can tell there is no open source font library and for many of the same reasons we have discussed I thought it would be better as a separate project. It sounds like there has already been some discussion on making a separate font library
Re: Combine FOP PDFBox efforts?
Chris, I don't think FOP should step up to a minimum of 1.4. Just last week a user was saying on the user mailing list that needed FOP to run on JDK 1.2. You have valid concerns, I will revisit exactly what parts of PDFBox require 1.4. I suspect it is only small sections and potentially sections not required for FOP functionality. For example, converting a PDF to an image requires 1.4, but that is not functionality that would be used by FOP. It should not be too difficult to isolate these sections. My only other comment(and I am just ranting) on this issue is that staying compatible with 1.3 requires effort, which diverts effort from added features or fixing bugs. Staying on the bleeding edge also takes a lot of effort, but 1.4 has been around for over 4 years, we need to cutover at some point. As Jeremias already mentioned FORay Font is a standalone Font library that has evolved from FOP 0.20.5. I just joined the foray developer list and hope to start helping. I don't fully understand how the Foray font package is changing to support FOP, but that is off topic so I'll start a new discussion thread on that list. Ben
Re: Combine FOP PDFBox efforts?
is still working with Victor Mote (of FOray) to improve FOrayFont and to prepare its integration/use in FOP so we profit from additional functionality. I think it would be important to make sure that the PDF library and the font subsystem remain as independant of each other as possible, i.e. it may be necessary to have multiple subclasses of basic PDF model objects to interface with the various font sources. * Switching to on an externally managed library means giving away a certain amount of control and freedom. Changes may need more energy and time. But moving the PDF library from FOP to XML Graphics Commons will already mean a step in this direction. Two projects will depend on it which means more coordination. * Adopting PDFBox into the ASF is certainly an option if the people involved in PDFBox really want that. A full PDF library with parsing and rendering support might go beyond the XML Graphics' project boundaries, however. It might need to go into a separate project. And that would certainly be a big step which would need a lot of energy. * Talking about energy: Resources in FOP and Batik are still sparse. Switching the PDF library is a rather big task and would need investment from both XML Graphics and PDFBox sides. It might produce diversion from other tasks. Could we get that together? I may be a little pessimistic, but I doubt it at this time. Just look at the font stuff. Vincent currently has to play lone rider at the moment because I simply don't have the time to even closely track what's going on. And noone else seems to have time or motivation to jump in. * An idea: We could simply start an experiment and create a copy of our PDFRenderer in the sandbox which is converted to use PDFBox as PDF backend. If it evolves enough, we can switch the main implementation one day, i.e. just let evolution decide. * Integrating PDFBox would be cool because it would allow inserting arbitrary existing PDF pages or using preproduced PDF pages as page backgrounds, stamps, watermarks, external-graphic objects. * There's probably more to add here, but my head's starting to pound again Questions: - What's the minimal JDK version for PDFBox? FOP and Batik need to remain JDK 1.3.1 compatible for the time being. - I've seen something about Log4J. I hope this is an optional dependency. Is it? One task during the migration of FOP's PDF library to XML Graphics Commons is to remove the dependency on JCL. That was a wish coming from Batik. I assume the same would apply to any other PDF library we'd use. On 09.03.2006 21:43:22 Ben Litchfield wrote: Hello all, I am the main developer of PDFBox, an open source(BSD) PDF library. FOP contains PDF library functionality(specifically classes in org.apache.fop.pdf.*) and PDFBox is a PDF library. Because they do very similar things they contain a lot of overlapping code, but the pdf package in FOP has some features that PDFBox does not and PDFBox has some features that the FOP pdf package does not. I propose that classes in FOP's package be 'merged' into the PDFBox library and FOP utilize PDFBox for PDF functionality. I think we should do this for a variety of reasons; -PDFBox FOP benefit by gaining functionality -PDFBox FOP benefit by having a larger user base, which means code is used more, tested more, contributed to more -The entire community benefits by having higher quality PDF components available -There are several projects that currently take FOP output and perform post processing with PDFBox, this could be optimized if FOP used PDFBox as its core -Future core PDF development efforts will no longer be duplicated between these two projects I wanted to gauge interest from FOP developers and start to think about how we can make this work. What do you guys think? Ben Litchfield http://www.pdfbox.org/ Jeremias Maerki
Re: Combine FOP PDFBox efforts?
Hi Christian, Currently I am the only developer that works consistently on PDFBox, other developers contribute occasionally. I just meant to introduce myself as I assume you would not know who I am. I was proposing that PDFBox would remain on SourceForge, but I am open to other possibilities. As far as I can tell that would not need to change, is there a reason it should? Ben Ben Litchfield schrieb: Hello all, Hi Ben, I am the main developer of PDFBox, an open source(BSD) PDF library. How many other developers are working on PDFBox? [..] I propose that classes in FOP's package be 'merged' into the PDFBox library and FOP utilize PDFBox for PDF functionality. Are you proposing to do this on SourceForge or here at the ASF? -- Christian
Combine FOP PDFBox efforts?
Hello all, I am the main developer of PDFBox, an open source(BSD) PDF library. FOP contains PDF library functionality(specifically classes in org.apache.fop.pdf.*) and PDFBox is a PDF library. Because they do very similar things they contain a lot of overlapping code, but the pdf package in FOP has some features that PDFBox does not and PDFBox has some features that the FOP pdf package does not. I propose that classes in FOP's package be 'merged' into the PDFBox library and FOP utilize PDFBox for PDF functionality. I think we should do this for a variety of reasons; -PDFBox FOP benefit by gaining functionality -PDFBox FOP benefit by having a larger user base, which means code is used more, tested more, contributed to more -The entire community benefits by having higher quality PDF components available -There are several projects that currently take FOP output and perform post processing with PDFBox, this could be optimized if FOP used PDFBox as its core -Future core PDF development efforts will no longer be duplicated between these two projects I wanted to gauge interest from FOP developers and start to think about how we can make this work. What do you guys think? Ben Litchfield http://www.pdfbox.org/
Re: Combine FOP PDFBox efforts?
Hi Clay, I am glad to hear this sounds like a possibility. PDFBox is currently licensed under the BSD license. I did not initially envision a change in licensing, but I am open to possibilities if necessary. Is there a reason it would need to change? It is my understanding that Apache projects can utilize projects that are BSD licensed. Is it possible for the existing FOP pdf classes to become part of PDFBox under the BSD license? Ben Clay Leeds wrote: On Mar 9, 2006, at 12:43 PM, Ben Litchfield wrote: Hello all, I am the main developer of PDFBox, an open source(BSD) PDF library. FOP contains PDF library functionality(specifically classes in org.apache.fop.pdf.*) and PDFBox is a PDF library. Because they do very similar things they contain a lot of overlapping code, but the pdf package in FOP has some features that PDFBox does not and PDFBox has some features that the FOP pdf package does not. I propose that classes in FOP's package be 'merged' into the PDFBox library and FOP utilize PDFBox for PDF functionality. snip Ben Litchfield http://www.pdfbox.org/ Thank you for your interest, Ben. Although I don't speak for everyone, it does look intriguing to me. You may want to clarify how you envision PDFBox will be licensed (would this be a software license grant[1]?). I don't know the details on the BSD license. Also, I assume you would provide a software license grant and fill out a CLA[2]. [1] http://www.apache.org/licenses/#grants [2] http://www.apache.org/licenses/#clas Clay Leeds [EMAIL PROTECTED] My religion is simple. My religion is kindness. -- HH Dalai Lama of Tibet
