On Thu, Jan 5, 2023 at 2:24 PM Werner LEMBERG <w...@gnu.org> wrote: > > > >> The only thing I would like to convince the Cairo people is to add > >> a mode to produce PDFs with font references instead of embedding – > >> and subsetting – fonts. My Cairo knowledge is zero; maybe this is > >> already possible? > > > > This makes no sense to me as a Cairo feature. Such PDF snippets > > would need custom post processing to assemble into the full > > document. > > The general problem (i.e., the inclusion of multiple PDF images into a > larger PDF document) is not unique to LilyPond. My idea is that there > exist special tools (for example, Ghostscript's 'pdfwrite' device or > `pdfsizeopt`) to produce size-optimized PDFs.[*] However, these tools > can only do their optimization job if the necessary preliminaries are > fulfilled. If the PDF images contain subsetted fonts, it doesn't work > most of the time: You either need PDFs with complete fonts (i.e., not > subsetted), or PDFs with references to fonts. I've now looked up the > Cairo manual, and it doesn't offer any control for that. > > > If we do custom post processing, we might as well postprocess the > > final PDF directly to make all snippets point to a single music font > > object? > > Font subsetting effectively prevents such post-processing since too > much information gets stripped off during this process. For the > special case of Emmentaler fonts it might work because LilyPond knows > more about these fonts than for others, but not in the general case.
I played around on essay.pdf with pdfcpu. It looks like Cairo strips the encoding information when the snippet PDFs are generated, and then creates a subsetted font containing /uni0001, /uni0002 in glyph slots 1, 2, .. in the font. I was hoping we could replace the font reference within the snippet in a postprocessing step, but this is obviously impossible, as each snippet has its own encoding. It also means that the Cairo feature you propose would add a completely new way of outputting glyphs/fonts, with associated costs in coding, testing etc. >From the perspective of Cairo development, it seems like a tall order. > > IMO, working with a 35mb user manual isn't materially different from > > working with a 10mb user manual. Both take a while to download. > > Indeed, but the manuals as a whole, in all languages, get also > distributed, and there it *does* make a significant difference IMHO: > Right now, the PDFs in `lilypond-2.24.0-documentation.tar.xz` (which > has a size of 170MByte) need 144MByte in total (uncompressed). > Multiply the latter by four... Do people actually download this a lot? Unfortunately Gitlab doesn't provide this data (https://gitlab.com/gitlab-org/gitlab/-/issues/327317). I looked on lilypond.org as well, but we only have 2 weeks of data and the doc tarballs there are outdated (there were no downloads.) -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen