[GUI] The default theme (and a few others) have problems with Cyrillic text on Windows

[victoryforce]

Describe the bug/issue

The default theme for the Ukrainian UI (as well as other languages with Cyrillic text) contains text with too wide letters and with large spacing between letters, which looks monospaced.

The problem does not appear only in the "darktable" and "darktable-icons" themes.

To Reproduce

1. Launch current Windows darktable build and change the interface language to Ukrainian.
2. Restart darktable. If you do this with an empty configuration directory, then you will get the theme "darktable-elegant-grey" and you can observe the problem.

Platform

• darktable version: Latest git master build as of the date of the issue.
• OS: Windows

Additional context

This is not reproducible on Linux (at least on a regular Ubuntu installation).

[dterrahe]

A screenshot helps (from Windows 10)

It seems that for example module labels (and tooltips, which are harder to screenshot on windows) are not affected, but bauhaus labels are. This may help @Nilvus diagnose the issue, although this could also be a lack of appropriate fonts on windows.

(this probably also helped aggravate #12877)

[victoryforce]

although this could also be a lack of appropriate fonts on windows.

Perhaps, but no fonts have been explicitly removed from Windows recently, and there was no such problem before. I can't remember the exact date to help find the cause, but I used to run dt with an empty configuration for debugging, it immediately started with the Ukrainian language (from system settings) and this problem did not occur.

[Nilvus]

If it appears only on elegant themes, so maybe some Roboto fonts missing. I don't know how they handle Cyrillic fonts but they should given that those theme use them since 3 years now and nothing had changed recently.

The only font setting recently done was adding that line, following your good idea @dterrahe:

font-feature-settings: "tnum"; (line 241)

That line add spacing for numbers only. But maybe that could have unwanted effet on some Cyrillic fonts. Is one of you could test what you have if you remove that line?

[victoryforce]

If it appears only on elegant themes, so maybe some Roboto fonts missing. I don't know how they handle Cyrillic fonts but they should given that those theme use them since 3 years now and nothing had changed recently.

This problem does not occur on darktable 4.0.1. So it can't be a missing font issue because the css file that defines the fonts hasn't changed since then.

The only font setting recently done was adding that line, following your good idea @dterrahe:

font-feature-settings: "tnum"; (line 241)

That line add spacing for numbers only. But maybe that could have unwanted effet on some Cyrillic fonts. Is one of you could test what you have if you remove that line?

In my test, removing this line does not fix the problem.

[Nilvus]

So there's something else. Unfortunately, I can't help more here. If this works great on darktable 4.0.1, that means it would be good if we fix that for 4.2 release (we have 1 week for that, no more). But, as you precise that you can't reproduce on Linux, I can't reproduce so. A git bisect would so be needed to understand when this had been introduced.

[Mark-64]

This problem does not occur on darktable 4.0.1. So it can't be a missing font issue because the css file that defines the fonts hasn't changed since then.

Windows 11, I rebuilt 4.0.1 and the issue is there.
Could it be some updates in Windows fonts or in Gtk libs?

[Mark-64]

In darktable-elegant-darker.css (for example), line 71
{

  font-family: "Roboto Light", "Roboto",                  /* best case scenario */
               "Segoe UI Light", "Segoe UI",              /* Windows 10 default */
               "SF Pro Display Light", "SF Pro Display",  /* Mac OS X default */
               "Ubuntu Light", "Ubuntu", "IPAPGothic",    /* Ubuntu default */
               "Cantarell",                               /* Gnome default */
                sans-serif;                                /* default default */
}

removing Segoe UI Light fixes the issue for me.
Definitely a Windows and/or Gtk problem.

@Nilvus what we do?

[Mark-64]

Actually neither Roboto (any variant) nor Segoe UI Light have cyrillic support on my Windows 11 system.

But I live in Italy, maybe they have not been installed.
@victoryforce can you test?

[kmilos]

"Light" is one of the 12 font faces ("tipi") of Segoe UI you see there, and should have Cyrillic support.

Word has no problems displaying both the normal and the "Light" text:

[victoryforce]

Windows 11, I rebuilt 4.0.1 and the issue is there.

I have Windows 10, latest updates, nothing font related installed or uninstalled. When I wrote that the problem does not occur on darktable 4.0.1, I meant the installed official build. It is possible that dt 4.0.1 rebuilt now, with the current versions of the libraries in MinGW, would also suffer from this problem (not yet tested though). Then it may indeed look like a regression in some related libraries.

Actually neither Roboto (any variant) nor Segoe UI Light have cyrillic support on my Windows 11 system.

No Roboto font installed on my system. Regarding "Segoe UI Light" I was not convinced by your screenshot that this font does not contain Cyrillic. Only "Segoe UI" is shown there, but all other typefaces of this font are hidden behind this base font name.

In order to check whether the font contains Cyrillic letters, I use "Character Map" Windows utility. Segoe UI Light actually contains Cyrillic letters.

[kmilos]

It is possible that dt 4.0.1 rebuilt now, with the current versions of the libraries in MinGW

Yep, it wouldn't be the first time a pango/cairo/harfbuzz/gtk update introduced a regression like this on Windows, but it is not easy to track down... @wpferguson

[victoryforce]

removing Segoe UI Light fixes the issue for me.

@Mark-64 Fixes the problem for me too!
So this looks like a solution to the problem. Although it is still not clear what caused it.

[kmilos]

@victoryforce Maybe try downloading and replacing with older DLLs of said libraries one by one?

[Nilvus]

Another annoying Windows specific issue. I fear that removing Segoe UI Light could break display on other languages for some Windows users. I remember that Segoe fonts were added to allow correct rendering on Windows (on non Cyrillic languages, Cyrillic were not tested). Seems that regarding your comments, removing it would be more a workaround to something broken on some external libraries than a good fix.

[kmilos]

Another annoying Windows specific issue.

We have nightly builds, but not enough testers :(

[Mark-64]

Manually downgrading pango in MSYS2 to
mingw-w64-ucrt-x86_64-pango-1.48.9-2
fixes the issue for me, so confirmed it is a regression in pango.
I will try to find the last good version and open an issue upstream.

So for 4.2 we could build the Windows version against an old release of pango, waiting for the fix.

Can someone confirm?

[Mark-64]

To me, the last good version of pango is
mingw-w64-ucrt-x86_64-pango-1.50.9-1
which is actually the one immediately before the current (mingw-w64-ucrt-x86_64-pango-1.50.12-1)

Good, the regression is very recent
EDIT: Created an issue in Pango, see here

[TurboGit]

@Mark-64 : Nice detective work. Thanks!

[TurboGit]

@wpferguson : Please can you record this to be done (using mingw-w64-ucrt-x86_64-pango-1.50.9-1) for the next Windows binary release? TIA.

[kmilos]

which is actually the one immediately before the current

Hm, I see 1.5.10 and 1.5.11 also available here: https://repo.msys2.org/mingw/ucrt64/ so might be nice to narrow this down further, thanks! @Mark-64 @wpferguson

[Nilvus]

PR to fix that is posted (#13143): reviews are needed. Thanks guys for team work!

[Nilvus]

Just a note to those following that issue. My PR do not fix the issue actually. @Mark-64 and I have done feedback and Pango issues and some things are also on their side. This issue is so both Pango and darktable issue (more Pango but Pango issue revealed that the way fonts are handle on CSS code in darktable do not respect CSS specs, even if code works).

I follow, with @Mark-64, work on Pango side. We have quick feedback and they take care of the issue actually. So work is in progress and my PR will be confirmed or update if needed after Pango fix will be done.

[TurboGit]

@Nilvus : Any news on this?

[Nilvus]

@TurboGit: unfortunately, no. There's some WIP on Pango side but seems that this issue is also linked to Cairo side. See last comments on https://gitlab.gnome.org/GNOME/pango/-/issues/718 from Chun-Wei Fan And Luca Bacci. MR on Pango Gitlab is https://gitlab.gnome.org/GNOME/pango/-/issues/720

I fear that this will take some time to see a fix on Pango/Cairo side. So, at least for 4.2.1, I think we will need to keep same Pango release on Windows package as for 4.2 (@wpferguson).

[Nilvus]

Nothing moves on Pango and Cairo issues. So remove milestone.

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[kmilos]

Just tested the new pango-1.52.1-1 package, no change...

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[kmilos]

Still reproducible w/ pango 1.54.0, while all related upstream tickets seems to be closed?

Note that indeed removing the offending "Light" from the CSS starts addressing the issue...

[victoryforce]

Note that indeed removing the offending "Light" from the CSS starts addressing the issue...

Yes, this is a fix I've been testing extensively since yesterday (and started thinking about whether it's a good solution even earlier) and will push PR with this fix soon.

I haven't noticed any side effects yet. See, there are themes that do not use "Segoe UI Light", so using this font in the theme is definitely not necessary for correct rendering.

[kmilos]

Great. Also, going by the comments of pango devs, using "Segoe UI Semibold" and "Segoe UI Condensed" might be incorrect as well... In any case, I'll let someone more knowledgeable in CSS and GTK dig in, as it doesn't seem pango is to blame here any longer?