[Top][All Lists]

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

Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300

From: Werner LEMBERG
Subject: Re: Replace `-dgs-load-fonts' to `--bigpdfs' in lilypond-book (issue 300280043 by address@hidden)
Date: Fri, 22 Jul 2016 17:16:04 +0200 (CEST)

About a month ago we discussed how to reduce the disk space necessary
for builing the lilypond documentation.

> [...]  Since lilypond itself converts all fonts to PostScript
> resources, why not writing those resources to a `fontresource'
> directory instead of embedding?  We could add a checksum to the
> resource name, just to be sure that, say, `foo.tff' and `foo.otf'
> will be rejected.
> Ideally, all intermediate PDFs also refer to this `fontresource'
> directory, and only in the last step PDFs with subsetted, embedded
> fonts are created.

Such an approach has now been discussed on the the pdftex mailing
list, cf.

and the following e-mails in this thread.

I've just tested successfully the following method, except itemĀ 1,
which I've executed manually.

1. Instead of embedding font resources into the file, lilypond writes
   them to a font resource directory and uses the `.loadfont' operator
   in its PS output file.  For simplicity, the font resources should
   have the PS font name as its file name (regardless of the font
   format), e.g. `TeXGyraSchola-Regular'; we then don't need a font
   map for ghostscript.

2. Lilypond's PS files are converted to PDFs with the additional gs
   option `-dEmbedAllFonts=false' (to be added to `postscript->PDF' in
   file `backend-library.scm').

3. Both xetex and pdftex accept the fontless PDFs without complaints;
   they simply embed them into its output file without alterations,

4. After the output PDF is built, a call to

     ps2pdf -I<fontresourcedir> \
            -dNOSAFER -P \
            Fontless.pdf WithEmbeddedFonts.pdf

   creates the final document.

Comparing the `--bigpdfs' method with the fontless PDF approach as
outlined above, the latter creates a final output file about 30%
smaller (at least in my small test).


reply via email to

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