Glimpse: Missing fonts in Glimpse Image Editor 0.2.0 on Windows

[TrechNex]

Describe the bug

Currently if you install the beta versions of Glimpse Image Editor 0.2.0 on Windows, no fonts are installed. We originally assumed the cause was because they were erroneously not included with the MSI installers, but it now seems to be a bigger problem than that.

To Reproduce

Steps to reproduce the behavior:

1. Create new image
2. Click on the text tool
3. Font choice defaults to "Standard", offers no other choices

Expected behavior

There should be a long list of available fonts, just like in 0.1.2.

Screenshots

Desktop (please complete the following information)

• OS: Windows
• Version: 10

Additional context

Add any other context about the problem here.

[TrechNex]

I've dug into this for a couple of hours, and I literally have no idea why this isn't working. All the right files are there, and I have even caught a few unrelated bugs in the 64-bit installer (eg. wrong files in share/xml and share/xml/fontconfig folders).

My current suspicion is that we might be missing something in the CI build. I'm going to try doing a local build and package some time this week to test that theory.

This is not a simple matter of just copying some missing font files, unfortunately.

[TrechNex]

It seems we may be encountering a bug in MSYS2 itself: https://github.com/msys2/MINGW-packages/issues/5762

I am continuing to investigate.

[TrechNex]

Okay, so the tl;Dr is that the build of FontConfig that's included with MSYS2 atm doesn't seem to work. I could be missing a step, but running the usual fc-cache commands doesn't seem to be doing the trick.

This puts is in a bad position because we essentially have these options when it comes to release:

• Release 0.2.0 on all platforms as planned, and release a later update for Windows users to fix the problem (we now have an update checker, so that is technically viable)
• Release 0.2.0 on Linux only for now, and hope that Windows users are fine with continuing to use 0.1.2 until we find a workable solution
• Delay all 0.2.0 releases until we find a solution or MSYS2 project fixes the bug

None of those seem to be good answers to the problem, so I guess we have to determine how important this specific feature is to our users. If they think it's a showstopper, we have to treat it as such.

[LunaTheFoxgirl]

That's for fontconfig, fontconfig should not be used on Windows as windows has its own font management system which should be used instead? 🤔

[TrechNex]

@Member1221 in a world where the GNU Image Manipulation Program isn't based on GTK and using a minimal Linux subsystem to function on Windows, I would agree with you 😂

FontConfig not working seems to impact all GTK-based GUI applications if you build them with MSYS2, which is unfortunate.

As we learned through our own investigations, Crossroad (the custom cross-compiler upstream wrote and use) was something we found difficult to work with and support with our much smaller number of developers and resources.

[LunaTheFoxgirl]

Software development is cursed

[lazka]

