Re: Cairo plans

[Han-Wen Nienhuys]

+jan for real now.

Also: apologies to reviewers for the large Merge-Request.
Unfortunately, the backend code was quite convoluted, and I didn't see
a way except to just slash my way through it. refactoring along the
way.

On Mon, Aug 30, 2021 at 10:16 AM Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
>
> 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. Also, I think we could skip emitting
> EPS files for Cairo altogether, which would be another small speedup.
>
> In timings below, I started with an empty out-www/ and lybook-db/ directory,
>
> PS backend (gs-api, no extractpdfmark)
>
>     $ time make -j4 out=www out-www/en/notation.pdf
>
>     real 1m44.958s
>     user 5m26.919s
>     sys 0m14.347s
>
>     $ time make -j4 out=www out-www/en/notation-big-page.html
>     real 2m15.521s
>     user 7m34.088s
>     sys 0m19.567s
>
>     $ ls -lh  out-www-trad/en/notation.pdf
>     -rw-r--r--. 1 hanwen hanwen 38M Aug 30 08:48 out-www-trad/en/notation.pdf
>
> Cairo
>
>     $ time make -j4 out=www out-www/en/notation.pdf
>     real 1m20.922s
>     user 4m4.571s
>     sys 0m9.407s
>
>    $ time make -j4 out=www out-www/en/notation-big-page.html
>     real 1m39.933s
>     user 5m33.227s
>     sys 0m12.100s
>
>     $ ls -lh  out-www-cairo/en/notation.pdf
>     -rw-r--r--. 1 hanwen hanwen 13M Aug 30 08:45 out-www-cairo/en/notation.pdf
>
> If you want to reproduce this, download MR 897, and apply this to
> force Cairo:
>
>     diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
>     index 2d5b9d76b9..33c570c9c6 100644
>     --- a/scripts/lilypond-book.py
>     +++ b/scripts/lilypond-book.py
>     @@ -668,6 +668,7 @@ def main():
>
>     global_options.process_cmd += (
>      ' '.join([' -I %s' % mkarg(p) for p in global_options.include_path])
>     +        + ' -dbackend=cairo '
>      + ' -daux-files ')
>
> global_options.formatter.process_options(global_options)
>
> for size comparison, notation.pdf for 2.22 is 6.7M
>
> For the final website, we anti-alias the images by generating them at
> twice the resolution and then scaling them down. This seems
> unnecessary with the Cairo output: the rendering already uses
> antialiasing, and IMO, the plain Cairo output looks better than
> antialiased GS (images attached).
>
> Open question is how to position Cairo output and what defaults we
> should provide.
>
> * SVG.
>
>   The current SVG backend is glacially slow, and has suffered from
>   rendering discrepancies. I propose we retire it ASAP to be
>   replaced by Cairo. The only feature missing is the 'svg-woff option;
>   not sure how important that is? (CC'ing Jan who implemented this.)
>
>     [hanwen@fedora lilypond]$ time lilypond --svg
> input/regression/les-nereides.ly
>     GNU LilyPond 2.23.4
>     ..
>     real 0m1.662s
>     [hanwen@fedora lilypond]$ time lilypond  --svg -dbackend=cairo
> input/regression/les-nereides.ly
>     GNU LilyPond 2.23.4
>     ....
>     real 0m0.728s
>
>   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.
>
> * PS/EPS
>
>   The Cairo backend doesn't support \ps-command. This is unavoidable,
>   and probably a feature rather than a bug. It also doesn't support
>   \eps-file, but that can be made to work: see
>   https://www.cairographics.org/manual/cairo-PostScript-Surfaces.html#eps)
>
>   However, if Cairo is going to be the default, we should rather think
>   about PDF first (ie. embedding PDF images into the music). That's
>   possible, but we'd need to link in Poppler:
>   https://www.cairographics.org/cookbook/renderpdf/
>
>   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?
>
> 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).
>
> Here are my questions:
>
> * when could/would we drop the SVG backend?
>
> * when could/would we switch the default PS/PDF/PNG backend to cairo?
>
> * when could/would we drop the PS backend altogether?
>
> Thoughts?
>
> --
> Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen



-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen