[Top][All Lists]

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

Re: Cairo plans

From: Jean Abou Samra
Subject: Re: Cairo plans
Date: Tue, 31 Aug 2021 17:24:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Le 31/08/2021 à 14:47, Werner LEMBERG a écrit :
 From my current understanding of missing features, the amount of
testing the backend can have received (or rather cannot, due to
novelty), and the nature of bugs that are found (both in Cairo
itself and the integration in LilyPond), I don't think the backend
is currently in a state to be used by default.  I would highly
prefer to not mix switching the default backend with switching to
Guile 2.2 that will already be disruptive enough (yes, it's going
slower than I had hoped...).
I see your point, but consider the following: the PS backend
represents 3500 fiddlesome Postscript and Scheme code, which is only
exercised by us.

With the cairo solution, the complexity of rendering and font
handling is moved to Cairo, which is much more widely used and
better tested.  We are only left with which is much more
straightforward.  It should be expected that the cairo solution
takes comparatively little effort to stabilize.
In the long term this is certainly the way to go.  However, applying
Jonas's conservative versioning approach makes sense to me.  We aren't
in a hurry, are we?

* when could/would we drop the PS backend altogether?
I would say that this step requires going to LilyPond 3.0, along with
removing all the features and commands that cannot be implemented in
the Cairo backend, or that we don't want to.
We can discuss this in detail later, but I think a major version
bump is not warranted, as we're leaving the music input intact.
Jean's argument is a good point: Similarly to libtool, it deserves a
major version bump if you remove some functionality altogether that
was available for many years before.

My gut feeling says that a combination Guile 2.x with the Cairo
backend deserves 3.0.

I purposefully won't enter the debate about a potential
major version bump.

I would propose the following: For the next stable release
(whenever that will be), it would be good to have the Cairo backend
mature enough that it can be shipped as a "preview" in the official
my feeling is that this state is actually pretty close now already.
So let's work on a new stable release, then?

To me, the top priority would be getting the fresh
Cairo backend to be tested as widely as possible, as
soon as possible. Unfortunately, I currently have some
doubt that releases with Cairo being opt-in will best
achieve this effect. The reason is that most users
are editing in Frescobaldi, and Frescobaldi doesn't
-- to my knowledge -- offer a way of permanently editing
the set of command line options passed to LilyPond
(there is "Engrave (custom)" but you have to click
OK in a new window every time, which is annoying when
working on a score). It would be best to get some users
to use Cairo for their daily engraving work, as opposed
to letting them test a few scores when the release is
out (e.g., it took me a couple months of building with Guile 2
and developing with it to notice the \ottava quirk in
For that I think Cairo by default would be the most
effective way. Hence my earlier suggestion of making
Cairo the default in the next development release.
These are called unstable after all.

An alternative would be to release separate binaries
with opt-out Cairo. They wouldn't even need to be
official. But this has the problems linked to having
several versions with the same number ("I cannot reproduce
this even with the same version as you ...").

On the lists, we see a number of power users posting
examples with \version "2.23.3". Isn't that an ideal
testing pool for Cairo?


reply via email to

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