xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burgess <john.burg...@riskdecisions.com>
Subject Re: compressing pdf response
Date Tue, 20 Sep 2005 11:00:53 GMT
We have a reporting tool here that produces the reports as pdfs.  It has 
always worked with internet explorer but not with firefox or mozilla 
until recently, with both of them giving the message "File does not 
start with %PDF".  Recent updates to mozilla and firefox have meant that 
  about 75% of the reports will now open in all browsers.  After seeing 
this thread I have just modified the compression filter we use to not 
compress servlets with a name ending in .pdf (we map the report 
producing servlet to getrep.pdf to make sure Internet Explorer realises 
that it is getting a pdf file - not all versions will honour the mime type).

Now all reports are correctly displayed in all browsers.  I've had a 
look at the gains we were getting with the compressed pdfs and it was 
only about 5% on average so removing compression is not going to be noticed.

In summary, it appears that firefox and mozilla do not fully support 
compressed pdfs.



Jan Pernica wrote:
> Anyway the browser does not display PDF correctly if it is compressed.
> 
> Regards
> 
> Jan
> Sonja Löhr wrote:
> 
>> 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: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>>
>>>   
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


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


Mime
View raw message