[tex-live] TeX and recent ghostscript changes

[Werner LEMBERG]

>  > 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.

  . We were recommended to have a look at `mupdf', which probably has
    the necessary tools already to remove duplicate fonts.  However, I
    don't know this code yet, so I can't tell whether it really works.

      https://mupdf.com/

> I can tell you more tomorrow if you are interested.

Yes, please!

>  > This refers mainly to bad names for subsetted fonts as produced
>  > by OpenOffice, IIRC.  In other words, you are barking the wrong
>  > tree.
>
> What's the problem?  If OpenOffice does not comply with the PDF
> specs, the worst thing Ghostscript can do is to provide a
> workaround.

Not sure about the details, but AFAIU OpenOffice produced subsetted
fonts that were different but had identical names.  This is not
forbidden, I believe (since the PDF object IDs are different), but
very inconvenient for post-processing tools.

>  > 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.


    Werner