xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Douglas" <edoug...@blockhouse.com>
Subject FOP Output Stream
Date Thu, 02 Sep 2010 12:23:48 GMT
So, a BufferedOutputStream is better if you're going to produce output on the same machine,
or is there a better way of doing what I'm doing?

I use a ByteArrayOutputStream because I am running the program on the server.  That's where
I generate my XML input and where I do the transform.  Then I need to copy the output to the
client PC (running embedded code in webstart) because that's where I do all the output.
I currently don't have the printers set up on the server, we use client printers.  I prefer
to create the PDF directly on the client rather than save it to the server then copy it down.
 Of course the print preview, using the FOP PreviewPanel, must be run on the client.
I don't see any method in BufferedOutputStream to get the bytes, and it doesn't appear to
be serializable, so a ByteArrayOutputStream seemed the best logical output.

-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch] 
Sent: Thursday, September 02, 2010 7:13 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: fonts URL resolution

> Le 01/09/2010 17:55, Eric Douglas a écrit :
> > I don't know about a simple solution but there is a workaround.
> > I solved this or a related issue by not using the setFontBaseURL method.
> > I use the Renderer.setFontList method instead to manually load in 
> > the custom font(s).
> > Is there a point to using a BufferedOutputStream?  I use a 
> > ByteArrayOutputStream, so I have the output in bytes so I can copy 
> > it from server to client.

Yes. A ByteArrayOutputStream buffers the whole stream in memory which can cause problems if
you deal with bigger documents. A BufferedOutputStream allows maximum performance with only
minimal memory consumption. It will even be faster than the ByteArrayOutputStream because
at least the Sun implementation reallocates bigger and bigger chunks of memory and has to
copy the whole content of the old buffer over to the new one. At least the implementation
I wrote for Apache Commons IO doesn't do the copying but only allocates additional buffers.
Still, the memory problem remains.

Jeremias Maerki

To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message