Hi Jeremias, Jeremias Maerki a écrit : > 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.
Ok, I stand corrected. The two different pdf packages (o.a.f.pdf and o.a.f.render.pdf) suddenly take all their sense to me ;-) (that said I’ve never really tried to understand the why and how). <snip/> > 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. Yeah, in an ideal world we would probably have a font package as a sub-project of XML Graphics and PDFBox as a top-level project depending on it. >> - 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. Sure, but it can be kept optional for those features that can’t be easily implemented in a one-pass approach. For example, IIC, FOP doesn’t produce linearized PDFs for incremental access from a network. Typically something that requires two passes (just like compilers use several intermediate steps before producing binaries). And here PDFBox might be of interest. >> 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. I agree, although I’m not sure to what conclusion that leads... XML Graphics sub-project or not? In fact the success of the incubation itself seems to be questionable. For once the problem is more technical than political! Vincent --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
