Description of problem: I use terminus fonts in gvim, and they have worked fine in the past. But now, they are not recognized, and instead glyphs are shown for characters. When I bring up the font selection popup, they are not there. But, the terminus-fonts package is installed, and the fonts are there. They still work in the virtual consoles, though that is a different package, terminus-font versus terminus-fonts on X11. Version-Release number of selected component (if applicable): Name : vim-X11 Epoch : 2 Version : 8.1.1912 Release : 1.fc31 Architecture: x86_64 How reproducible: every time Steps to Reproduce: 1. Edit a text file with set gfn=Terminus\ 12 in the .gvimrc file 2. 3. Actual results: Page full of glyphs Expected results: Page full of characters. Additional info: I am able to bring up the font selection menu and select Anonymous, and then see a page of characters. As a workaround I put set gfn=Anonymous\ 12 in .gvimrc, and it works, but I prefer the terminus fonts.
Hi stan, thank you for reporting the issue! I have the same Vim version in F29 as it is in my rawhide machine, but it works for me on F29, but I experience the same issue as you in rawhide. Since Vim is on the same version, I would say it will require more investigation from terminus-fonts side - I saw it has different version than it is in F29, so maybe the rebase broke something.
That makes sense. It was working for me in F31; I wonder if it was the mass rebuild that caused the problem? My terminus-fonts package wass Version : 4.47 Release : 6.fc31 Architecture: noarch There is an update to 4.48, but for some reason it doesn't update; beta freeze? So, I downloaded the 4.48 src.rpm and built it, and installed it, and the problem was still there. So then I downloaded 4.47.4 src.rpm from f30 and built it, and the problem was still there. I then downloaded the 4.46.2 src.rpm from f29 and built it. Problem is still there. I think you are right, there is something different in the build or run environment causing this. But is it causing it in the terminus font package or gvim? Or is it a library they are calling that has a subtle bug?
I have read somewhere recently about something changing in fontconfig. I need to investigate that. And BTW, the package names are terminus-font (upstream package name, not used in Fedora packages) terminus-fonts (Fedora package containing the X11 fonts, Fedora insists on the plural "-fonts") terminus-fonts-console (Fedora package containing the console fonts) terminus-fonts-grub (Fedora package containing the grub2 fonts)
Confirmed this not to be an issue on F30: terminus-fonts-4.47-5.fc30.noarch fontconfig-2.13.1-8.fc30.x86_64 vim-X11-8.1.1912-1.fc30.x86_64 Not an issue on F30 either with terminus-fonts-4.48: terminus-fonts-4.48-1.fc30.noarch fontconfig-2.13.1-8.fc30.x86_64 vim-X11-8.1.1912-1.fc30.x86_64 I guess I need to upgrade this machine to F31 to examine and fix this in the next few days.
Finally got around to updating one system to F31 beta. I can reproduce the issue on "Gnome" sessions (i.e. Wayland) on F31. Both gvim and gnome-terminal show only hex codes in such a session instead of Terminus characters. The problem does not appear in "Gnome on Xorg" sessions on F31. Will investigate further.
Thanks!
*** Bug 1754492 has been marked as a duplicate of this bug. ***
This comment just records some facts. It does not find the problem or even fix it (yet). There are two font systems: The old X11 one, and the newer fontconfig one. The X11 font system can be queried with xlsfonts, and the fonts are then called something like $ xlsfonts | grep -i terminus [...] -xos4-terminus-medium-r-normal--24-240-72-72-c-120-iso10646-1 [...] The fontconfig font system can be queried with fc-list $ fc-list | sort | grep -i terminus [...] /usr/share/fonts/terminus/ter-x12n.pcf.gz: Terminus:style=Regular [...] A noticeable difference is that xlsfonts lists 252 lines for Terminus, whereas fc-list only lists 36 lines (the ter-x??[bn] variants). As my emacs setup still uses the old X11 font system (the "xos4" font family in the setting gives that much away), emacs still shows its text in Terminus on a "Gnome on Xorg" session. (No, I am *NOT* saying gvim users should switch to emacs :-) Both gvim and emacs cannot be started in a Weston wayland session, as they both appear to look for an X11 DISPLAY. The same applies to xlsfonts. However, fc-list lists the same 36 lines of Terminus fonts in a Weston wayland session. Both gvim and emacs can be started in a "Gnome" (i.e. on Wayland) and a "Gnome on Xorg" (i.e. Xorg on Wayland) session. In both types of Gnome (with and without Xorg) sessions, the results of fc-list and xlsfonts appear to be identical. More to follow as and when I find it out.
konsole (the KDE terminal emulator) both on Gnome and on KDE/Plasma can display text with the Terminus font and also lets users choose Terminus from the list of fonts. So, assuming the Qt font stuff does not still use the old X11 font handling, Qt appears to do something right with fontconfig, which gtk/pango (in gnome-terminal and gvim) do are doing wrong.
I think this is likely due to latest pango/harfbuzz dropping support for bitmap fonts. See bug 1753295 for more details.
This makes sense.(In reply to Jens Petersen from comment #10) > I think this is likely due to latest pango/harfbuzz dropping support for > bitmap fonts. > > See bug 1753295 for more details. Ah. The cause. Thanks a lot for the notification. I was suspecting something like that, but thank you very much for pointing at the specific place. As for remedies, I will need to try the fonttosfnt based trick from bug 1753295. It will be interesting to see whether this can work while keeping old X11 font based programs working.
For people looking for quick relief, I've now rebuilt terminus-fonts using the fonttosfnt approach from bug 1753295 comment 4 into https://copr.fedorainfracloud.org/coprs/adelton/fedora-fixes/.
That worked, thanks.
For the record, I've filed the same issue for LucidaTypewriter Sans as bug 1767384 now.
Thanks for creating the Fedora copr repo!
The next edition of Fedora font packaging guidelines will forbid packaging of bitmap fonts in non-opentype format for this reason https://pagure.io/fork/nim/packaging-committee/raw/7357efb01b0333a57eb064eacc1f0d17bcbd47ff/f/guidelines/modules/ROOT/pages/FontsPolicy.adoc Sorry that it takes me so long to finish wrapping them up (You need the Asciidoctor.js Live Preview extention to see a pretty-formatted version of the guidelines) Fedora packaging guidelines have been asking font packagers and authors to convert to OpenType for more than a decade, so the only change is that SHOULD becomes a MUST
@Nicolas Mailhot Why this was not announced/discussed for accepted F30 features (to remind maintainers and developers, and prepare a transition plan) NOR for F31 to announce, that support for bitmap fonts is being removed *right now*? In case of other such transitions (e.g. yum->dnf, python2->python3, cgroupsv1->cgroupsv2) the change was well announced in advance. As of right now, repackaging Terminus is not enough - the .otb font has whitespacing issues, making it render differently from the original font.
@Patryk Obara the move to a single text layouting engine built around the OpenType format was announced in 2006, and documented in 2007 in Fedora font packaging guidelines. So people had more than 20 releases to prepare. https://bugzilla.redhat.com/show_bug.cgi?id=1753295#c53 That bitmap users chose to disbelieve this monumental amount of work would ever be finished (it took 13 years to be done) is not anyone else’s fault. The final stages of the move to OpenType happen upstream, they’re not a Fedora decision.
@Nicolas Mailhot - bitmap font users did not "chose to disbelieve". Bitmap font users did not know, that this change is being planned. This problem was already unearthed by Arch users in May (and, again, NOT COMMUNICATED for upcoming Fedora release), then users adopting Fedora 31 - and you will face wave after wave of disgruntled users, as distributions will adopt new Pango release.
@Patryk Obara There are tens if not hundreds of tickets in this bugzilla I opened in 2007 to get people to move and fix things while there was time Most of them were ignored or closed with comments like "I’ll believe I’ll need to fix things when things break". And now they are breaking. As announced. Complain at someone else there was no communication. At one point I stopped nagging people to tell them the clock was running. The maintainers who wanted to make an effort made it years ago.
(In reply to Jan Pazdziora from comment #12) > For people looking for quick relief, I've now rebuilt terminus-fonts using > the fonttosfnt approach from bug 1753295 comment 4 into > https://copr.fedorainfracloud.org/coprs/adelton/fedora-fixes/. Karma! Thanks.
I also face this issue, but the “Noto Mono” also looks weird: https://vi.stackexchange.com/questions/21754/terminus-font-broken-in-gvim-on-fedora-31
You might want to file separate bugzilla for the Noto Mono. Sadly, we have yet to receive some guidance (in bug 1753295) how to fix those fonts in general to work with latest Pango in Fedora 31 but maybe the Noto fonts maintainer will have some trick to fix their font.
I'm not entirely sure we're running into the same whitespacing issue, but the Bug 1753295 comment #4 method resulted in partly cut-off characters in urxvt. Instead, this works: fonttosfnt -c -g 2 -m 2 -o terminusn.otb ter-u*n.bdf fonttosfnt -c -g 2 -m 2 -o terminusb.otb ter-u*b.bdf The -c flag prevents attempted cropping, which is probably the cause of the problem. The -b flag is apparently unnecessary and only increases file size. The normal and bold faces are in separate files because otherwise both gvim and urxvt apply some kind of automatic emboldening transformation on some syntax hilights, which looks disgusting at size 9. All of this is with the fonttosfnt from xorg-x11-font-utils.
Thanks, I just updated the wiki page https://fedoraproject.org/wiki/BitmapFontConversion . Before we test on multiple CPU architecture, I prefer to keep the "-b" option.
(In reply to Peng Wu from comment #25) > Thanks, I just updated the wiki page > https://fedoraproject.org/wiki/BitmapFontConversion . > > Before we test on multiple CPU architecture, I prefer to keep the "-b" > option. If that is intended to be the long-term solution, I can add it to packaging guidelines. But fonttosfnt need to end up in the distribution proper, not a copr (the wiki page can state that a more up-to date version can be found into a particular copr; but at some point the copr will end up unmaintained)
(In reply to Nicolas Mailhot from comment #26) > If that is intended to be the long-term solution, I can add it to packaging > guidelines. But fonttosfnt need to end up in the distribution proper, not a > copr (the wiki page can state that a more up-to date version can be found > into a particular copr; but at some point the copr will end up unmaintained) Okay, I will ask the maintainer to update xorg-x11-font-utils package.
(In reply to Peng Wu from comment #27) > (In reply to Nicolas Mailhot from comment #26) > > If that is intended to be the long-term solution, I can add it to packaging > > guidelines. But fonttosfnt need to end up in the distribution proper, not a > > copr (the wiki page can state that a more up-to date version can be found > > into a particular copr; but at some point the copr will end up unmaintained) > > > Okay, I will ask the maintainer to update xorg-x11-font-utils package. And the guidelines change is here https://pagure.io/fork/nim/packaging-committee/c/b0bcefa3dd757f34dc0392edc5c95cec11525f03
(In reply to Nicolas Mailhot from comment #20) > @Patryk Obara There are tens if not hundreds of tickets in this bugzilla I > opened in 2007 to get people to move and fix things while there was time > > Most of them were ignored or closed with comments like "I’ll believe I’ll > need to fix things when things break". > > And now they are breaking. As announced. Complain at someone else there was > no communication. > > At one point I stopped nagging people to tell them the clock was running. > The maintainers who wanted to make an effort made it years ago. Sorry, Nicolas. I appear to have read those bugs wrongly back then as "switch from bitmap fonts to vector fonts". I cannot remember ever having the faintest idea that those reports could have meant "convert your bitmap fonts to this new format". Anyway, now that this has been cleared up, what remains to do for me is to convert Terminus to the OpenType format without too many conversion errors. No idea yet whether I will use Terminus upstream's Python scripts to generate PCF and then use fonttosfnt, or change upstream's Python scripts to output OpenType, or use Terminus upstream's font sources as input to yet another tool to generate OpenType. I will have to evaluate all of these possibilities, and possibly more. And I will keep generating the font files for the other two formats in the same way (Linux virtual console and grub menu).
I have found two ways to generate *.otb files for Terminus so far. Those are: 1. the fonttosfnt way which generates * one TerminusBold.otb from ter-u*b.bdf and * one TerminusNormal.otb from ter-u*n.bdf with commands like fonttosfnt -b -c -g 2 -m 2 -o TerminusBold.otb ter-u*b.bdf fonttosfnt -b -c -g 2 -m 2 -o TerminusNormal.otb ter-u*n.bdf 2. the fontforge way which generates * one ter-*[bn].otb for every ter-*[bn].bdf with a number of commands like fontforge -lang=ff -c 'Open("ter-u12b.bdf"); Generate("ter-u12b.otb")' At this time, I am inclined towards the fontforge way, as this uses the stock fontforge shipped with Fedora, not from some COPR. Now I am trying to read the current font guidelines, to fish out the information applying for bitmap fonts from amongst instructions using tools not shipped in Fedora at all (ttname), applying to vector fonts only, etc. I still want to maintain backward compatibility with older software which still uses the old fonts through old rendering libraries. Not everyone is using Pango and Gnome, after all.
I think fonttosfnt upstream is reviewing the merge requests, and they may release the tar ball later. Could you combine the fonts with the same family name and style name into one OpenType font? I suspect several OpenType fonts with the same family name and style name may cause problem when selecting the fonts. Maybe we can keep the old fonts for backward compatibility.
Font selection in gnome-terminal does not appear to be a problem here even with many ter-u*b.otb and ter-u*n.otb files in /usr/share/fonts/terminus. So at least for now, I will be going the fontforge route for OTB, and keep the old *.pcf.gz files in /usr/share/fonts/terminus as well. This appears to work for me so far, but let's see what people report when the 4.48-2 package builds hit updates-testing in a few hours. If there is a problem with this many OTB files or any other aspect of the fontforge generated OTB files, we can still change to using fonttosfnt in 4.48-3 later.
FEDORA-2020-619cd50145 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-619cd50145
> Now I am trying to read the current font guidelines, to fish out the > information applying for bitmap fonts from amongst instructions using > tools not shipped in Fedora at all (ttname), applying to vector fonts > only, etc. The current font packaging policy has been badly mangled during (botched) conversion to asciidoc, end never contained a lot of bitmap instructions If you want to work in the guidelines space, start from https://pagure.io/packaging-committee/pull-request/934 that's the version FPC is working on now. (further PRs are welcome) Alternatively, read the old policy in its archived wiki version, you won’t miss all the parts the asciidoc script dropped.
With terminus-fonts-4.48-2.fc31.noarch, Terminus Medium 8 fonts works fine for me with xfce4-terminal-0.8.8-2.fc31.x86_64 and pango-1.44.7-1.fc31.x86_64. Thank you.
I just noticed in the gnome-terminal font selection dialog, that instead of the expected fonts Terminus Bold Terminus Medium it also lists [Terminus Medium] in numeric glyphs Terminus Bold Italic The [Terminus Medium] in the numeric glyphs probably should be "Terminus Medium Italic" according to whatever piece of software which has invented these italic versions of Terminus Medium and Terminus Bold. I have no idea which piece of software invents these italic versions. It might be fontforge during the bdf to otb conversion, it might be pango/harfbuzz, or it might be something else. In any case, the invented [Terminus Medium] in numeric glyphs font causes numeric glyphs to be rendered. I hope I can find a flag I change in the font files somewhere to prevent the invention of those two italic font variations. Package versions in use: $ rpm -q harfbuzz pango gnome-terminal terminus-fonts fontforge | grep -v i686 | sort fontforge-20190801-1.fc31.x86_64 gnome-terminal-3.34.2-1.fc31.x86_64 harfbuzz-2.6.1-2.fc31.x86_64 pango-1.44.7-1.fc31.x86_64 terminus-fonts-4.48-1.fc31.3.noarch $
(In reply to Hans Ulrich Niedermann from comment #36) > I just noticed in the gnome-terminal font selection dialog, that > instead of the expected fonts > > Terminus Bold > Terminus Medium > > it also lists > > [Terminus Medium] in numeric glyphs > Terminus Bold Italic it should only list one font, Terminus, with lots of styles (Regular, Medium, Bold, Bold Italic, etc) However, that’s not an unexpected result of conversion from a legacy format. Legacy formats have very poor (everything, but especially) naming support. Converting to SFNT will usually involve fixing the naming layer (Name ID 16/17, using WWS rules, and Name ID 4, as Family + Style except for regular for which is named Family not family Regular). That’s probably something that could be scripted using fontforge’s python bindings.
(In reply to Nicolas Mailhot from comment #37) > (In reply to Hans Ulrich Niedermann from comment #36) > > I just noticed in the gnome-terminal font selection dialog, that > > instead of the expected fonts > > > > Terminus Bold > > Terminus Medium > > > > it also lists > > > > [Terminus Medium] in numeric glyphs > > Terminus Bold Italic > > it should only list one font, Terminus, with lots of styles (Regular, > Medium, Bold, Bold Italic, etc) > > However, that’s not an unexpected result of conversion from a legacy format. Uhm. This is confusing. The font list for gnome-terminal starts with DejaVu Sans Mono Bold DejaVu Sans Mono Book DejaVu Sans Mono Oblique DejaVu Sans Mono Bold Oblique Droid Sans Mono Regular Droid Sans Mono Italic Droid Sans Mono Bold Droid Sans Mono Bold Italic ... All of those are *.ttf fonts, which is definitively not a legacy bitmap format: $ ls /usr/share/fonts/{google-droid,dejavu}/*Mono* /usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf /usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf /usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf /usr/share/fonts/dejavu/DejaVuSansMono.ttf /usr/share/fonts/google-droid/DroidSansMono.ttf $ Also, the gnome-terminal or gedit font selection dialogs do not allow selecting any styles of a single font, so listing each font in a number of styles appears to be just their way to show font styles. > Legacy formats have very poor (everything, but especially) naming support. > Converting to SFNT will usually involve fixing the naming layer (Name ID > 16/17, using WWS rules, and Name ID 4, as Family + Style except for regular > for which is named Family not family Regular). > > That’s probably something that could be scripted using fontforge’s python > bindings. Ah. As it turns out, if I split off the ter-*.pcf.gz files into a -legacy-x11 subpackage and only install the ter-*.otb files, the gnome-terminal font selection list will properly display the "Terminus Italic" font without any hex glyphs. However, not installing the ter-*.pcf.gz files will result in xlsfonts not listing any terminus fonts, and without ter-*.pcf.gz emacs will then start to have all weird character spacing. More trial and error to follow.
Created attachment 1649541 [details] emacs showing proper spacing in Gnome/Wayland session with PCF files Proper character spacing with PCF files. $ rpm -q emacs freetype harfbuzz pango terminus-fonts{,-legacy-x11} | grep -v i686 emacs-26.3-1.fc31.x86_64 freetype-2.10.0-3.fc31.x86_64 harfbuzz-2.6.1-2.fc31.x86_64 pango-1.44.7-1.fc31.x86_64 terminus-fonts-4.48-2.fc31.1.noarch terminus-fonts-legacy-x11-4.48-2.fc31.1.noarch $
Created attachment 1649542 [details] emacs showing weird spacing in Gnome/Wayland session without PCF files emacs showing proper spacing in Gnome/Wayland session with the PCF files installed: $ rpm -q emacs freetype harfbuzz pango terminus-fonts{,-legacy-x11} | grep -v i686 emacs-26.3-1.fc31.x86_64 freetype-2.10.0-3.fc31.x86_64 harfbuzz-2.6.1-2.fc31.x86_64 pango-1.44.7-1.fc31.x86_64 terminus-fonts-4.48-2.fc31.1.noarch package terminus-fonts-legacy-x11 is not installed $
(In reply to Peng Wu from comment #31) > I think fonttosfnt upstream is reviewing the merge requests, > and they may release the tar ball later. FTR; I have just opened a bug against xorg-x11-font-utils to track when fonttosfnt is updated: https://bugzilla.redhat.com/show_bug.cgi?id=1787668
(In reply to Hans Ulrich Niedermann from comment #38) > Uhm. This is confusing. The font list for gnome-terminal starts with > > DejaVu Sans Mono Bold > DejaVu Sans Mono Book > DejaVu Sans Mono Oblique > DejaVu Sans Mono Bold Oblique > Droid Sans Mono Regular > Droid Sans Mono Italic > Droid Sans Mono Bold > Droid Sans Mono Bold Italic Well none of those exist in the font file themselves. (the giveaway is “DejaVu Sans Mono Book” or “Droid Sans Mono Regular”) The gnome-terminal font selector is reconstructing a fake Name ID 4 (aka fullname) by collating Family (Name ID 16 or 21) and Style (Name ID 17 or 22). Probably to workaround the following fontconfig bug: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/208 However, because the people that wrote the workaround did not bother reporting their problem fonconfig-side, and because they didn’t bother reading the OpenType Naming spec, they forgot the “Regular” special case. And the result is no better than using raw Name ID 4 directly (which is broken for some real-world font files). You can check the actual metadata contained in font files with fontforge or fc-scan (the later will apply fontconfig-level naming fixups)
terminus-fonts-4.48-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-619cd50145
terminus-fonts-4.48-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
Reopening, as the fontforge converted fonts Terminus OTB files still exhibit problems. Details to follow.
For experimenting, I have created a copr with terminus-fonts-4.48-2.fc31.1.3 at https://copr.fedorainfracloud.org/coprs/ndim/otb-bitmap-fonts/packages/. As you can see at https://copr-be.cloud.fedoraproject.org/results/ndim/otb-bitmap-fonts/fedora-31-x86_64/01139759-terminus-fonts/, this means there are now three separate packages to experiment with: terminus-fonts containing the convertfont.py/fonttosfnt generated /usr/share/fonts/terminus/TerminusBold.otb /usr/share/fonts/terminus/TerminusRegular.otb and the mkfontdir generated /usr/share/fonts/terminus/fonts.dir (is this still required for OpenType fonts?) terminus-fonts-legacy-bdf Contains the original bdf files as shipped from terminus-font upstream. This works e.g. with the emacs Xft font backend. /usr/share/fonts/terminus-legacy-bdf/fonts.dir /usr/share/fonts/terminus-legacy-bdf/ter-u12b.bdf /usr/share/fonts/terminus-legacy-bdf/ter-u12n.bdf and a good dozen of bdf files terminus-fonts-legacy-pcf Contains the *.pcf.gz files as built by upstream terminus-font. This works e.g. with the emacs Xft font backend. /etc/X11/fontpath.d/terminus:unscaled -> /usr/share/fonts/terminus-legacy-pcf /usr/share/fonts/terminus-legacy-pcf/fonts.dir /usr/share/fonts/terminus-legacy-pcf/ter-112b.pcf.gz /usr/share/fonts/terminus-legacy-pcf/ter-112n.pcf.gz plus about 250 more ter-*.pcf.gz files Some entries in the respective fonts.dir files are the same, but pointing to a different font file. As it turns out, the botched invented "Terminus Italic" (probably invented by fontconfig) consisting only of hex number in rectangle glyphs (what is the proper term for those btw?) only appears in the gnome-terminal font selection dialog when either the BDF or the PCF or both BDF and PCF fonts are installed. However, there are applications which do not support OTB fonts yet. Not every piece of Linux software in the world uses pango/harfbuzz. So removing the PCF fonts (or even the BDF fonts which the terminus-fonts package had never provided in the past) would remove an ABI on which software relies. Some of that non-harfbuzz or pre-harfbuzz Linux software comes from the Fedora set of packages, and some will come from outside Fedora. Providing those older font formats as a compatibility layer for running that software certainly is not the worst of ideas. E.g. emacs upstream is still working on adding a harfbuzz font backend which appears to be aimed for emacs 27, which has not been released yet, and that is an important use case for e.g. Terminus. As it stands, having more than *.otb causes the weird hex number rectangle glyph "Terminus Italic", but not having *.bdf or *.pcf.gz breaks emacs for me, so the hex number rectangle glyphs are the price to pay for that. As to other more test cases than just gnome-terminal and emacs, I still need to look for and test a number of those.
FEDORA-2020-7c418e8b13 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c418e8b13
FEDORA-2020-dc8c6af49d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc8c6af49d
FEDORA-2020-7c418e8b13 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-7c418e8b13` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c418e8b13 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-dc8c6af49d 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-dc8c6af49d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc8c6af49d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-7c418e8b13 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Fedora Update System from comment #51) > FEDORA-2020-7c418e8b13 has been pushed to the Fedora 32 stable repository. > If problem still persists, please make note of it in this bug report. This issue is still persisting (even with the new package), although I haven't tried reproducing in gvim. In my case, the issue occurs with many Gnome/GTK applications such as Eclipse and Gnome file manager. Although only the italics font seems to be broken in the font selection dialog, actually using the font is broken in many applications (even if they aren't using Italicized text). I posted some more info and screenshots on Bug 1823637 (https://bugzilla.redhat.com/show_bug.cgi?id=1823637#c17). Sorry if my comment isn't directly related to this ticket's topic (gvim with Terminus).
For a couple of weeks I now have the problem that the Terminus font is only found in size 9 within Konsole. I can happily use it in gvim in all sizes, though. I am not sure what causes this, but as I don't like to use font size 9, I am stuck using some other font now. Screenshot of Konsole font settings: https://imgur.com/a/LagtGCK
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.
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.