Created attachment 1752737 [details] gnome-terminal and gedit font selection box Description of problem: Creating the *.otb files using fonttosfnt 1.2.1 (from xorg-x11-font-utils 1:7.5-47) causes some weirdness in the generate Terminus Bold (while fixing the non-Bold spacing issues). Version-Release number of selected component (if applicable): terminus-fonts-4.48-10.fc33.noarch xorg-x11-font-utils-7.5-47.fc33.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install terminus-fonts-4.48-10.fc33.noarch 2. In the gnome-terminal or gedit font selection box, look for and select "Terminus Bold". Actual results: The letters of words "Terminus Bold" in the font list are cut off at the top. Also, if you select size 10 for Terminus Bold, the letters run into each other. See attached image file. Expected results: Proper font rendering. Additional info:
Created attachment 1752738 [details] Terminus font rendered for all sizes and both Medium and Bold This is the result of using `pango-view` to render text for each "Terminus" and "Terminus Bold" font size, and joining those renderings using ImageMagick's `montage`. This shows the vertial issues with "Terminus Bold" quite well. Not sure how much the vertical spacing in the pango-view rendering for the non-bold "Terminus" font actually mean, as gnome-terminal, gedit and emacs actually render the non-bold properly with regards to line spacing. (If there is a more modern replacement for "pango-view" for rendering text into image files, please let me know.)
It needs to be seen whether terminus-fonts-4.49.1 would fix this. terminus-fonts-4.49 has introduced *.otb rendering upstream for the first time, however generating one *.otb file for every font size for a reason which is not clear to me yet. The reason given might even affect the issues I have described above, but I need to test that first.
I have just found out that after killing gnome-terminal-server, gnome-terminal now shows "Terminus Medium" text with very *nice* horizontal spacing between letters but very much *too large* vertical spacing between lines This looks to be the same or at least very similar to the pango-view renderings in the attached PNG file.
I'm seeing the same issue on i3. Screenshot attached.
Created attachment 1752787 [details] i3 window titles after upgrading terminus-fonts to 4.48-10.fc33
Summarizing the new terminus-fonts package built using fonttosfnt >= 1.2.1: * *completely* messed up the vertical spacing for Terminus Medium making it impossible to use * messed up the vertical spacing for Terminus Bold * cut off the top of larger Terminus Bold fonts * worsened the horizontal character spacing for Terminus Bold * fixed the horizontal character spacing for Terminus Medium For these reasons, I have just unpushed https://bodhi.fedoraproject.org/updates/FEDORA-2021-79f17f3c73 from testing, for whatever that is worth. My ideas right now is to * try upstream's terminus 4.49.1 * try post-1.2.1 fonttosfnt If neither of those or nor both of them help, I guess I need to dig into the fonttosfnt code. For all of this it would be brilliant if there was a utility which could take a text file, a font file, and render the text into a bitmap file. If anybody knows of such a utility, please let me know. The pango-view utility appears to just use the fonts installed to the system.
Created attachment 1754115 [details] terminus-fonts-4.48-8.fc33 font card with box and block characters
Created attachment 1754116 [details] terminus-fonts-4.48-10.fc33 font card with box and block characters
This is because Terminus.otb and Terminus-Bold.otb have different underline position values. In fonttosfnt, the underline position is computed from the font descent value if not defined. But the bitmap font with different height will have different descent values, then the underline position values are different. The fonttosfnt tool suggests to convert the font one by one to preserve the fonts metrics. The warning from fonttosfnt tool: $fonttosfnt -b -c -g 2 -m 2 -o Terminus-Bold-16.otb ter-u16b.bdf ter-u16v.bdf You are requesting to put more than one font into a single OpenType font. This is not recommended. The global font metrics will not match every font face. The creation of an OpenType font collection is recommended. Sorry, the work around is to convert the font one by one. Or use the convertfont2.py tool to group the fonts by fullname and height. URL: https://pwu.fedorapeople.org/fonts/convertbitmap/convertfont2.py
Just so I understand the higher level correctly (skip the next two paragraphs for the practical consequences): I used to just generate one *.otb file per *.bdf file about a year ago, but then someone more familiar with font things said to use fonttosfnt to generate one *.otb file for "Terminus Medium" containing all sizes and one *.otb file for "Terminus Bold" containing all font sizes. Now it turns out the *.otb OpenType bitmap font file format does not store the information actually needed for using a stored bitmap font when multiple font sizes are stored in one file, and so fix is to go back to one *.otb file per (font weight, font size) tuple? Anyway, to the practical consequences... I have just built two test packages testing building per (font weight, font size) tuple *.otb files from upstream release terminus-font-4.49.1. 4.49.1-10.2: uses Peng's convertfont2.py script which in turn uses fonttosfnt pango-view generated font card PNG file looks good gnome-terminal font selector has one choice "Terminus" gedit font selector has four choices ("Terminus Regular", "Terminus Italic", "Terminus Bold Italic", "Terminus Bold") emacs font selector has four choices ("Terminus Regular", "Terminus Italic", "Terminus Bold Italic", "Terminus Bold") fontlint complaints: CHECKING /usr/share/fonts/terminus-fonts/Terminus-Bold-32.otb File checksum is incorrect. Table 'OS/2' has a bad length, must be 78, 86 or 96 but is 100. Missing required table: "post" The following table(s) in the font have been ignored by FontForge Ignoring 'PCLT' PCL 5 data table ERROR 41 Bad sfnt file header ERROR 80 Missing BlueValues entry in PostScript Private dictionary FAIL /usr/share/fonts/terminus-fonts/Terminus-Bold-32.otb 4.49.1-10.3: uses upstream's bdf to otb python converter pango-view generated font card PNG file looks good gnome-terminal font selector has one choice "Terminus" gedit font selector has four choices ("Terminus Regular", "Terminus Italic", "Terminus Bold Italic", "Terminus Bold") emacs font selector has four choices ("Terminus Regular", "Terminus Italic", "Terminus Bold Italic", "Terminus Bold") fontlint complaints: CHECKING /usr/share/fonts/terminus-fonts/ter-u20b.otb Missing required table: "post" ERROR 80 Missing BlueValues entry in PostScript Private dictionary FAIL /usr/share/fonts/terminus-fonts/ter-u20b.otb Both package variants appear to work in practical use, and the fontlint complaints do not appear to cause problems. I am undecided now which package variant to package as 4.49.1-11 for rawhide and fc33: * fonttosfnt based conversion (4.49.1-10.2) - some extra maintenance required (fonttosfnt, conversion script) + fonttosfnt and conversion script work well in Fedora - fontlint complains about a lot more problems + proper font selection + proper spacing in rendered font * terminus-font upstream own python tool (4.49.1-10.2) + upstream maintains it - tooling probably less proven than fonttosfnt + fontlint complains about fewer problems + proper font selection + proper spacing in rendered font * terminus-font upstream own javascript/nodejs tool - never tried it - requires separate software universe to build (nodejs
The flow to fix something when we find issues in otb shouldn't be different so much. but different is who fix it and maitnain it at the end: 1. investigate what exactly is wrong. 2. report phase or try to work around if possible * fonttosfnt based conversion - fix/work around in conversion script and/or report to fonttosfnt * upstream - ask for fixing I'm not checking how upstream script do. if no other deps on it, that looks promising because all the changes can be made at their own risk even if the fix is a bit ugly but easier to do for Terminus.
Considering all of the above, I am tending towards switching to upstream's special Python script: * upstream's script should work with upstream's font * test package with upstream's scripts (4.49.1-10.3) works for me in gnome-terminal, gedit, emacs, gitk+git-guit * fewer complaints by fontlint (and no additional complaints) * in case of serious problems, we can still revert back to fonttosfnt Will rename 4.49.1-10.3 to 4.49.1.11 soon for f33 and rawhide, unless someone comes forward with a really significant argument against upstream's script or for fonttosfnt.
FEDORA-2021-83d02bf1a9 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-83d02bf1a9
FEDORA-2021-6ee8444b7a has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6ee8444b7a
FEDORA-2021-83d02bf1a9 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-83d02bf1a9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-83d02bf1a9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6ee8444b7a has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6ee8444b7a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6ee8444b7a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Tested, before the update 27 cyrillic letters were almost 32 Latin letters wide in konsole, after the update everything is same width (reboot was required).
FEDORA-2021-6ee8444b7a has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.