Werner LEMBERG <w...@gnu.org> writes: > 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. > > http://tug.org/pipermail/pdftex/2016-July/009045.html > > 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, > AFAICS. > > 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).
A 30% reduction in the final output file size sounds nice. Personally, I find the prospect of not having 4GB of disk usage for running lilypond-patchy-staging quite more compelling, and I would seriously suspect that all the amount of font juggling and merging subsetted fonts will not just take quite a bit of disk space but also of processing time. So if we could successfully pull this off and have it work reliably for lilypond-book, I consider it likely to end up as a real boon in resource usage. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
