Hi Craig, Thanks for your extensive study!
On 03/04/12 10:31, Craig Ringer wrote: > On 03/04/12 01:16, Vincent Hennebert wrote: > >>> From a quick look that sounds about right. Are you developing with a 1.7 >>> JDK? >>> You would have to make your code 1.5-compatible. Also, it would be good if >>> you could back your optimizations with profiling data. If code >>> safety/readability have to be compromised there has to be a good reason >>> for it. > > Yep, I'm on 1.7, but was building for a 1.5 target and source level. Careful, because that doesn’t ensure you that your code will run on a 1.5 JVM. You may still be using elements of the standard library that appeared only in 1.6+. <snip/> >> That said, please do feel free to give it a try if that route appeals to >> you. We would certainly consider a switch if it looks more promising in >> the long term. > > I'm wondering how practical it'd be to progressively adopt PDFBox, > actually, rather than doing an abrupt and total switch. > > The PDF primitives in PDFBox (COSName, COSNumber, COSDictionary, etc) > are modeled extremely similarlines as those in FOP's PDF library, and > while they won't be drop-in replacements they behave very similarly, > just with different method names and in some cases different datatype > assumptions (PDFName instead of String dictionary keys for example). The > only truly big difference looks to be in the handling of indirect > objects, where FOP uses one class that may be direct or indirect, and > PDFBox uses a dedicated `COSObject' class that wraps other objects for > indirect objects. Yep, I think we want to do the same in FOP. As a first step during our work on object streams, we had a chance to factorize into PDFDocument the outputting of obj/endobj for indirect objects. Before, there were ‘if (hasObjectNumber())’ statements spread all over the PDF classes. > If it proves possible to do a largely 1:1 substitution of PDFBox > primitive PDF classes for FOP ones that'd *greatly* simplify the job of > moving to using the PDFBox `PD' model for document output, and would let > the job be done in a couple of distinct and separate chunks. PDFFont, > PDFXObject, etc would build on top of the COS types like COSDictionary, > COSBase and COSObject, rather than on top of PDFObject, PDFDictionary, etc. I’m not too sure about this one? Even if you manage to convert the FOP higher-level PDF classes to use PDFBox primitives, what does that bring you? IIUC you would still have to make major changes to move to the PD model. <snip/> > If I get time (big if, at the moment) I'll see if I can have a play and > determine what kind of work is involved in doing this. Let us know how you’re getting on. > -- > Craig Ringer Thanks, Vincent
