Preview gets stuck at certain font in family.

[WinkelCode]

Describe the bug
The preview window gets stuck on a certain font in a family, selecting another font in that family won't change the preview.

To Reproduce

1. Have affected font installed. In my case "Montebello" by Ian Bernard (unfortunately not a free font, so I can't link the files).
2. All previews will only show one of the fonts.
3. If the stuck font is removed, another font will get stuck in its place.

Expected behavior
Different fonts are shown separately.

Screenshots
Note how they look the same:

Different program, you can see that there should be a clear difference (screenshot from FontBase):

System Information

• OS: Alpine Linux via WSL2
• Desktop Environment: Gnome is installed but application is displayed directly via WSLg
• Font Manager version: 0.8.8
• Font Manager installation method: Tested with both apk package and Flatpak

Additional context

1. This issue doesn't affect any other fonts which I am storing and accessing in the same manner, just this one particular font.
2. I tested with both .ttf and .otf versions of the font.
3. Interestingly, the fields in the character list is changing based on the font's capabilities, it is just displaying the characters of the "stuck" font.

Update:

The issue is also present in "real" Fedora 36/FM 0.8.8 booted from the installation media and with the font files downloaded into the temporary filesystem. (Just to verify that this is not related to WSL2)

[JerryCasiano]

This is almost certainly a problem with the font metadata or the way underlying libraries are processing that particular font file.

Since the font is not free you'll need to provide more info.

Install jq if it's not already installed and use it to search the applications output for that family.

i.e.

font-manager --list-full | jq '.[] | select(.family == "Montebello")'

Post the output.

[WinkelCode]

Thank you for looking into the issue, below is the output from the command:

{
  "family": "Montebello",
  "n_variations": 4,
  "variations": [
    {
      "filepath": "/mnt/e/Fonts/Montebello Typeface - Ian Bernard/Montebello-Rounded.otf",
      "family": "Montebello",
      "findex": 0,
      "spacing": 0,
      "slant": 0,
      "weight": 80,
      "width": 100,
      "style": "Rounded",
      "description": "Montebello",
      "_index": 0
    },
    {
      "filepath": "/mnt/e/Fonts/Montebello Typeface - Ian Bernard/Montebello-Sans.otf",
      "family": "Montebello",
      "findex": 0,
      "spacing": 0,
      "slant": 0,
      "weight": 80,
      "width": 100,
      "style": "Sans",
      "description": "Montebello",
      "_index": 1
    },
    {
      "filepath": "/mnt/e/Fonts/Montebello Typeface - Ian Bernard/Montebello-Script.otf",
      "family": "Montebello",
      "findex": 0,
      "spacing": 0,
      "slant": 0,
      "weight": 80,
      "width": 100,
      "style": "Script",
      "description": "Montebello",
      "_index": 2
    },
    {
      "filepath": "/mnt/e/Fonts/Montebello Typeface - Ian Bernard/Montebello-Script-Textured.otf",
      "family": "Montebello",
      "findex": 0,
      "spacing": 0,
      "slant": 0,
      "weight": 80,
      "width": 100,
      "style": "Script - Textured",
      "description": "Montebello",
      "_index": 3
    }
  ],
  "_index": 22,
  "description": "Montebello"
}

[WinkelCode]

I think I found what must be confusing some part of the software! For whatever reason, something goes wrong when the description field is the same between two fonts.

I found another typeface where two fonts have the same description (Atipo Foundry: Silka Regular & Thin), and I am observing the same issue there. The mono variant of that typeface has separate descriptions for all fonts, and doesn't have this issue.

[JerryCasiano]

I think I found what must be confusing some part of the software! For whatever reason, something goes wrong when the description field is the same between two fonts.

Sort of.

The description field is generated by looking at the various characteristics present in the font file metadata.

You'll note that every entry has the same value for spacing, slant, weight & width.

From those values you will of course end up with identical descriptions since those values imply that all those variations are technically identical.

Edit those values to something appropriate and the offending file or files should work properly everywhere rather than most of the time.

I'm leaving this open for now. I'll check later to see if we can fix this without breaking rendering for font files which are actually sane. I believe we used to take the style field into account when generating descriptions but had to drop it, don't remember why or whether the underlying stack even worked properly with descriptions generated that way.

[JerryCasiano]

So I tried some changes to the way we generate descriptions and ended up remembering why we dropped that approach...

I guess the only question I have left is how do other GTK applications, especially core ones like the font selector, handle these broken fonts? Are they exposed correctly and completely usable?

[WinkelCode]

This is how it looks in the Gnome Font Viewer:

[WinkelCode]

More examples (behavior in the font selector matches behavior in the editor for both examples):

• Doesn't work in Gnome Text Editor
  
• Works in Kate
  

---

Edit: Sorry for all the .gif spam, it's the easiest way I could come up with to show how it looks in practice.

It looks like this problem might be beyond Font Manager then? I wonder, since even after just a short look though my font library, I could find at least two affected fonts (Montebello and at least one from Atipo), would it be feasable to implement a "font fixer" that automatically appends the style field to the description in order to fix this issue?

Edit 2: As far as I can tell, none of my Windows applications actually have this issue where the fonts are just called "Montebello".

[JerryCasiano]

No need to apologize, that's not spam at all. It's useful information.

So, the reason gnome-font-viewer displays it properly is because it does it's own rendering bypassing the actual stack used in the rest of the desktop, doesn't really make sense to me to do it that way but it is what it is. In many cases, it leads you to believe that a particular font is usable when in reality as you can see from the actual GTK font selector the font is not usable at all, at least in any GTK applications which don't do their own font rendering which is most of them.

Kate relies on different libraries for it's rendering so that's an apples to oranges comparison, same with Windows.

So yes, the issue is with the way the libraries used by GTK handle broken fonts and not something we can fix within the application. We could do our own rendering which would work around this issue but then users would be confused when the rest of their GTK based desktop behaved differently.

You can file an issue against Pango if you like. But, and it's a big but, that font file in my opinion is simply broken and the Pango developers may tell you as much. I know that working around broken fonts is not only not fun but gets very messy really quick. I would personally suggest you use Fontforge to edit the relevant fields to something sane.

Anyway, since the font will behave that way across GTK applications I don't consider this a bug in the application since it's an accurate representation of what you'll encounter if you try to use it in GTK applications.

I'm going to close this out for now. Please feel free to update this issue with any relevant information. If you do file a bug against Pango please link to it here so we can track it.

Thanks again for your interest.

[JerryCasiano]

would it be feasable to implement a "font fixer" that automatically appends the style field to the description in order to fix this issue?

It does fix the issue for those particular fonts but it unfortunately breaks selection for some actually correct font files in the process.

Editing font metadata was requested in #275 - such a feature would make it easier to deal with these situations, unfortunately it's not quick and easy to get it right and work on it hasn't even started yet so it's likely going to be a long time before that's an option.