Thanks you for your patch and sorry for taking so long to commit it. Fred
> Am 10.06.2020 um 09:30 schrieb Josh Freeman <gnustep_li...@twilightedge.com>: > > Got yesterday's KDE Neon release installed successfully [1], and the > missing-text issue Patryk found on Neon/Aarch64 also affects Neon/x86_64: > GNUstep gui apps are missing all UI text characters except digits. > > Running the fc-pattern-check tool on Neon (attached output: > fcpc_out_kdeneon.txt) shows the same issue as on Kubuntu: The second > FcFontMatch() call returns a match for the "Noto Color Emoji" font. > > Cheers, > > Josh > > <fcpc_out_kdeneon.txt> > > > [1] Earlier install problems were due to running the KDE Neon installer under > BIOS; KDE Neon requires UEFI. > > > On May 30, 2020, at 5:27 PM, Fred Kiefer wrote: > >> Thank you Josh for this excellent analysis. My impression is that this is >> somewhat of a Kubuntu bug, still it is better to fix it in our code >> especially if this results in a speed up. Such a speed up is really needed >> for slower machines. >> >> I will look through the details of the patch tomorrow and apply it. >> >> Cheers, >> Fred >> >>> Am 30.05.2020 um 21:37 schrieb Josh Freeman >>> <gnustep_li...@twilightedge.com>: >>> >>> Some users of Kubuntu (official flavor of Ubuntu with the KDE Plasma >>> desktop) reported that PikoPixel's missing most of its UI text; Numbers are >>> the only characters displayed: >>> https://old.reddit.com/r/Kubuntu/comments/gas88l/pikopixel_strange_graphics_bug_any_suggestions_on/ >>> >>> I can reproduce this on Kubuntu 20.04, and the missing-text issue affects >>> all GNUstep gui apps, whether the apps & GNUstep are from packages or from >>> current sources. >>> >>> This might be the same issue that Patryk found last August with KDE Neon: >>> https://lists.gnu.org/archive/html/gnustep-dev/2019-08/msg00019.html >>> (I couldn't test this, because the current x86_64 builds of KDE Neon fail >>> to install on a VirtualBox VM, and older versions don't seem to be >>> available). >>> >>> Manually installing a different desktop on Kubuntu doesn't fix the issue; >>> Text is still missing on GS gui apps when run under GNOME or Window Maker, >>> however, switching GS's backend from Cairo to Art fixes the text. >>> >>> Text displays correctly on Ubuntu 20.04 - even under Plasma - and also on a >>> daily build of Ubuntu Studio 20.10 (Plasma is Studio's installed desktop as >>> of 20.10). >>> >>> The issue's caused by a combination of two factors: >>> >>> A) The Cairo backend sets up fontconfig patterns for font matching by >>> calling the fontconfig library's Fc...Substitute() functions twice on each >>> pattern instead of once: >>> The backend's FCFaceInfo class has two methods, matchedPattern & >>> characterSet, that each call FcConfigSubstitute() & FcDefaultSubstitute(), >>> passing the FCFaceInfo instance member, _pattern, to be modified. Both >>> methods in turn are called from within a single method, -[CairoFontInfo >>> setupAttributes] (itself called from the FcFontInfo initializer): >>> 1. [CairoFontInfo setupAttributes]:[FcFontInfo (super) >>> setupAttributes]:[FCFaceInfo characterSet] >>> 2. [CairoFontInfo setupAttributes]:[CairoFaceInfo fontFace]:[FCFaceInfo >>> matchedPattern] >>> Note that the font face is only generated after the second set of >>> Fc...Substitute() calls. >>> >>> B) The fontconfig library's font-matching functionality behaves differently >>> on Kubuntu vs. other distros (even with the same version installed - >>> Kubuntu 20.04 & Ubuntu 20.04 both have libfontconfig1 2.13.1-2ubuntu3). >>> >>> >>> Alone, neither factor causes the issue, however calling the >>> Fc...Substitute() functions twice on the same pattern on Kubuntu leaves a >>> modified pattern that - when passed to FcFontMatch() - always resolves to >>> the "Noto Color Emoji" font. (That font has no alphabet characters, but >>> does have digits, which explains why only numbers appear in the above >>> linked screenshots). >>> >>> To demonstrate this, the attached C file, fc-pattern-check.c, builds a >>> standalone diagnostic tool using only the fontconfig library - no GNUstep. >>> It creates a fontconfig pattern for matching the "DejaVu Sans" font and >>> makes two sets of calls to Fc...Substitute() & FcFontMatch(), duplicating >>> the calls made by the Cairo backend. After each call, the resulting pattern >>> is printed. >>> >>> The attached textfiles, fcpc_out_kubuntu.txt & fcpc_out_ubuntu.txt, are the >>> outputs from running the fc-pattern-check tool on Kubuntu 20.04 & Ubuntu >>> 20.04. >>> >>> Comparing the two output files, the first difference comes after the first >>> call to FcConfigSubstitute(): On Kubuntu, the pattern has a "rgba" >>> (pixel-format) field inserted - this may not contribute to the incorrect >>> match, but it already shows a different behavior between Kubuntu & Ubuntu. >>> >>> Following the first set of Fc...Substitute() calls, the first call to >>> FcFontMatch() correctly returns a resolved pattern for the "DejaVu Sans" >>> font on both Ubuntu & Kubuntu. When these same first calls are made by the >>> Cairo backend, the resolved pattern's used only to get the font's character >>> set, not to generate the font face for drawing. >>> >>> After the second call to FcConfigSubstitute() on Kubuntu, the pattern's >>> "lang" field for some reason now contains "und-zsye" (emoji locale) before >>> its earlier value, "en" (english). The pattern now also contains a "color" >>> field with a value of "True" (requiring a match to a font that contains >>> color information). With those field values present, the second call to >>> FcFontMatch() returns a resolved pattern for "Noto Color Emoji"; On Ubuntu, >>> its second FcConfigSubstitute() call doesn't add those "lang" & "color" >>> values to the pattern, and its second call to FcFontMatch() correctly >>> returns a "Deja Vu Sans" resolved pattern. >>> >>> >>> The attached patch, libs-back_fontconfig_pattern_fix.diff, fixes the >>> missing text by limiting FCFaceInfo's Fc...Substitute() & FcFontMatch() >>> calls to once per pattern. The resolved pattern returned by FcFontMatch() >>> is now stored in FcFaceInfo's _pattern member (which previously only held a >>> pre-matched pattern), and a new bool member, _patternIsResolved, keeps >>> track of _pattern's pre-matched/resolved state. >>> >>> The characterSet method now gets the resolved pattern by calling the >>> matchedPattern method instead of calling the fontconfig functions directly; >>> Outside of the initializer, dealloc, & matchedPattern methods, the _pattern >>> member is now only accessed by the displayName method (which just reads the >>> pattern's fullname, postscriptname, & style fields - if those were present >>> in the pre-matched pattern, they should remain in the resolved pattern), so >>> there should be no side-effects from storing a resolved pattern instead of >>> a pre-matched pattern in the _pattern member. >>> >>> Loading a large set of fonts will probably also go faster now, as >>> FcFontMatch() is only called half as often. >>> >>> Cheers, >>> >>> Josh >>> >>> >>> <fc-pattern-check.c> <fcpc_out_kubuntu.txt> <fcpc_out_ubuntu.txt> >>> <libs-back_fontconfig_pattern_fix.diff> >> >> >> >
