Hello, you might want to use a temp file first, and then, send the data to the client using a serialization trick in which you don't have to load the whole file in memory before serializing the object. I've attached a .java file which shows how to achieve that.
HTH, Regards, Julien 2010/9/6 Jeremias Maerki <[email protected]>: > With such an API, you probably don't have a choice but to use a single > byte array, unless you can send over ordered chunks..... > > On 02.09.2010 15:10:43 Eric Douglas wrote: >> I'm not sure. It's embedded code. I'm guessing they're using sockets. I'm >> just calling cloneAsClientObject. >> http://www.basis.com/onlinedocs/documentation/sysguimethods5/bbjapi_cloneasclientobject.htm >> >> >> -----Original Message----- >> From: Julien Aymé [mailto:[email protected]] >> Sent: Thursday, September 02, 2010 8:39 AM >> To: [email protected] >> Subject: Re: FOP Output Stream >> >> Hello, >> >> How do you send the generated output from the server to the client? >> If you're sending bytes through a Socket, then a SocketOutputStream is the >> best way (use Socket#getOutputStream). >> If you're saving the bytes into a temp file, then you could use a >> FileOutputStream. >> >> (Both of them must be wrapped in a BufferedOutputStream for better >> performances). >> >> HTH, >> >> Regards, >> Julien >> >> 2010/9/2 Eric Douglas <[email protected]>: >> > 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:[email protected]] >> > Sent: Thursday, September 02, 2010 7:13 AM >> > To: [email protected] >> > 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: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > > Jeremias Maerki > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
DeferedSerializableStream.java
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
