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+.

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


>  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


Reply via email to