(By default gtk/pango doesn't use fontconfig on Windows)

[TrechNex]

@lazka by coincidence, forcing that default behaviour is the workaround I'm currently pursuing. 😄

If there's one thing I've learned working on this 25 year old codebase, it's that I actually have to prove out default behaviour because it often doesn't match what I assumed or read in the docs.

(Adding usual disclaimer that it's amazing this software was achieved with the collective endeavour of volunteers over multiple decades. My griping is usually because I don't understand something adequately enough and am having to spend time puzzling it out to make the thing work!)

[TrechNex]

That didn't yield any positive results. I'm going to try specifically installing the fontconfig package (which upstream does not seem to mention at all in their build doc atm) here: https://packages.msys2.org/base/mingw-w64-fontconfig

Edit: This did not fix the problem

[TrechNex]

Well, if anyone comes up with any other ideas within the next few days I'll investigate them. But it currently looks a lot like I'm going to have to read up on how fonts work in GTK, then try to puzzle out how exactly the GNU Image Manipulation Program has implemented font detection, then figure out how it differs on Windows compare to Linux, then figure out what exactly is broken in MSYS2's implementation.

Given this is a project where I work on the code during two weekends a month (at most), that sounds like detail I'm unlikely to have time to get buried in in the near future given all the higher priority stuff I need to get done. So it looks like we're back to the three choices I suggested earlier. That's unfortunate.

[TrechNex]

Testing the severity of the bug:

• You can still open existing XCF files containing text elements with their original typeface just fine, but you can't edit them or add new ones
• Attempting to add text to an image pops up an error message telling you that you can't do that every time you try to type
• The Text tool and Fonts dock are visible, but empty and non-functional

I don't think we can get away with releasing 0.2.0 on Windows with that level of breakage. 😞

I am currently looking into whether it's possible to create a 0.1.4 release (I.e. existing 0.1.2 executable with updated installer, new PhotoGIMP config and more recent dependency components) as a possible stop-gap solution. #452

[TrechNex]

Having looked into it further this evening, I do not think there is a good workaround on MSYS2 right now. I have dropped a question on the upstream IRC channel, but given my experience asking for help on previous occasions I suspect that will not yield a useful answer.

My guess is that the only way to fix this problem would be to ditch MSYS2 entirely and use the crossroad tool that upstream themselves develop and maintain. That is a problem for us because we would have to create a completely new build process, completely rewrite all of our automated tooling for Windows, and we would probably have to maintain our own fork of crossroad to avoid potential breakage with our build process ongoing.

That is way beyond what I have the time to implement and maintain in my free time, so I think we need to produce workable alternatives.

[TrechNex]

Apparently there are developers on the upstream IRC now running into the exact same problem, so it's reassuring to know that being unable to solve this problem is not just a personal failing on my part 😅

The plan is to release 0.1.2 as a "Gold Edition" (it's a bit self-aggrandising, but I think non-techies are more likely to understand that this means they're getting the same application re-packaged with extra fixes).

Afterwards I'm going to re-engineer our Windows offering. The plan is to provide a Glimpse-branded installer that customizes a pre-existing installation of the GNU Image Manipulation Program. That still addresses our objective of rebranding and making usability customizations, but means we don't have to constantly reverse-engineer upstream's build process for Windows as it evolves, and users on that operating system will not have to wait for us to rebase to get the latest "new shinies".

It might also reinforce the message that it's not our objective to replace or supplant the GNU Image Manipulation Program if our Windows "port" actually becomes a plugin instead.

[LunaTheFoxgirl]

I feel making a modifying installer is kinda eh...
I don’t expect we need to reverse engineer their build process every time so that seems a bit silly to do. We’ve only needed to do so as of late to actually set this up to begin with.

We'd lose customization like our custom about view, wilbur ui replacements, removal of easter eggs, etc.
I know I'm not the one who mainly has to work with this codebase, but we'd be doing a disservice to our users on Windows if we went that route.

Say it as it is, Windows version will be delayed until this regression/problem with fontconfig is fixed and for the time being the "Gold Edition" will have to do if we even ship that.

We need to also consider ways we can ease merging the changes from upstream in to our codebase for every new version we make (to prevent having to redo our patches every time); I am not experienced enough with git to think up a proper workflow for that, though.

[TrechNex]

Also linking to https://github.com/msys2/MINGW-packages/issues/6661 as that seems to duplicate the same issue.

[TrechNex]

After discussing with other members of governance team, we'll be doing some changes:

• The re-released of Glimpse 0.1.2 will be called "Glimpse 0.1.2 Release 2"
• Instead of working on a plugin/modification pack for Windows users, we will wait a time and see if MSYS2 is able to fix the problem

[TrechNex]

Further troubleshooting steps undertaken today during my lunch break:

• Copying 0.2.0 executable and supporting libraries into a known-good 0.1.2 installation to see if using older components fixes it

It did not work. The problem exists in the build system, and therefore the built executable. So no sneaky hackarounds for us today!

[TrechNex]

There's an upstream fix we may want to consider backporting here: https://gitlab.gnome.org/GNOME/gimp/commit/c5f9b8e

Edit: This is the tracking issue too: https://gitlab.gnome.org/GNOME/gimp/-/issues/5530

[TrechNex]

A patch seems to have been applied in MSYS2, so fingers crossed: https://github.com/msys2/MINGW-packages/pull/6809

Source: https://twitter.com/msys2org/status/1295365173016961024

[TrechNex]

Confirming this has now been fixed upstream. It may have delayed our release, but it has not scuppered it!