When I look at the metadata for the PDF versions of the documentation,
it shows hundreds and hundreds of embedded fonts. Or more correctly, it
shows subsets of the same fonts embedded, in some cases, hundreds of
times over.
For example, open the 2.13.55 NR in Adobe Reader, and go to the Fonts
tab of the document properties. It takes about 15 or 20 seconds for
acroread to enumerate all the embedded fonts and fill the list box, and
if you scroll down you can see that some fonts, such as DejaVuSans and
Emmentaler, have subsets embedded many many times over.
If I open the one of the manuals in Acrobat (full version) and select
the Reduce File Size option from the Document menu, which consolidates
fonts, then when that eventually finishes - depending on file size, it
can take many hours to complete - I find that the size of the PDF file
has been reduced by 40-50%.
The number of duplicate font subsets has skyrocketed at some point
during the 2.13 development process. Every few subversions I make myself
a PDF portfolio of the PDF docs, and I normally run a Reduce File Size
on the individual PDF docs first, as that reduces the size of the
portfolio from ~50Mb to ~30Mb. This used to take around 20-30 minutes to
process all the English PDF docs, but it now takes about an hour for the
docs excluding the NR, and many hours for the NR alone, and nearly all
the processing time is spent in consolidating duplicate fonts.
Without knowing what mechanism is used for producing the PDF docs, I
wonder if *not* subsetting fonts would produce smaller documentation
files, as there would then be no need to include hundreds of different
subsets of the same font.
Nick
_______________________________________________
bug-lilypond mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
