Pango 1.50.12+ cannot load non-system fonts for Wesnoth 1.16 on Windows

[Wedge009]

Game and System Information

• Version: 1.16.9
• Downloaded from: Steam, but I expect other Windows releases to exhibit the same problem.
• Build info: Official release build
• OS: Windows 7 and 10

Description of the bug

Pango reports being unable to load Lato font as per logs:

(process:11320): Pango-WARNING **: 09:21:34.812: couldn't load font "Lato Not-Rotated 20", falling back to "Sans Not-Rotated 20", expect ugly output.

(process:11320): Pango-WARNING **: 09:21:34.824: couldn't load font "Lato 14", falling back to "Sans 14", expect ugly output.

(process:11320): Pango-WARNING **: 09:21:34.840: couldn't load font "Lato Not-Rotated 17", falling back to "Sans Not-Rotated 17", expect ugly output.
Checking lua scripts... ok

(process:11320): Pango-WARNING **: 09:21:35.269: couldn't load font "Lato Italic Not-Rotated 17", falling back to "Sans Italic Not-Rotated 17", expect ugly output.

(process:11320): Pango-WARNING **: 09:21:35.275: couldn't load font "Lato Bold Not-Rotated 17", falling back to "Sans Bold Not-Rotated 17", expect ugly output.

(process:11320): Pango-WARNING **: 09:21:35.307: couldn't load font "Lato Not-Rotated 16", falling back to "Sans Not-Rotated 16", expect ugly output.

(process:11320): Pango-WARNING **: 09:21:35.311: couldn't load font "Lato Not-Rotated 15", falling back to "Sans Not-Rotated 15", expect ugly output.

(process:11320): Pango-WARNING **: 09:21:35.313: couldn't load font "Lato Not-Rotated 13", falling back to "Sans Not-Rotated 13", expect ugly output.

(process:11320): Pango-WARNING **: 09:21:35.317: couldn't load font "Lato Not-Rotated 14", falling back to "Sans Not-Rotated 14", expect ugly output.

So far, I only see this issue on 1.16 releases for Windows. 1.17 doesn't appear affected, neither are Linux releases.

1.16.9 on Windows 7:

Steps to reproduce the behavior

Run Wesnoth 1.16.9 on Windows.

Expected behavior

1.16.8 on Windows 7:

1.17.15 on Windows 7:

1.16.9 on Linux:

Additional context

Don't know if it's relevant but Windows release builds includes pango 1.50.11 for Wesnoth 1.16.8 and pango 1.50.14 for both 1.16.9 and 1.17.15.

I cannot bisect this issue due to #7217.

[Pentarctagon]

Are there Lato fonts present in wesnoth's fonts/ directory?

[Wedge009]

Yes, I did check they were all there - seems to be unchanged from 1.16.8.

[Pentarctagon]

Darn, I was hoping it was that simple...

@Vultraz or maybe @knyghtmare would you be able to try bisecting this?

[Wedge009]

Darn, I was hoping it was that simple...

Was one of the first things I checked, also hoping to find a straightforward cause...

[Wedge009]

Labelled as possible upstream issue as it seems to be pango-related. I dropped pango 1.50.11 DLLs (libpango*.dll - four files) from 1.16.8 release into 1.16.9 release and the Lato font seems to load fine.

Although this doesn't explain why Wesnoth 1.17.15 doesn't have the issue despite using the same pango version (I believe) as Wesnoth 1.16.9.

[knyghtmare]

would you be able to try bisecting this?

What am I supposed to look for?

Should I use 1.16.8 as a starting point and the latest 1.16.x commit as the end point?

[Wedge009]

1.16.8 and 1.16.9 should suffice. 1.16.8 'good', 1.16.9 'bad'.

But if the underlying issue is due to changes in pango, a bisect might not get us anywhere.

[knyghtmare]

I cannot seem to switch to 1.16.9+dev branch on Github Desktop. This was working fine...What is this?

[gfgtdf]

It would be nice if this war reported upstream, if it's a recent change someone at pango that knows the ide might still be around to fix it

[Pentarctagon]

@knyghtmare I guess it doesn't like the lua modules directory not existing for 1.16 for some reason. I don't know why though - a simple git checkout 1.16 on the command line works fine.

[knyghtmare]

warning: unable to rmdir 'src/modules/lua': Directory not empty
Updating files: 100% (12450/12450), done.
Switched to branch '1.16'
Your branch is up to date with 'origin/1.16'.

It worked but doesn't show in the Github desktop client that it worked

[Zireael07]

Github desktop client has always been buggy for me. Try another free GUI git client - GitKraken and SourceTree are both good in my experience

[gfgtdf]

So if i understood the comment in #7544 (comment) correctly we 'fixed' the 1.16.9 windows steam/download release by using oder dll versions? And this is 'only' about self builds and 1.16.10+ now?

[Pentarctagon]

Correct.

[Wedge009]

It appears that with the way 1.16 uses Pango - without fontconfig that's currently in master - something changed in Pango between 1.50.11 and 1.50.14 such that on Windows platforms it will only load a font if it's available in the Windows system pool of fonts. I confirmed this by installing the Lato fonts on my system, and re-confirmed the problem after uninstalling the fonts.

