Re: Cairo plans

[Jean Abou Samra]

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 cairo.cc 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
> > > builds
> > 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
https://gitlab.com/lilypond/lilypond/-/issues/6141).
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?

Best,
Jean