> 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
