Re: Cairo plans

[Werner LEMBERG]

> I'll look into PDF processing software.  AFAICT, the subsetting
> retains the character mapping of the original font, so I think it
> should be possible to rewrite it to embed the Emmentaler font once,
> point all font references to the full font, and elide all the
> subsetted versions.

Thanks.

> I see no reason to keep the SVG backend alive given that Cairo
> achieves the same functionality faster and with less code.

I agree.

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


   Werner