Terminus font is completely broken with terminus-fonts-4.48-5.fc32.noarch. See the screenshot at http://tpopela.fedorapeople.org/terminus-broken.png.
The bug happens in Fedora 32 Silverblue, and use rpm-ostree to install terminus-fonts. After the user run `fc-cache -fvr`, the terminus fonts appears in the preference dialog.
Well, this is caused by 0 timestamp on ostree system. the scenario leading up to this issue is: 1. fc-cache create a cache when installing a font; cache contains timestamp and timestamp is used to detect an update on the target directory. if the directory timestamp is different compared to one in a cache, cache will be updated. 2. ostree resets timestamp to 0 3. when running fontconfig-aware applications, all caches is basically updated due to the above, except it has already been done since last install of fonts. i.e. not if there are valid caches in user cache directory. 4. considered users caches is newer than system caches due to the above and has priority to be used. 5. When going to install a new font package on this state, 3) won't happen because of 4). plus, in general, parent cache is going to be updated when installing a new font on new directory though, this won't happen. thus, fontconfig doesn't recognize a directory newly created and then can't find out fonts. I'm not sure what is better to fix. we may have some options: 1. restore timestamp for caches; everything will works back. but there may be a problem from ostree POV. dunno. 2. stop detecting updates and update caches; may see similar problem when installing fonts manually on user side. 3. stop updating caches for system directories; somewhat sounds realistic to me but this needs to assume fc-cache is run in a timely manner. which isn't acceptable somewhat from upstream POV. 4. any more idea?
Think of 3) as a solution/workaround for SB specific, we could assume that caches having 0 timestamp is always the latest because updates of all the files under /usr won't appear without reboot on SB and /usr is read-only, and fc-cache is triggered on %transfiletrigger* in fontconfig rpm. So it should reasonably works for SB.
I've just built the testing package of fontconfig at https://copr.fedorainfracloud.org/coprs/tagoh/fontconfig/.
Ah, well, my comments are basically based on Peng Wu's comment at comment#2 (which is basically same to Bug#1750891) but it seems not what the original report claims. That is because terminus-fonts contains two format and Pango/freetype doesn't support synthesizing the legacy bitmap fonts for Italic. that's why we wanted to make it sub-packaged to avoid issues. We may have two options to fix: 1. Separate packages for both OTB and the legacy bitmap 2. Drop legacy bitmap (at least for rawhide according to new font packaging guidelines) 3. Disable embolden flag for certain apps I don't know if 2) is really a good idea for f32 though. anyway, this isn't something we can deal with fontconfig itself. reassigning back to terminus-fonts.
Created attachment 1681683 [details] F31 and F32 state: broken invented italic variant, the other three variants look ok
If I remove the all *.pcf.gz fonts, I can see correct rendering for Italic font on Fedora 32.
I have updated my F31 system to F32 yesterday specifically for reproducing this issue. However, my gnome-terminal font selection dialog behaves exactly the same on F32 as it did on F31. It shows four font variants, two of which are actually provided by the terminus-fonts package, and two of which are invented by the fonts software stack for some reason: Terminus Medium Terminus Bold <series of unicode hex code glyphs> Terminus Bold Italic Anyway, the reporter of this bug is showing something *very* different: His gnome-terminal font selection dialog shows four apparent font variants in a very diffent way: <series of rectangles> <series of rectangles> <series of unicode hex code glyphs> <series of rectangles> (BTW, I am still looking for the proper term for those unicode hex code glyphs. If you know that term, please let me know.) I have removed the terminus-fonts package, and automagically the gnome-terminal terminal and the gnome-terminal font selection dialog have changed to stop including terminus. After re-installing the terminus-fonts package, both have automagically started showing terminus fonts again. This behaviour is the same both with the older terminus-fonts-4.48-3.fc32.noarch package (with updates-testing disabled) and (with updates-testing enabled) the newer terminus-fonts-4.48-5.fc32.noarch package. I interpret this as the font installation and removal working very well and as intended, and that ostree is messing up those automagical updates to the state of the font set. So it looks as if ostree/fontconfig or something along those lines is responsible for the reporter's issue and I cannot see what the terminus-fonts package could do about this. So either this bug needs to be address by ostree/fontconfig/something or I just close it for terminus-fonts. That the fonts software stack insists on inventing a broken italic version of a font which explicitly choses not to ship an italic version is an *entirely* *different* *issue*, and not the topic of this bug. However, nobody needs to select those broken italic version from the font selection box, as the fonts actually provided by terminus-fonts are in perfect working order. The user experience is certainly better if you install "terminus-fonts" if you want to use the Terminus font inside, say, your gnome-terminal and emacs, and just ignore the obviously broken italic font variant. The alternative is a separate package with legacy fonts for Emacs, and the user having to find out about actually needing the legacy variant package, then installing that legacy variant package in addition to the standard one to have Terminus for both gnome-terminal and Emacs, and then they see the broken italic font variants in the gnome-terminal font selection dialog again.
So... is this actually just a duplicate of <https://bugzilla.redhat.com/show_bug.cgi?id=1750891>? FWIW, I have just created a bug describing the italic issue at <https://bugzilla.redhat.com/show_bug.cgi?id=1827905> because regardless of whether the legacy fonts are inside terminus-fonts or split off into terminus-fonts-legacy-foo, that issue will stay with us for a few more years until software using the legacy font rendering is actually out of circulation.
(In reply to Hans Ulrich Niedermann from comment #8) > I have removed the terminus-fonts package, and automagically the > gnome-terminal terminal and the gnome-terminal font selection dialog have > changed to stop including terminus. After re-installing the terminus-fonts > package, both have automagically started showing terminus fonts again. This > behaviour is the same both with the older terminus-fonts-4.48-3.fc32.noarch > package (with updates-testing disabled) and (with updates-testing enabled) > the newer terminus-fonts-4.48-5.fc32.noarch package. Right. that should works on WS. and is the off topic for this issue and misled by comment#1. please ignore it. > However, nobody needs to select those broken italic version from the font > selection box, as the fonts actually provided by terminus-fonts are in > perfect working order. The user experience is certainly better if you > install "terminus-fonts" if you want to use the Terminus font inside, say, > your gnome-terminal and emacs, and just ignore the obviously broken italic > font variant. The alternative is a separate package with legacy fonts for > Emacs, and the user having to find out about actually needing the legacy > variant package, then installing that legacy variant package in addition to > the standard one to have Terminus for both gnome-terminal and Emacs, and > then they see the broken italic font variants in the gnome-terminal font > selection dialog again. Right.. In that sense, applications which are going to deal with un-supported format should ignore them in their code to query fonts, in general at least. (In reply to Hans Ulrich Niedermann from comment #9) > So... is this actually just a duplicate of > <https://bugzilla.redhat.com/show_bug.cgi?id=1750891>? No, I don't think so.
Tomas, would you mind if I attached your screenshot from https://tpopela.fedorapeople.org/terminus-broken.png to this bug?
No problems at all Hans.
Created attachment 1685173 [details] The original poster
Let me try to summarize this bug's discussions with my limited understanding of the font software stack: 1. The original poster mainly had an issue with fontconfig/ostree which resulted in his gnome-terminal dialog showing only small rectangular glyphs instead of "Terminus Medium", "Terminus Bold", and the invented-by-the-software-stack "Terminus Bold Italic". This appears to have been solved over in fontconfig/ostree land, so the main part of this bug looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1750891 to me, and definitively outside the scope of what the terminus-fonts package is responsible for. 2. The original poster also had a completely different issue with what Akira TAGOH calls Pango/freetype in which the presence of *.pcf.gz files breaks the "Terminus Italic" invented by what appears to be pango/freetype. As this issue has been reappearing and is going to reappear until the last piece of software using pre-pango font rendering has disappeared from at least Fedora, if not the planet, I have created https://bugzilla.redhat.com/show_bug.cgi?id=1827905 to track that part. So the secondary part of this bug looks like a duplicate of 1827905 to me. Akira TAGOH, sorry to bother you again here, but you appear to be the one with the knowledge to actually help with this. I would not even know where to start reading documentation. You have mentioned above "Disable embolden flag for certain apps". Where would this flag be located? And in this case, terminus-fonts already provides "Terminus Medium" and "Terminus Bold", so I cannot se where "embolden" should play a part here, but might there be a "italicize" flag somewhere? Maybe an "italicizes flag for certain fonts"? That could prevent the secondary issue number 2. Also, is there a third issue discussed in this bug which I have completely overlooked?
Sorry for late response, I was away from my computer for a while. (In reply to Hans Ulrich Niedermann from comment #14) > Let me try to summarize this bug's discussions with my limited understanding > of the font software stack: > > 1. The original poster mainly had an issue with fontconfig/ostree which > resulted in his gnome-terminal dialog showing only small rectangular glyphs > instead of "Terminus Medium", "Terminus Bold", and the > invented-by-the-software-stack "Terminus Bold Italic". This appears to have > been solved over in fontconfig/ostree land, so the main part of this bug > looks like a duplicate of > https://bugzilla.redhat.com/show_bug.cgi?id=1750891 to me, and definitively > outside the scope of what the terminus-fonts package is responsible for. Not exactly. this isn't ostree specific. when system has same font families in different formats, fontconfig prioritize them from various aspects though, FC_FONTFORMAT which is a priperty in cacche containing the font format is one of factors. but it do compare strings so far. so there are the case that fontconfig returns a bitmap font as the best font instead of OpenType and applications didn't just support the synthethic emboldening for such fonts. I thought so far fontconfig could intentionally gives a lower priority to bitmap fonts than OpenType fonts though, someone may also intentionally wants to use bitmap fonts rather than OpenType fonts. I need to think about how to implement it. thus, conditionally installing one of them in the packaging level was a workaround. > 2. The original poster also had a completely different issue with what > Akira TAGOH calls Pango/freetype in which the presence of *.pcf.gz files > breaks the "Terminus Italic" invented by what appears to be pango/freetype. > As this issue has been reappearing and is going to reappear until the last > piece of software using pre-pango font rendering has disappeared from at > least Fedora, if not the planet, I have created > https://bugzilla.redhat.com/show_bug.cgi?id=1827905 to track that part. So > the secondary part of this bug looks like a duplicate of 1827905 to me. Right. but that "the secondary part" is actually main thing for this. the comment#1 and relevant comments were the off-topic for this. > Akira TAGOH, sorry to bother you again here, but you appear to be the one > with the knowledge to actually help with this. I would not even know where > to start reading documentation. Sorry for that. that is one of my tasks I need to improve fontconfig documentation. > You have mentioned above "Disable embolden flag for certain apps". Where > would this flag be located? And in this case, terminus-fonts already > provides "Terminus Medium" and "Terminus Bold", so I cannot se where > "embolden" should play a part here, but might there be a "italicize" flag > somewhere? Maybe an "italicizes flag for certain fonts"? That could prevent > the secondary issue number 2. Well, enumerating everything in config isn't actually realistic but one could do for example (not tested): <match> <test name="family"><string>Terminus</string></test> <test name="prgname"><string>gnome-terminal</string></test> <edit name="fontformat" mode="prepend"><string>TrueType</string></edit> </match> As I commented for 1., this should be fixed/improved in fontconfig as well...
Created attachment 1690664 [details] OP gnome-terminal font selection dialog only with empty rectangles
I've encountered this issue recently after updating to F32 from F30. Is there a suggested workaround? I really would like to continue using Terminus as my system font, and the Terminus TTF font is blurry :( Some additional notes: - Despite the fact that only the Italic version of Terminus is broken in my font selection dialog (using lxappearance), GTK apps such as the Gnome file manager and Eclipse are completely broken when Terminus is used as the system font. Only glyphs appear. - Certain GTK applications don't seem to break (such as Firefox and HexChat). They seem to handle this bug better? If someone could find out what these applications are doing better, then other applications could make a workaround update until the core issue is resolved. I work on Eclipse IDE and would be willing to try and get this workaround into Eclipse. - Removing all *.pcf.gz fonts didn't seem to fix the issue for me, and worst, it broke the Terminus font for KDE Plasma. - QT (or more specifically, KDE) applications seem to be handling this better. All my KDE apps still look fine, and the font selection dialog does not suggest the italics version of Terminus, and labels it Terminus [xos4]. I'll attach some related screenshots.
Created attachment 1691588 [details] GTK apps are broken This is noteworthy because, although only the italics version of the font seems to be glyphs/boxes, a lot of GTK applications are unable to correctly display the font. This also affects Eclipse and many Gnome applications.
Created attachment 1691589 [details] Firefox (and HexChat) seem to handle the font better, and aren't broken. Learning why these applications aren't completely broken could be useful in finding a temporary workaround (even if it would be on a per-application basis).
Created attachment 1691590 [details] Italics font broken in GTK font selection dialog (lxappearance) This might be redundant and more related to Bug 1827905, but I figured I'd mention it.
Created attachment 1691591 [details] Other versions (non-italics) of Terminus look fine
Created attachment 1691592 [details] KDE font selection dialog KDE seems to be handling this better, or at least differently. Note the [xos4].
Peng Wu, Why was the weight of Terminus.otb changed to 100 (Medium)? the original weight should be 80 (Regular).
Akira TAGOH, the ter-u12n.bdf file contains 'WEIGHT_NAME "Medium"', I think its weight is Medium in the source font. Maybe nautilus uses similar code like hexchat, but fontconfig returns different fonts format randomly. Andrew Obuchowicz, could you try to delete ter-*.pcf.gz files, and re-generate the fontconfig cache using `fc-cache -fvr`? I delete the ter-*.pcf.gz files, and re-generate the fontconfig system cache and user cache, maybe also re-login, it seems nautilus works with "Terminus Regular".
Hmm, interesting. PCF files weighted as Regular like ter-[1-9c-gik]*.pcf.gz was converted from the same source of BDF files. there might be some idea there to have *Regular* otb fonts. BTW putting "Regular" into style for current Terminus*.otb is completely wrong. that is Medium as the weight property indicates it is 100. plus, when applications doesn't specify any weight property into query, the default value will be Regular (80). but no Regular weight available in Terminus*.otb. I'll file a separate bug for that. So if you do "fc-match Terminus", the best font will be bitmap fonts and no synthetic emboldening supported for them. thus, hex code glyphs.
(In reply to Peng Wu from comment #24) > Maybe nautilus uses similar code like hexchat, but fontconfig > returns different fonts format randomly. > > Andrew Obuchowicz, could you try to delete ter-*.pcf.gz files, > and re-generate the fontconfig cache using `fc-cache -fvr`? > > I delete the ter-*.pcf.gz files, and re-generate the fontconfig > system cache and user cache, maybe also re-login, it seems > nautilus works with "Terminus Regular". I deleted the ter-*.pcf.gz files in /usr/share/fonts/terminus, and ran fc-cache -fvr. While I was logged in, most of KDE Plasma's text became messed up however this was fixed when I logged out and logged in. Unfortunately, Nautilus (now renamed to Files?) still shows Glyphs even thought I have "Terminus Regular" selected as my GTK system font in lxappearance. HOWEVER, when I check my ~/.config/gtk-3.0/settings.ini, I can see that Terminus regular is not actually set. Instead, Terminus Medium is being set. [Settings] gtk-button-images=1 gtk-cursor-theme-name=Adwaita gtk-cursor-theme-size=0 gtk-enable-event-sounds=1 gtk-enable-input-feedback-sounds=1 gtk-font-name=Terminus Medium 12 <---------------------- gtk-icon-theme-name=breeze-dark-red gtk-menu-images=1 gtk-modules=appmenu-gtk-module gtk-shell-shows-menubar=1 gtk-theme-name=Abrus-dark gtk-toolbar-icon-size=GTK_ICON_SIZE_LARGE_TOOLBAR gtk-toolbar-style=GTK_TOOLBAR_BOTH gtk-xft-antialias=1 gtk-xft-hinting=0 gtk-xft-hintstyle=hintnone gtk-xft-rgba=rgb Keep me updated, I'm eager to see this fixed :D (And will help test any fixes needed!).
(In reply to Peng Wu from comment #24) > Maybe nautilus uses similar code like hexchat, but fontconfig > returns different fonts format randomly. To clarify, it's not random. the default weight is Regular and bitmap version of Terminus supports that weight despite not supporting Regular weight in OTB. see: $ FC_DEBUG=3 fc-match Terminus ... Font 3958 Pattern has 27 elts (size 27) family: "Terminus"(w) familylang: "en"(w) style: "Regular"(w) stylelang: "en"(w) fullname: "Terminus Regular"(w) fullnamelang: "en"(w) slant: 0(i)(w) weight: 100(f)(w) width: 100(f)(w) pixelsize: 12(f)(w) 18(f)(w) 22(f)(w) 28(f)(w) 16(f)(w) 14(f)(w) 20(f)(w) 24(f)(w) 32(f)(w) spacing: 100(i)(w) foundry: "UNKN"(w) antialias: False(w) file: "/usr/share/fonts/terminus-fonts/Terminus.otb"(w) index: 0(i)(w) outline: False(w) scalable: False(w) charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff 0001: ffffffff ffffffff ffffffff ffffffff 6005c040 00e00000 001fe000 f031fffc 0002: 0f000000 008c0000 0b100000 00040000 00040000 38000000 3b0000c0 00000000 0003: 00001dff 00000200 00000000 00000000 ffffd7f0 fffffffb 00227fff 007f0000 0004: ffffffff ffffffff ffffffff 00000c0c 3fff0000 0fcfcc3f ffff8007 033ffffc 0005: 00000000 00000000 00000000 00000000 00000000 00000000 ffff0000 000007ff 001e: 00003000 00f00000 000000ff 00003000 00000000 33000000 00003c00 03000030 0020: ffffffff 560d0047 00000000 fff30000 05ff7fff 00005480 00000000 00000000 0021: 2460c004 00200054 00000000 00000000 003f0000 08200150 003f1800 00000000 0022: c67c3ff9 000007a0 00000100 00000c33 000000cc 00000020 0000000c 00000000 0023: 02010f05 00000003 00000000 00000000 f8000000 3c00fbff 00010000 00000000 0024: 00003e00 00000010 00000000 00000000 00000000 00000000 00000000 00000000 0025: ffffff0f ffffffff ffff0fff ffffffff ffcfffff 14445001 03008c51 00000000 0026: 00000000 1c000000 00000005 00000c69 00000000 00000000 00000000 00000000 0027: 01980000 00000000 00000000 00000000 00000000 00000000 00000000 00000f00 0028: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 002e: 00000000 00001000 00000000 00000000 00000000 00000000 00000000 00000000 00e0: 00000000 00000000 00000000 00000000 00000000 000f0007 00000000 00000000 00f6: 00000000 00000000 00000000 00000000 00000000 40000000 00000000 00000000 00ff: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 20000000 (w) lang: aa|af|av|ay|az-az|ba|bm|be|bg|bi|bin|br|bs|bua|ca|ce|ch|chm|co|cs|cv|da|de|el|en|eo|es|et|eu|fi|fj|fo|fr| fur|fy|gd|gl|gn|gv|haw|he|ho|hr|hu|ia|ig|id|ie|ik|io|is|it|kaa|ki|kk|kl|kum|kv|kw|ky|la|lb|lez|ln|lt|lv|mg|mh|mi|mk|mo| mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|os|pl|pt|rm|ro|ru|sah|se|sel|sh|sk|sl|sm|sma|smj|smn|sms|so|sq|sr|ss|st|sv|sw|tg|tk| tl|tn|to|tr|ts|tt|tw|tyv|uk|uz|vo|vot|wa|wen|wo|xh|yap|yi|zu|ak|an|crh|csb|fat|fil|hsb|ht|jv|kj|ku-tr|kwm|lg|li|mn-mn|m s|na|ng|nv|pap-an|pap-aw|rn|rw|sc|sg|sn|su|ty|za(w) fontversion: 65536(i)(w) fontformat: "TrueType"(w) decorative: False(w) postscriptname: "Terminus"(w) color: False(w) symbol: False(w) variable: False(w) fonthashint: False(w) ... weight: 20000 80(i)(s), 100(f)(w) ... Score 0 0 0 0 0 0 0 0 0 2000 1001 0 0 0 0 500 0 0 20000 0 0 0 0 0 0 2.14742e+12 ... Font 3960 Pattern has 28 elts (size 28) family: "Terminus"(w) familylang: "en"(w) style: "Regular"(w) stylelang: "en"(w) fullname: "Terminus Regular"(w) fullnamelang: "en"(w) slant: 0(i)(w) weight: 80(f)(w) width: 100(f)(w) pixelsize: 12(f)(w) spacing: 110(i)(w) foundry: "xos4"(w) antialias: False(w) file: "/usr/share/fonts/terminus-fonts-legacy-x11/ter-112n.pcf.gz"(w) index: 0(i)(w) outline: False(w) scalable: False(w) charset: 0000: ffffffff ffffffff ffffffff ffffffff dffe5ffd ffffffff ffffffff ffffffff (w) lang: aa|ay|bi|br|ch|da|de|en|es|eu|fj|fo|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|oc|om|p t|rm|sma|smj|so|sq|ss|st|sv|sw|tl|ts|uz|vo|wa|xh|yap|zu|an|fil|ht|jv|kj|kwm|li|ms|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|za (w) fontversion: 0(i)(w) fontformat: "PCF"(w) decorative: False(w) postscriptname: "Terminus"(w) color: False(w) symbol: False(w) variable: False(w) fonthashint: False(w) ... weight: 0 80(i)(s), 80(f)(w) ... Score 0 0 0 0 0 0 0 0 0 2000 1001 0 0 0 0 500 0 0 0 0 0 0 0 0 0 2.14748e+12 Again, look at this: Score 0 0 0 0 0 0 0 0 0 2000 1001 0 0 0 0 500 0 0 20000 0 0 0 0 0 0 2.14742e+12 Score 0 0 0 0 0 0 0 0 0 2000 1001 0 0 0 0 500 0 0 0 0 0 0 0 0 0 2.14748e+12 Only difference in score is weight. if requirements is "Terminus" only, this behavior *is* correct. The problem here would be either or all of: * [font] No Regular weight for OTB * [font] Lying style as Regular despite being Medium weight (Bug#1839689) * [apps] No fontformat=truetype,cff in query despite not supporting legacy bitmap format In fact, these queries works fine: $ fc-match Terminus:weight=medium Terminus.otb: "Terminus" "Regular" $ fc-match Terminus:fontformat=truetype,cff Terminus.otb: "Terminus" "Regular"
Some updates: Apparently "Medium" in BDF and "Medium" in OpenType looks different. XLFD deals with "Medium" as "Regular". in this sense, bdftopcf do the right job. but fonttosfnt not. For a workaround, we need to apply the following config to fix the weight: <fontconfig> <match target="scan"> <test name="family"><string>Terminus</string></test> <test name="style"><string>Regular</string></test> <test name="weight"><const>medium</const></test> <edit name="weight" mode="assign"><const>regular</const></edit> </match> </fontconfig> After this, "fc-match terminus" works as expected: $ fc-match terminus Terminus.otb: "Terminus" "Regular" as well as Terminus Italic on the font picker.
Created testing package on copr: https://copr.fedorainfracloud.org/coprs/tagoh/terminus-fonts/
and PR for this: https://src.fedoraproject.org/rpms/terminus-fonts/pull-request/2
Awesome work. I have checked that this produces better fonts, even though I have not tried to understand all the details yet. Merged the PR, and building packages for F32 and F33/rawhide right now. Will take a look at the details later.
FEDORA-2020-a2c3a268f1 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2c3a268f1
FEDORA-2020-dce0e3e11c has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-dce0e3e11c
FEDORA-2020-a2c3a268f1 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-a2c3a268f1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2c3a268f1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-dce0e3e11c has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-dce0e3e11c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-dce0e3e11c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I can confirm the new patch works correctly :)! Thank you very much Akira, and everyone who helped getting this resolved!
Akira TAGOH, I created one patch to recognize Medium Weight as Regular style. URL: https://gitlab.freedesktop.org/pwu/fonttosfnt/-/commit/7096c58f3fe3b6c79508cb16daac5c5bb2f042e7 Here are the Fedora 32 copr testing repo. URL: https://copr.fedorainfracloud.org/coprs/pwu/fonttosfnt/ If this patch is okay, I will create upstream merge request soon.
terminus-fonts-4.48-7.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
terminus-fonts-4.48-7.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.
Peng Wu, Thank you for working on this. If Medium has been abused as a Regular synonym in BDF files (to the point that XLFD treats them the same) that is the correct thing to do *for* *BDF* *files*. However, it is not sufficient to get a safe OpenType result. Medium and Regular are most definitely *not* synonyms in the OpenType and CSS specs. And, because various generations of software will select fonts by Name *or* Weight, or some mix of both (and various iterations of the CSS and OpneType specs have encouraged one mode at the expense of the other, then changed their mind), it is not sufficient to adjust Weight value only. You need to adjust the Weight value *and* the style name and make sure they are coherent with one another, or bad things will happen®.
(In reply to Peng Wu from comment #37) > Akira TAGOH, I created one patch to recognize Medium Weight as Regular style. > > URL: > https://gitlab.freedesktop.org/pwu/fonttosfnt/-/commit/ > 7096c58f3fe3b6c79508cb16daac5c5bb2f042e7 > > Here are the Fedora 32 copr testing repo. > > URL: https://copr.fedorainfracloud.org/coprs/pwu/fonttosfnt/ > > If this patch is okay, I will create upstream merge request soon. Yes, LGTM. (In reply to Nicolas Mailhot from comment #40) > And, because various generations of software will select fonts by Name *or* > Weight, or some mix of both (and various iterations of the CSS and OpneType > specs have encouraged one mode at the expense of the other, then changed > their mind), it is not sufficient to adjust Weight value only. You need to > adjust the Weight value *and* the style name and make sure they are coherent > with one another, or bad things will happen®. Fortunately or unfortunately fonttosfnt already sets Regular as style name. no need changes further.
Okay, upstream merge request is created. URL: https://gitlab.freedesktop.org/xorg/app/fonttosfnt/-/merge_requests/8