Hi there

A little heads up: As I've announced I did some refactoring on the PDF
library. As life goes it got pretty extensive. I've cleaned a lot of
stuff, more centralized und uniform behaviour, improved logging
(PDFDocument makes the logger available to all child objects) etc. I
also hope that my changes are somewhat preparatory for the "parse PDF"

The refactoring allows me now to easily implement on-the-fly stream
encoding. That means the stream doesn't have to be encoded from a
StreamCache (byte buffer) to another byte buffer. That was previously
necessary to calculate the length of the encoded stream. This value was
included in the object's dictionary (/Length). By using an indirect
object (4.10 in the PDF 1.3 specs) I can encode the raw stream on-the-fly
using a chain of FilteredOutputStreams to the PDF file. The length is
later added as a separate PDFNumber object.

I quickly tested the new runtime behaviour and I got from 4350KB down to
2277KB (Total memory used as calculated in the LayoutHandler) on a 1.1MB,
two-page PDF (image-intensive). Time used went up from average 2.5sec to
3.1sec, but when I used a BufferedOutputStream it was around 2.4sec.
(Disclaimer: I didn't account for JVM warm-up! It was just a quick test.)

Theoretically, it would now also be possible to pipe a (JPEG image)
stream right through FOP without having to buffer the raw stream in
memory or in a temp file. But doing that is not on my todo list right

I still need to tackle the last few methods. Then it's testing time. And
when I'm done that'll be a rather big commit.

Jeremias Maerki

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to