Apache OpenOffice (AOO) Bugzilla – Issue 19567
Text output in PDF should be optimized for fewer PDF code
Last modified: 2007-10-23 14:48:37 UTC
There are 3 levels of optimisation for PDF export, Screen, Print, or Press. At least in RC3 Print optimisation produces a larger file (marginally) than Press optimisation. Either there is a bug, or one of the options is redundant which could save some space in the binaries.
cp->phb7: please provide a bugdoc.
Created attachment 9388 [details] OOo Writer File (.sxw) that demonstrates the issue
Test file just uploaded (PDF Test{1}.sxw) produces the following PDF oupput: Screen optimised = 124,413 bytes Print Optimised = 1,085,999 bytes Press optimised = 1,085,578 bytes Regards Peter HB
NB. I've upgraded to rc4 since reporting the bug. Results are the same. Regards Peter HB
there is no difference for b&w images. the difference between press and print is mainly in the quality of jpeg compression for color images. philipp can tell you more about it after he's back from vacation. I don't see an issue in having 0,04% difference in file size
The lack of significant difference in file size between Print and Press is the issue! My objective in raising it was to point out the redundant nature of having 2 options that offered no significant difference in the result. Maybe it's a generational thing, but when I started programming (some time before Pontius became a pilot) wasting memory on redundant code was viewed with dis-favour and I merely thought a similar attitude would be prevalent in the OpenOffice.org development environment. Regards Peter HB
The difference between screen/print/press optimized generation is merely the "artificial" resolution of the resulting PDF. I say "artificial" because PDF in itself is a vector format and does not have a resolution per se. But the applications (writer, impress, ...) calculate with integer coordinates which are more fine grained for higher resolutions. This should in theory make a difference only for images which are rastered according to the resolution (of course only if the original image is of higher resolution than the target). But actually if the resolution is higher the applications tend to typeset text more fine grained, too: essentially the higher the resolution, the more they begin to position single characters instead of whole words. But positioning a single character involves coordinates for each one which takes much more space than positioning once and then printing a word. Obviously this has an upper boundary when each glyph is positioned separately, which in many cases is already met at the "print" resolution level, hence the "press" and "print" optimized files do not differ much in size. So currently i think everything "works as designed" as the PDF is supposed to look like the original document in a WYSIWYG fashion. What can be said is that the PDF file size in general is too large; we're working on making that smaller.
Many thanks for the comprehensive response. It is appreciated and I'll not darken your door further on this issue! Incidentally, I've no complaints about the file size. Ghostscript and pdfwrite generate roughly the same size of file. Regards Peter HB
We'll address this issue with the redesign of PDF UI for 2.0; there will be separate control fields concerning text and image quality.
according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later.
Since we have no print or press optimization anymore i change the summary to reflect what should be done.
For information, OOo 1.9.87 generates pdf files approximately twice as large as the same file exported from OOo 1.1.4 (Print optimised). The file(s) in question contain a small amount of text (c. 10 lines) and a single JPEG graphic that was pre-optimised. Output from 1.9.87 was left at the default 90% image quality. If this is of interest and I can offer any assistance, please ask. Peter HB
*** Issue 66532 has been marked as a duplicate of this issue. ***
fixing issue 74609 brings a new implementation for text output in PDF which should also result in smaller files.
The difference mentioned since the 1.9 versions is that Graphics are not so much compressed per fefault anymore for better results (default is nowadays a jpeg quality setting of 90% where it was 80% at "press" setting in 1.1). For text we can now create up to ~30% smaller PDF code; however in a normal document you will not notice this much since graphics and embedded fonts comprise a much larger part of the PDF docuement then the actual text information itself. The drop in size is most noticeable in documents that use the PDF builtin fonts only (Times, Helvetica and Courier). The attached sample document's PDF export however shrinks less than a percent with the new code since almost all of the size is used up by fonts and graphics. But the fonts we cannot do much about whereas the graphics are a user setting (just the default setting changed from 1.1 to 2.0 for better image quality).
please verify in CWS glyphadv
Verified with cws glyphadv = ok
Still ok in 680m208_9137
*** Issue 25733 has been marked as a duplicate of this issue. ***