Conversation

Uhg, Pango utterly broke font support for everything using it (including everything GTK):

gitlab.gnome.org

Pango 1.44 and the removal of support for bitmap fonts (#386) · Issues · GNOME / pango · GitLab

Pango 1.44 just landed in Arch Linux. Applications that use Pango and that are configured to use bitmap fonts now only show rectangles instead of characters. This affects...

2

2

1

It's not just bitmap fonts (which IMO are useless nowadays, but whatever) but also Type1 fonts, which prominently includes the only free perfect-matched replacements for Helvetical, Times, and Courier - the Nimbus family from ghostscript-fonts package.

1

1

@LeahNeukirchen

Replying to

These are at ctan.org/tex-archive/fo in OpenType, no?

1

1

Replying to

@LeahNeukirchen

I think so. Distros need to package them, though, and Pango needs to make sure it skips the Type1 results in font enumeration or it will end up selecting them if they come first, then failing to load when it passes them to harfbuzz...

1

Replying to

and

@LeahNeukirchen

There's conversion software so distributions should probably convert all their packaged bitmap and Type 1 fonts to OpenType. Bitmap fonts can be converted to an OpenType font providing an embedded bitmap for each supported size, although it will have a terrible vector variant.

2

Replying to

and

@LeahNeukirchen

Yes. If distros take care of that, it will be mostly better, but will still be a pain for some users with custom fonts, especially GIMP users with projects depending on them...

1

Replying to

and

@LeahNeukirchen

Of course it was a horrible mistake to use a nondeterministic, *interface* library as part of the data model, but TBF Pango was never clear on whether it was an interface library or something suited for this...

1

Replying to

and

@LeahNeukirchen

If they had provided a sensible deprecation period, there would have been time to provide automatic conversion using one of the codebases providing it. It probably would have had an impact on rendering (hopefully minor) but at least it would still work. Now, it's too late.

1

1

Replying to

and

@LeahNeukirchen

I've been screwed over multiple times by GNOME ecosystem libraries making unexpected backwards compatible changes without time to prepare for it and deal with a migration. They also often remove things without a replacement, which is at least not the case for this example.

1

Replying to

and

@LeahNeukirchen

I've often been screwed over by changes with no clear path forward. They love making APIs that I depend on private and then their response to my request / patches to make the APIs public and documented is basically to tell me to fuck off since they don't need it in GNOME itself.

6:31 PM · Jul 30, 2019Twitter Web App

Replying to

and

@LeahNeukirchen

So, for example, don't get the wrong impression that gitlab.gnome.org/GNOME/vte is a "virtual terminal widget for GTK applications" providing proper Unicode handling and modern font rendering, etc. unlike most alternatives. It's GNOME Terminal code, not meant to be used elsewhere.

gitlab.gnome.org

GNOME / vte · GitLab

Virtual Terminal library You must read the bug reporting guidelines before filing an issue!

1

Replying to

and

@LeahNeukirchen

Same thing applies to GTK itself. Using it is a big mistake. It will remove half of what you depend on because GNOME decides to change everything. It's certainly not actually a cross-platform library intended for usage by applications outside of GNOME either. It's misrepresented.

1