lilypond-devel
[Top][All Lists]
Advanced

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

Re: Cairo plans


From: Jean Abou Samra
Subject: Re: Cairo plans
Date: Mon, 30 Aug 2021 11:39:59 +0200


> Le 30 août 2021 à 10:16, Han-Wen Nienhuys <hanwenn@gmail.com> a écrit :
> 
> 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


Wow, I'm impressed by the speedup.


> 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


13M for this would be fine in my opinion. On contrary to HTML, which people 
browse directly on the website, PDF is usually saved and read locally -- isn't 
it? And few people actually use it compared to HTML.


> 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.)


This is one of the reasons why I'm excited to see Cairo output. (CCing Johannes 
Feulner from scorio, who might be interested in having fonts embedded in SVG 
files.)


>  [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/


What about PNG images?


> 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?


I agree with your reasoning.


> 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?


Could we make Cairo the default in the next development release? We could make 
more noise than usual to get users to test it.

I don't have an opinion as to when to retire the old backends. Wait on Cairo to 
get some testing exposure and let them go?

The current SVG backend is barely usable (slow, unreliable); it can probably be 
dropped soon. PS deserves some more thought due to being more feature-rich; 
would something like -dembed-source-code be feasible with Cairo?

Lastly: thanks for woking on this.

Best,
Jean

> Thoughts?
> 
> -- 
> Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
> <les-nereides-aa.png>
> <les-nereides-cairo.png>
> <les-nereides-gs.png>



reply via email to

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