lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by


From: Knut Petersen
Subject: Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by address@hidden)
Date: Thu, 15 Jan 2015 16:05:58 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 15.01.2015 14:47, address@hidden wrote:
On 2015/01/15 13:18:46, Knut_Petersen_t-online.de wrote:
On 15.01.2015 13:15, mailto:address@hidden wrote:
> On 2015/01/15 12:01:55, Knut_Petersen_t-online.de wrote:
>
>> Ghostscript does the font merging.
>
> Any idea whether something could be done to make PDFTeX do the font
> merging instead when including all the PDF files?

No, not really. That would require a lot of work.

Judging from the documentation, that should be the default (namely, when
\pdfinclusioncopyfonts is at its default value of 0 and we are talking
about Type1 fonts).  Cf
<URL:http://tex.stackexchange.com/questions/136574/merging-duplicate-embedded-fonts#138726>
for example.  So the question is what is keeping this from happening.
Maybe we need to call ps2pdf (when converting the fragments for
inclusion) with some particular options to keep the fonts in a mergeable

Current lilypond uses glyphshow to draw glyphs in postscript,
encoding vectors are not present.

As there is no direct equivalent of the postscript glyphshow operator
in the pdf language, ghostscript constructs a _new_ font with an
encoding vector, including only the subset of glyphs used in the document.
Ghostscript then uses the glyphs in that font indexed by the new encoding
vector. The name of that new font is derived from the original.

It's pretty unlikely that two lilypond scores use the exactly same
subset of glyphs in exactly the same order, so it's pretty likely that
the two new fonts are not identical. But they share (aside from the
prefix) their name.

pdflatex would need to inspect all glyphs in those fonts, detect which are
identical and construct up to three fonts (remember the size limit of
encoding vectors and the number of emmentaler glyphs) with encodings
from the fonts found in the lilypond pdfs. It then would need to recode
the data stream and everything would be fine.

Identical fonts could be expected to be merged by default and without
problems (my interpretation of the pdftex documentation is different).
But without --bigpdfs you do not have identical fonts in the lilypond
pdfs, even if you instruct ghostscript not to subset fonts. It ignores that
order because it cannot obey.

cu,
 Knut






reply via email to

[Prev in Thread] Current Thread [Next in Thread]