I found this from browsing various reports of the same issue for projects that depend on Pango, not Pango itself. Looking at Pango's change log, there doesn't appear to be anything directly associated with this change in behaviour.

[Pentarctagon]

So this is potentially an upstream issue, in that case?

[Wedge009]

Perhaps a change in how downstream users are expected to use it.

[Pentarctagon]

Did you find anything indicating what that new expected usage is? If not, it would probably be worth it to open an issue on the pango gitlab asking if it's intentional and if it is then what's the new expected way to handle this.

[Wedge009]

Actually, I'm not even sure that it's necessarily a new problem. I don't really know how Pango, Cairo, fontconfig, and Wesnoth are all supposed to interact. But reading through various issues like the following seems to suggest that it's an expectation to either use fontconfig to set-up the fonts or have the fonts installed and available system-wide:

Automattic/node-canvas#1608
lovell/sharp#1162 (comment)
shoes/shoes3#48

Oh, and I think my GitLab account expired - I gave up on trying to use the platform because of some requirement that the GitLab account name and the name configured in my local Git be the same for MRs. Or maybe that was specific to the project, I can't remember now.

[Pentarctagon]

Reading through those, it sounds like there are a couple options to try and get some additional information:

• Try setting the FC_DEBUG environment variable (apparently FC_DEBUG=8191 is the most verbose?)
• Add a glib log handler as shown in https://stackoverflow.com/a/26618242

Otherwise I suppose the question would just be "how are we supposed to be loading game-specific fonts that aren't installed or system-wide?"

[gfgtdf]

But reading through various issues...

All of these issues are much older then this bug the pango version that changed this is from 2023 or late 2022, and even if our method is not listed there it doesn'tean that it's not supported.

I really think the only way to get clarity on this issue is to file an upstream bug report, ideally with a simple example code.

[Wedge009]

All of these issues are much older then (sic) this bug the pango version that changed this is from 2023 or late 2022, and even if our method is not listed there it doesn'tean (sic) that it's not supported.

I noted that as well. As a quick test, I tried libpango 1.50.14 (my distribution normally uses 1.50.6) on Linux and confirmed I don't already have Lato installed as a system font - no apparent issues on either 1.17.18+dev nor 1.16.9 release nor 1.16.10+dev. Just confirming: Windows is the only platform where Wesnoth doesn't use fontconfig (and only for 1.16)?

[Pentarctagon]

Correct.

[Wedge009]

After some more testing with vcpkg's builds of Pango and peeking into the Pango source code and git blame records, I'm fairly confident this is caused by https://gitlab.gnome.org/GNOME/pango/-/commit/5bc16f7896ba3eb5b37ffdb03f28c646aad5889e. There's an issue already open for this: https://gitlab.gnome.org/GNOME/pango/-/issues/720

(In summary, it appears to be caused by a switch to DirectWrite that broke Windows GDI support. Wesnoth uses the latter.)

This doesn't help the release version of Wesnoth, since that doesn't use MSVC, but while this is an issue I can work around it by adding the following to vcpkg.json:

  "overrides": [
    {
      "name": "pango",
      "version": "1.50.11"
    }
  ]

[Wedge009]

@loonycyborg Do you need to be aware of this? Perhaps we can hold to libpango 1.50.11 for Windows releases for the time being?

[Wedge009]

Advice from Pango developers seems to be to stay on libpango 1.50.11 until they replace the now-missing GDI functionality in a 'PangoWin32 API'. (Or use fontconfig, which we already established in #7544 cannot be done.) DirectWrite - which seems to ignore non-system installed fonts - replaced GDI usage in libpango 1.50.12.

https://gitlab.gnome.org/GNOME/pango/-/issues/720#note_1794746

Additionally, it appears any support for non-system fonts with newer Pango would be for Windows 10 first, older Windows second (if at all).

[gfgtdf]

Nice, thx for finding this.

[loonycyborg]

I guess we would have to make a separate docker image for msys2+windows build then, with downgraded pango.

[Konrad22]

Hey, it seems the bug made it into the 1.16.10 release. :/

[Pentarctagon]

Should be fixed for 1.16.10 now.

[fanc999-1]

Hi,

This issue is raised as Pango/Cairo is transitioning to DirectWrite, so AddFontResourceEx() with FR_PRIVATE will be affected when using PangoWin32.

Related upstream items:
https://gitlab.gnome.org/GNOME/pango/-/issues/720
https://gitlab.gnome.org/GNOME/pango/-/merge_requests/700
https://gitlab.gnome.org/GNOME/pango/-/merge_requests/707

Current upstream Pango has a new API that works for Windows 10 and later that added support using an API adding non-installed fonts into the PangoWin32FontMap, and the version for Windows 7/8.x is under review/progress.

With blessings, and cheers!

[Pentarctagon]

Is there documentation for this?

[Wedge009]

I suppose this can be closed once 1.18 releases

[Wedge009]

Not an issue with 1.18.x release.