Bug 1748495 - The terminus font is no longer found by gvim, so text files come up with glyphs instead of characters.
Summary: The terminus font is no longer found by gvim, so text files come up with glyp...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: terminus-fonts
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Hans Ulrich Niedermann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1754492 (view as bug list)
Depends On: 1787668
Blocks: 1753295
TreeView+ depends on / blocked
 
Reported: 2019-09-03 17:36 UTC by stan
Modified: 2020-01-30 23:58 UTC (History)
19 users (show)

Fixed In Version: terminus-fonts-4.48-2.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-05 00:41:03 UTC
Type: Bug


Attachments (Terms of Use)
emacs showing proper spacing in Gnome/Wayland session with PCF files (24.34 KB, image/png)
2020-01-03 22:15 UTC, Hans Ulrich Niedermann
no flags Details
emacs showing weird spacing in Gnome/Wayland session without PCF files (24.28 KB, image/png)
2020-01-03 22:20 UTC, Hans Ulrich Niedermann
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1753295 None None None 2020-01-03 22:44:01 UTC
Red Hat Bugzilla 1787668 None None None 2020-01-03 22:44:01 UTC

Internal Links: 1753295

Description stan 2019-09-03 17:36:34 UTC
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.

Comment 1 Zdenek Dohnal 2019-09-04 08:25:04 UTC
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.

Comment 2 stan 2019-09-04 15:21:10 UTC
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?

Comment 3 Hans Ulrich Niedermann 2019-09-07 00:19:56 UTC
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)

Comment 4 Hans Ulrich Niedermann 2019-09-07 00:37:39 UTC
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.

Comment 5 Hans Ulrich Niedermann 2019-09-22 11:29:44 UTC
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.

Comment 6 stan 2019-09-26 14:19:31 UTC
Thanks!

Comment 7 Tomasz Torcz 2019-09-28 17:45:52 UTC
*** Bug 1754492 has been marked as a duplicate of this bug. ***

Comment 8 Hans Ulrich Niedermann 2019-09-28 18:27:10 UTC
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.

Comment 9 Hans Ulrich Niedermann 2019-09-28 22:38:00 UTC
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.

Comment 10 Jens Petersen 2019-09-29 14:24:40 UTC
I think this is likely due to latest pango/harfbuzz dropping support for bitmap fonts.

See bug 1753295 for more details.

Comment 11 Hans Ulrich Niedermann 2019-09-30 20:48:40 UTC
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.

Comment 12 Jan Pazdziora 2019-10-29 13:43:25 UTC
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/.

Comment 13 stan 2019-10-29 17:31:38 UTC
That worked, thanks.

Comment 14 Jan Pazdziora 2019-10-31 10:49:21 UTC
For the record, I've filed the same issue for LucidaTypewriter Sans as bug 1767384 now.

Comment 15 Peng Wu 2019-11-07 03:28:57 UTC
Thanks for creating the Fedora copr repo!

Comment 16 Nicolas Mailhot 2019-11-09 09:27:23 UTC
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

Comment 17 Patryk Obara 2019-11-10 08:14:29 UTC
@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.

Comment 18 Nicolas Mailhot 2019-11-10 11:19:05 UTC
@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.

Comment 19 Patryk Obara 2019-11-10 18:43:08 UTC
@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.

Comment 20 Nicolas Mailhot 2019-11-11 13:15:23 UTC
@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.

Comment 21 Mike Pittaro 2019-11-13 01:47:04 UTC
(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.

Comment 22 Martin Ueding 2019-11-26 13:38:15 UTC
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

Comment 23 Jan Pazdziora 2019-11-26 14:33:34 UTC
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.

Comment 24 spamulousbastard+redhat 2019-11-28 13:18:11 UTC
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.

Comment 25 Peng Wu 2019-12-02 07:20:05 UTC
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.

Comment 26 Nicolas Mailhot 2019-12-02 07:59:58 UTC
(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)

Comment 27 Peng Wu 2019-12-04 06:23:28 UTC
(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.

Comment 28 Nicolas Mailhot 2019-12-07 11:32:10 UTC
(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

Comment 29 Hans Ulrich Niedermann 2020-01-02 04:20:52 UTC
(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).

Comment 30 Hans Ulrich Niedermann 2020-01-03 05:45:20 UTC
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.

Comment 31 Peng Wu 2020-01-03 06:28:51 UTC
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.

Comment 32 Hans Ulrich Niedermann 2020-01-03 07:36:45 UTC
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.

Comment 33 Fedora Update System 2020-01-03 07:43:34 UTC
FEDORA-2020-619cd50145 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-619cd50145

Comment 34 Nicolas Mailhot 2020-01-03 10:03:12 UTC
> 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.

Comment 35 Jan Pazdziora 2020-01-03 10:17:34 UTC
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.

Comment 36 Hans Ulrich Niedermann 2020-01-03 15:10:02 UTC
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
    $

Comment 37 Nicolas Mailhot 2020-01-03 15:40:57 UTC
(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.

Comment 38 Hans Ulrich Niedermann 2020-01-03 21:02:05 UTC
(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.

Comment 39 Hans Ulrich Niedermann 2020-01-03 22:15:38 UTC
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
    $

Comment 40 Hans Ulrich Niedermann 2020-01-03 22:20:06 UTC
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
    $

Comment 41 Hans Ulrich Niedermann 2020-01-04 00:35:02 UTC
(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

Comment 42 Nicolas Mailhot 2020-01-04 11:11:34 UTC
(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)

Comment 43 Fedora Update System 2020-01-04 22:24:30 UTC
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

Comment 44 Fedora Update System 2020-01-05 00:41:03 UTC
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.

Comment 45 Hans Ulrich Niedermann 2020-01-07 01:16:28 UTC
Reopening, as the fontforge converted fonts Terminus OTB files
still exhibit problems. Details to follow.

Comment 46 Hans Ulrich Niedermann 2020-01-07 11:56:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.