Web optimised PDF

From Scribus Wiki
Revision as of 22:39, 30 January 2006 by Mhanski (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

My wife edits a newsletter that is mostly distributed via e-mail and the web (but some volume is also printed black-and-white at an inexpensive print shop). After her Windoze machine died and she could no longer use PageMaker and Distiller, I convinced her to use Scribus on Linux, and apart from her occasionally cursing myself for this, things works fine (she likes the CVS version of Scribus much better than 1.2).

Being sent out via e-mail, the newsletter must be below ~ 1 MB, desirably even smaller. Since the Scribus options for minimizing the size (subsetting fonts and downsampling images) did not meet that requirement (I'd need to try again to give figures), I looked for a route to PostScript and back to PDF that would give better compression, and the following does a surprisingly good job:

 1. Export as PDF, embedding all fonts, no font subsetting, no image subsampling
    --> newsletter_scribus.pdf [~2.8 MB]
 2. Convert to PS using `pdftops -level3' (Acroread 7's PS export will not work'Bold text')
    --> newsletter.ps [huge]
 3. Convert back to PDF using ghostscript (subsetting fonts, subsampling
    images; this must be ghostscript 8.x or later)
    --> newsletter_compact.pdf [~500 kB]

As you see, the resulting PDF is more than 5 times smaller.

And now for the mysterious part: The new PDF file is not only smaller, but it is `nicer' (for on-screen reading) in three aspects:

(i) In Acroread 7 (the buggy one, I don't have any other around for

 comparing) on Linux, the text appears not to be antialiased for the old
 PDF, but is perfectly so for the new one.
 Xpdf shows both fine (and identical as far as I can tell).
 Gv/ghostscript hangs while antialiasing the old file, but shows the new
 file fine.

(ii) Text marking and searching in the old file works not too well in

 Acroread (with lots of gaps in marked text), and practically not at all
 in Xpdf. It works perfect for the new file in both applications.

(iii) The picture is shown far too dark in Acroread for the old file, but

 fine for the new file. Xpdf once again shows identical results for both.


You can see Acroread's output of both files at

 http://www.capca.ucalgary.ca/~wdobler/tmp/Scribus/

Can anybody explain this to me? I attach some vague ideas, but I find this behaviour really striking.

 Point (i) could be the switched-off font hinting in Scribus' PDF that
   was mentioned before. But how on Earth can pdftohtml + gs reconstruct
   the hinting information?
 Point (ii) sounds like it is caused by Scribus placing separate
   characters into the PDF, rather than whole words -- and gs
   reassembling the words very efficiently.
 Point (iii) could have to do with the fact (I am quoting out of my head)
   that Acroread never touches the CMYK values, while other viewers apply
   colour profiles (or such).

Any rebuttal/confirmation of these thoughts and further enlightenment are welcome.



PS: If anybody is willing to run the resulting file through a PDF checker, you

   can try the latest newsletter at
     http://www.calgarymulticulturalcentre.com/CC_January_2006.pdf