--- Comment #24 from Martin K <> 2011-06-16 22:32:37 
UTC ---
Add "Avoid overhead of creating writers":

By default, nearly each FO tag results in an PDF structure element [= object],
so there are lots of OutputStreamWriters created.

The trunk implementation with two objects (Writer+Stream) has the weak point,
that forgetting to flush the writer before using the stream can lead to
incorrect PDFs.

As OutputStream.write only supports bytes, any forgotten encode will result in
an syntax error => My solution will catch errors at compile time.

> I think the problem of encoding text into the output should be solved by 
> defining a specialized PDFOutputStream that would be able to stream both 
> String and bytes. That PDFOutputStream would be passed around to objects 
> that then wouldn’t have to handle their own wrapper or make calls to 
> encode. Does that make sense?

If the PDFOutputStream is persistent (eg, not recreated for each batch of
objects), it is an interesting idea.

The current code creates lots of CountingOutputStreams too, which would be
needed to be wrapped in a PDFOutputStream. To overcome this, the new
PDFOutputStream could count the total number of written bytes. Instead of using
a CountingOutputStream, the code can store the start number of written bytes
and use the difference to the end number of written bytes.

This is an optional enhancement, therefore I would currently like to
concentrate on the other patches.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to