If I'm not mistaken the r1302518 commit broke compile compatibility with
the Jeremias' PDF-image-plugin trunk which needs to be addressed. It's a
simple change if I'm not mistaken, just to do with how PDFDocument holds
it's version (was an int now an enum o.a.f.pdf.Version), there maybe some
other minor changes, but that one sticks out.

Anyway, I haven't checked it myself, but trust yourself and Pete did a good
job, +1 from me

Mehdi

On 21 March 2012 15:40, Vincent Hennebert <vhenneb...@gmail.com> wrote:

> Hi All,
>
> I’ve just uploaded our work on PDF object streams. If accessibility is
> enabled and PDF version 1.5 has been selected in the config file, then
> the structure tree will be stored in object streams. Support for
> cross-reference streams (a successor of the cross-reference table that
> appeared in 1.5) has been implemented in order to be able to address
> objects stored in object streams.
>
> The amount of space saved can be substantial, as much as 70% on
> a 20-page document.
>
> The changes are relatively localized and mostly affect the PDF packages.
> While there are significant refactorings, there is not a lot of new
> code. Therefore I’m inclined to handle this using lazy consensus; So if
> nobody objects within 72 hours, I’ll merge the branch back to trunk.
>
> Side note for those using the PDF Images plug-in: once the branch has
> been merged, the plug-in will have to be modified so that PDF objects do
> not output the obj/endobj wrapper themselves if they are indirect. This
> concerns the PDFBoolean and PDFString classes in
> o.a.f.render.pdf.pdfbox. Also, AbstractPDFStream now uses composition
> rather than inheritance for its dictionary, which requires changes to
> PDFBoxAdapter. Once the PDF Images plug-in has been moved under the
> umbrella of the XML Graphics project, we will upload the necessary
> changes.
>
> Thanks,
> Vincent
>

Reply via email to