lilypond-devel
[Top][All Lists]
Advanced

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

Re: Cairo plans


From: Werner LEMBERG
Subject: Re: Cairo plans
Date: Mon, 30 Aug 2021 08:49:42 +0000 (UTC)

> With MR 897, I have been able to run the doc build through Cairo.
> Results are very encouraging: the build is faster, while the
> resulting PDF file is smaller.

Great!

> -rw-r--r--. 1 hanwen hanwen 13M Aug 30 08:45 out-www-cairo/en/notation.pdf

This is still far too large IMHO.  On my GNU/Linux box, the default
documentation build (using gs 9.54 & extractpdfmark) produces a
`notation.pdf` version that is less than 6MByte.

>   The current SVG backend is glacially slow, and has suffered from
>   rendering discrepancies.  I propose we retire it ASAP to be
>   replaced by Cairo.

I don't use SVG normally, but this sounds like a good plan, especially
because of ...

>   The Cairo SVG files are larger, but that is because they also
>   embed the fonts used for texts, making the rendering exactly equal
>   to the PDF/PNG.

... this.

>   The PS backend also has support for a couple of options that Cairo
>   doesn't have
> 
>   - embed-source-code
>   - font-ps-resdir
>   - gs-load-fonts
>   - gs-load-lily-fonts
>   - gs-never-embed-fonts
>   - music-font-encoding
>   - outline-bookmarks
> 
>   I think we can't support the options that tweak font loading, but
>   do we need to, if we generate our docs directly from PDF, and the
>   result is reasonably small?

This is the main question.  IMHO, Cairo's output is definitely not
small enough for large documents that embed zillions of small PDFs
like LilyPond's Notation Reference PDF.  What about retaining the PS
backend but making Cairo the default?

Maybe we can further convince the Cairo people to add a PDF output
mode that doesn't embed fonts, leaving the final assembly to a better
suited program (like gs).

> Dropping Ghostscript altogether would let us delete ~5000 lines of
> code, simplify runtime (no more subprocessing), our build (don't
> have to build GS), and simplify our licensing story (no more
> potential AGPL dependency).

Right now, as discussed above, I favor not doing this.

> Here are my questions:
> 
> * when could/would we drop the SVG backend?

ASAP, but I'm probably not qualified enough to make a decision here.

> * when could/would we switch the default PS/PDF/PNG backend to
>   cairo?

As the default: ASAP.  Removing the old PDF backend: not now.

> * when could/would we drop the PS backend altogether?

As above: I suggest to retain it but making Cairo's PS output the
default in case this is faster.

On the other hand, I don't see any advantage to retain the PNG output
given that Cairo produces exactly the same (according to your
reports).


    Werner



reply via email to

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