Re: compressing pdf response
Thanks to you all! If the improvement is so small I will unplug the filter. Although the browsers do support compression (the filter is checking this), the outcome seems to be somewhat unpredictable, and I don't know anything about the client side in production, of course. sonja Am Montag, den 19.09.2005, 21:48 +0200 schrieb J.Pietschmann: Sonja Löhr wrote: With IE (that is, acrobat inside) I get sometimes the pdf and sometimes a blank page, after reloading the message about a damaged file. Firefox (always) complains that the file doesn't begin with %PDF- (ok, indeed both speak German ;-) The browser explicitly asks if it will accept a compressed response. The server is *not* allowed to use compression (at the HTTP level) if the browser doesn't ask for it. Check your browser configuration. In Firefox, you might try the HTTP live headers extension for sniffing the actual values. Also, most of the PDF parts are already compressed (and re-encoded as ASCII85). A secondary compression will probably gain something between 15% and 20% for typical PDF files. Significant improvements are only to be expected in case of large embedded BMP images and in some cases if there are large embedded fonts. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sonja Löhr [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a way to stop the creation of a PDF when the user close the browser windows?
Hi I don't think so if backwards compatibility with IE 5 and older browsers is important. I don`t care about IE5 .. are you saying it's works with IE6 .. I remember having tried that without success ... /David I know when I generate an HTML report I get a java.net.SocketException when I close the browser window while the report is generated and send over the internet). Is there a way I can test if the socket is still open while I generate the report? Again, I don't think so. Until you write to the outputstream and the outputstream actually attempts to write to the underlying socket which may not happen until it flushes its buffers you won't know if the connection is still up. And if all this goes through a frontend like Apache who knows what happens as the servlet outputstream actually goes to the Apache connector and it is Apache who manages the connection to the client browser. For example in a servlet type environment you could connect the fop outputstream directly to the servlet outputstream. I worked this problem a while ago .. but your telling my I don't need to set the content length ?! My solution need to work with IE too ... Thanks for your help ! /David My recommendation - just catch the exception and do any cleanup required. Manuel Sorry, but it seems you are stuck with leaving it as it is know and just deal with the exception. snip/ - 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]
