lilypond-devel
[Top][All Lists]
Advanced

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

Re: Missing items to make Cairo ready


From: Jonas Hahnfeld
Subject: Re: Missing items to make Cairo ready
Date: Fri, 30 Dec 2022 13:54:33 +0100
User-agent: Evolution 3.46.2

On Fri, 2022-12-30 at 13:08 +0100, Jean Abou Samra wrote:
> > I am not at all convinced by these workarounds just to get Cairo a
> > bit earlier and avoid walking the proper road to the clean solution
> > (ie properly deprecating what we don't want to or cannot support).
> 
> \postscript can be deprecated on other grounds, but we cannot
> really deprecate \epsfile without an offering an alternative,
> which means figuring out how to do PNGs via the default PS
> backend and GS.

Yes, I agree.

> I'm not really eager to do that, TBH.
> 
> > I think this is a bad limitation, and adding more dependencies into
> > the mix doesn't make it more appealing.
> 
> As I said, I don't see obvious use cases for \epsfile where you
> really need vector graphics. LilyPond provides markup commands
> for that.

Ok, in that case we can properly deprecate this once we have an
alternative (see above). I still think losing the ability to include
(external) vector graphics is a loss, though.

> > With Cairo, I am not aware of benefits for our users, it is more
> > motivated by internal maintenance considerations - please correct
> > me if I'm wrong.
> 
> - SVG rendering is *way* faster.
> 
> - It also embeds fonts, so the generated SVG files are device-
> independent.

Ok, this is SVG which we can probably agree that the backend is in a
bad state. At some point, there was a discussion on making Cairo the
default for producing SVGs but IIRC it faded out with the lack of
support for output-attributes, ie
https://gitlab.com/lilypond/lilypond/-/issues/6503

Once that is solved, only enabling Cairo by default for SVGs may be a
separate discussion that is worth having.

> - PDF rendering is a little faster.
> 
> - It does not use a subprocess, which makes it easier to sandbox it
>    (cf. the problem with LilyPond on GitHub actions that was
> discussed some time ago on this list).
>    (OK, this is defeated by the "workaround" as you noticed.)

Both actually, right?

> - It makes it easier for developers to add certain features
>    that would be harder to support in the current backends,
>    like PNG, which benefit users in the end.

"Developer happiness" is hard to sell to users unless it results in
immediate benefits; I don't think it's a convincing argument at the
moment.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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