Re: Missing items to make Cairo ready

[Han-Wen Nienhuys]

On Thu, Jan 5, 2023 at 2:24 PM Werner LEMBERG <wl@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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen