+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 <hanw...@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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen