Re: Ghostscript/GhostPDL 9.22 Release Candidate 1

[Werner LEMBERG]

> In general, however, my experience of working with large documents
> is that the content should be maintained in the layout application
> native format until the last moment.  Broadly speaking this is
> similar to keeping bitmap data in something like TIFF and only
> converting to JPEG at the last moment, and for similar reasons.

This is next to impossible.  lilypond has knowledge for good music
typography, while TeX has knowledge for good text typography.  I read
your suggestion that lilypond should do everything, i.e., both text
and music layout, but this won't happen, for obvious reasons.

In other words, we have to co-operate with TeX somehow – output from
lilypond must be included into TeX documents.

> Your problem with multiple fonts pretty much exhibits that; once
> you've got the PDF file, a layout engine can't tell that all the
> fonts are the same.  Ghostscript can't either, which is why it now
> doesn't strip the duplicates out.

But our pipeline *guarantees* that the fonts are identical (basically
by disabling font subsetting)!  This is something we can completely
control, and for such a use-case we would like to have forthcoming
versions of ghostscript be able to do what it did previously.

> Assuming that you are using TeX throughout for your documentation,
> then it seems to me that you should be creating your final document
> by appending the various TeX documents together and then producing a
> final PDF, instead of appending multiple PDF files.

As mentioned above, lilypond doesn't produce TeX output (it did so
many, many years ago, but this was abandoned for various reasons).  It
natively produces EPS, which gets converted to PDF using gs.  However,
the modern TeX flavours we need produce PDF only, and can only include
PDF files easily.  However, its font handling capabilities are not
sophisticated enough to produce small output files.  Thus the second
pass with ghostscript.


    Werner