#5545 Compatibility with pango 1.44

[Simon Albrecht]

Reported by T. Sefzick:

With the new pango version 1.44 compilation of

src/lilypond/lily/pango-font.cc

gives warnings about
'void* pango_fc_font_lock_face(PangoFcFont*)'
to be deprecated and
'pango_font_get_hb_font'
should be used instead.

followed by
error: invalid conversion from 'gpointer' {aka 'void*'} to 'FT_Face' {aka 'FT_FaceRec_*'}

Seems that pango doesn't work with freetype fonts anymore.

A side note: lilypond executables compiled with pango <=1.43
produce an empty 1st page when run with pango 1.44 installed.

[Simon Albrecht]

Rafael Fontenelle adds:

Indeed, Pango 1.44 dropped support to FreeType font, as posted in
https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/.

[Werner LEMBERG]

Pango 1.44 also dropped Type1 support... Note sure whether this is something we actually want.

[Caleb Malcennan]

1. This is an urgent bug and should be higly prioritized. The side note at the end of the original report is more serious than it sounds: Lilypond is utterly unusable on systems with pango 1.44. It just spits out white sheets or little shreds of stuff that isn't layed out right.
2. This affects a lot of people and will affect more soon. Pango 1.44 has started to show up in downstream distros. For example it hit Arch Linux last week and Lilypond can no longer be used there without downgrading the system. As of today Alpine, Crux, Kwort, Mageia, Manjaro, OpenMandriva, Parabola, and PCLinuxOS also have Pango 1.44. More will follow soon.
3. Pango did not drop support for "free type fonts" as some comments (mostly eslewhere) have tried to suggest. They have changed from using the FreeType library as a font loader to Harfbuzz. This is an objectively better library in almost every way, and is easier to code with (I work on the SILE Typesetter, so I'm not a stranger to this). Sure it will take a little work to migrate, but the long term will be a good thing.
4. When this gets fixed, it should trigger a version bump and release cycle early so that distros where Lilypond has stopped working can start working again.

[Werner LEMBERG]

Well, Pango did drop Type1 support...

Regarding the 1.44 issue: There have been reports that a lilypond binary compiled against Pango 1.43 doesn't work with 1.44 .so libraries (using OpenType fonts). If this can be confirmed (can you do that?) we have a serious bug in Pango itself since they broke ABI backward compatibility; this should be reported as such, and the Pango guys have to increase the .so major number correctly – or fix the ABI.

Of course, we should make LilyPond compile with newer Pango versions, too. It is also possible that our Pango code is not fully correct, exhibiting problems with 1.44.

[Caleb Malcennan]

I can confirm that my Lilypond was compiled against 1.43 and works, dropping in the 1.44 SO makes it fail.

I've reported a bug about the so version with Pango.

[Caleb Malcennan]

Upstream is suggesting the C ABI did not change and the problem is Lilypond's C++ casting.

[David Kastrup]

That concerns the compilation error which is a bit tangential to the issue. Even if the interfaces were superficially completely binary compatible, when there are substantial reductions in functionality making it unavoidable to be using two different versions of the library at the same time, the library numbers have to be changed. Only straightforward extensions in functionality and bug fixes can afford to keep the same numbers because only then there is no incentive to use more than one version of the library at the same time.

[Werner LEMBERG]

I fully agree, and I've just commented on the Pango bug report.

[Caleb Malcennan]

Upstream has rolled back this change. I'm sure it will take a littleb bit of time to land in distros, but when it does Lilypond compiled agoinst 1.43 should work again even with new Pango dropped in. What that won't solve is being able to compile against 1.44, which is also a problem because distros that have new Pango won't be able to update (and hence include) Lilypond.

This is already an issue on Arch that is stuck one point release behind because it won't compile. As soon as this compile time issue is fixed it should make it's way to a point release so Arch and other up to date distros can keep using it on new systems.

[Werner LEMBERG]

Pango 1.44.5 or newer fixes this.