[tex-live] TeX and recent ghostscript changes

Reinhard Kotucha reinhard.kotucha at web.de
Mon Sep 25 01:52:06 CEST 2017

On 2017-09-22 at 06:47:56 +0200, Werner LEMBERG wrote:

 > >  > This is not what we (the lilypond team) are after.  We need
 > >  > proper merging of non-subsetted fonts.
 > >
 > > I must admit that I had not lilypond in mind in the first place.
 > > But if the fonts are not subsetted and you are willing/able to
 > > add a program to the lilypond distribution which can [de]compress
 > > PDF files (qpdf, pdftk), I'm sure that you can write a script
 > > which solves the problem without much effort.  I'm quite
 > > optimistic because I already repaired a broken PDF file created
 > > by InDesign manually.
 > Yes, we will actively investigate this route since ghostscript
 > seems to have another bug in the current git version that prevents
 > our `trick' to work correctly even if we restored the removed
 > option.
 > Two potential solutions come to my mind.
 >   . PŽter Szab—'s `pdfsizeopt' tool.
 >       https://github.com/pts/pdfsizeopt.git
 >     He recently invested a lot of energy to improve it (it can
 >     finally compress the lilypond reference manual :-) Ð maybe we
 >     can directly use it, without the intermediate ghostscript step.

Hi Werner,
sorry for the late response.  I wasn't aware that pdfsizeopt is still
maintained and am very glad to hear that PŽter is still working on it.
It's also great that he considers to try to remove dependencies to
other programs.  The old version I'm still using works only with

 > > I can tell you more tomorrow if you are interested.
 > Yes, please!

Let me explain the problem I had to solve first.  I used LuaTeX in
order to plot electrocardiograms.  Here is an example:


A colleague used InDesign in order to create a poster for an
exhibition.  She included the file mentioned above but clipped it so
that only the curves but no text was visible.

InDesign correctly noticed that none of the glyphs were visible and
tried to be smart.  There are two possible solutions:

 1. remove the font completely and any references to it,

 2. create a subset of the font with does not contain any glyphs but
    provide a valid font header.

InDesign introduced a new, much smarter, "solution":

    create a reference to an empty object supposed to contain a valid

PDF readers complained loudly, of course, and no printing office would
accept such a file.

I decompressed the file with qpdf, copied the font into the empty font
object, and then ran pdftk in order to create a PDF file with an
updated xref table.  At this point I had a valid PDF file.

Finally I pushed the file through Ghostscript.  GS removed the object
containing the unused font and the reference[s] to this object.  The
resulting file was smaller than the file created by InDesign, so I
suppose that some other optimizations were done by GS.

As far as lilypond is concerned, the first step is to determine which
fonts are identical.  Your script can extract the fonts and create
checksums of the objects containing fonts.

If you notice that one and the same font is used more than once, make
sure that only the first one is referenced.  Means: change the object
number of the link so that it points to the first instance of a font
rather than to the current one.  The current instance of the font is
inaccessible if it's not referenced anymore but dangling objects will
be removed by Ghostscript anyway.

If you intend to post-process files, avoid object stream compression
(use PDF-1.4 instead of PDF-1.5) if possible.  If object stream
compression is used, you need an external program in order to make the
PDF file suitable to be processed by general purpose programming

I don't know how lilypond creates PDF files and why there are many
instances of the same font in the output files.  I always thought
that lilypond creates PostScript code.  Could you describe the
workflow briefly?

Could you make a PDF file produced by lilypond, containing duplicate
fonts, available to me somehow?

 > >  > The concept of /UniqueID was abandoned many years ago already
 > >  > by Adobe, for good reasons.
 > >
 > > What are these "good reasons"?
 > To make this work really reliably, you have to register all unique
 > IDs (or the corresponding foundries) at a central place, something
 > which doesn't fit the reality since many years.

The concept would be more successful with a /VendorID, which is
maintaned at a central place, and a /FontID, which is maintained by
the foundries, instead of maintainig a /UniqueID for every font at a
central place.  I suppose that Adobe preferred to maintain /UniqueIDs
for every font in order to know what the competitors are doing.
Before Bitstream cracked Type 1 encryption, Adobe believed do be the
only company which can provide Type 1 fonts with proper hinting.

The main reason Adobe abandoned /UniqueIDs is that they are not
interested in Type 1 fonts anymore.


Reinhard Kotucha                            Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                    mailto:reinhard.kotucha at web.de

More information about the tex-live mailing list