xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hennebert <vincent.henneb...@anyware-tech.com>
Subject Re: [DISCUSS] PDFBox proposal
Date Sun, 18 Nov 2007 13:07:19 GMT
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).

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


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