xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: [DISCUSS] PDFBox proposal
Date Fri, 16 Nov 2007 10:17:31 GMT
Comments inline...

On 15.11.2007 11:56:38 Vincent Hennebert wrote:
> > Thoughts?
> A few. I lack a bit of skills in that whole area, but in the hope they 
> will be useful:
> - my understanding is that our PDF library is quite specialized for 
>   producing output from the area tree.

Not at all! The PDF library doesn't know a thing about the area tree.
The PDFRenderer is the adapter that translates the area tree into the
PDF library's object model. What your PDF library is specialized in is
producing new PDFs with a low memory profile and high speed. The PDF
library could easily be used by any other project that wants to create
PDF files. That's actually the reason why I still want to move our own
PDF library to XML Graphics Commons (besides making a clean dependency
tree between Batik and FOP).

>   In the end there is probably some 
>   common stuff that can be factored out of the several renderers 
>   (mainly: AFP, PostScript, PDF). I’m not sure PDFBox would integrate 
>   smoothly in that scheme.

Common stuff for the area tree is already factored out as far as
possible: AbstractRenderer, PrintRenderer and

> - to a certain extent there may be the same issue with fonts. Our needs 
>   go slightly further than just parsing PostScript/TrueType/OpenType 
>   fonts and embedding them in the output format. We also need to embed 
>   them in PostScript, or convert them into AWT, possibly AFP, etc. 
>   Ideally another sub-project dedicated to fonts, on which 
>   FOP/Batik/PDFBox would rely, would probably be necessary.

The embedding of fonts is usually output format specific and IMO doesn't
belong into a general font library. But otherwise, it's true a common
library for handling fonts is useful, which is why Victor created the
foray-font module and why Ben created the FontBox SF project. And I
simply need to move the font package out to Commons when I move the PDF
library so we can transfer the PDFTranscoder over to Batik.

> - that said, we would probably benefit from a general-purpose PDF 
>   library that would provide us with extra-functionalities like 
>   encryption (and tagged PDF?). It might make sense to keep our output 
>   library in a minimal form, and use PDFBox as a post-processor for 
>   optimizing the output or adding encryption or whatever.
>   You told about a PDF/A validator, but even a general PDF validator 
>   would perhaps be useful.

Hey, we have encryption, although not the strong stuff, yet. I don't
like the post-processing idea at all if it can be avoided.
Post-processing always means performance loss.

> I’m slightly doubtful it would make sense to have PDFBox as an XML 
> Graphics subproject, because it has both too many and not enough 
> features for our needs. Although it’s obvious that stuff can be shared 
> between the projects, and that one would have its place as 
> a sub-project. But PDFBox probably deserves to be a top-level one, all 
> the more if other Apache projects would also have a use of it. For us 
> that would be a dependency, like the other jars in the lib/ directory. 
> That said, had I to vote, that would probably be a +0.9.

I agree that PDFBox should become a TLP if possible. The problem could
be the same as with FOP/Batik: Established technology is not attracting
too many new developers. Most people look at this like a given. I fear
that PDFBox might not attract enough of a developer community. I see it
myself: We have a great PDF library which just basically lacks one
feature and that's why I/we should invest a lot of time merging two PDF
libraries into one? I don't know how this will work out.

> Hope that all makes sense,
> Vincent

Jeremias Maerki

Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message