Hi,

We have a process which generates 3,000 2-page PDF documents. They have embedded fonts (and we don't enable subsetting). Each comes out to about .5MB, which admittedly is large but understandable, given 5 embedded fonts.

Then we "spool" (concatenate using pdftk) those into a few PDF files of 500 items (1000 pages) each, and run an optimizer (pdfoptimize from pdf-tools.com), which removes redundant fonts, graphics, etc. and brings the file size down from 250 MB to 2.5 MB -- a fantastic 100x optimization, resulting an average 2.5KB per original PDF file.

When we upgraded from 6.0r3 to 6.0r5, we found that (good:) our formerly .5MB PDFs were now down to .1MB (a 4x improvement), but (bad:) when we then concatenate and optimize those, our 1000 page files which formerly optimized down to 2.5MB, are now coming out at 30MB -- more than 10x worse than we formerly achieved.

Is 6.0r5 somehow encoding fonts differently in such a way that pdfoptimize can no longer optimize them? If it is, is the bug with prince, or with pdfoptimize?

-c

This is because we have added support for font subsetting, but we are perhaps insufficiently identifying the resulting font subsets, so that they appear to be unrelated and it is not possible for the PDF optimiser to combine them into a single font. We can probably fix this in Prince, but in the meantime the easiest workaround would be for you to disable font subsetting with the --no-subset-fonts option to get back the old behaviour.

In Prince 7.0 font subsets are now correctly labeled as such, which would hopefully avoid this issue.