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
