Comments inline... On 15.11.2007 11:56:38 Vincent Hennebert wrote: <snip/> > > 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 AbstractPathOrientedRenderer. > - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
