Created attachment 1776799 [details]
LibreOffice with all three fonts displayed in regular, italic and bold face.
I have installed some company-provided fonts for use in presentations etc.:
$ ls /usr/share/fonts/neo-sans-intel/
In LibreOffice I have a choice of three separate fonts: Neo Sans Intel, Neo Sans Intel Medium, and Neo Sans Intel Light.
For each of those three, the italic version of the font (from the separate TTF file) is used. I can tell by the tail on the 'f' character. For bold text, however, an 'emboldening' algorithm seems to be used instead of using the appropriate separate font file.
In GNOME font selection dialogs, I see just one 'Neo Sans Intel' family, with a choice of 8 styles. I'll ignore the italic versions since those do actually seem to work as expected, so there are four weights listed:
- Light (== Neo Sans Intel Light)
- Regular (== Neo Sans Intel Medium)
- Medium (== Neo Sans Intel Medium)
- Bold (== Neo Sans Intel Medium + emboldening algorithm?)
I *don't* seem to have an option in GNOME which will just use the straight 'Neo Sans Intel' font.
So both seem to be getting it wrong, in different ways. Or perhaps there's something wrong with the fonts themselves?
If you ask:
1. LibreOffice is definitely wrong because it tries to force fonts to fit in the regular/italic/bold/bold italic model, which has not been true in font formats for decades. It should display a single font family with the real font face names instead of relying on legacy compatibility metadata layers (which are increasingly unreliable because who cares the world has moved on)
2. The GNOME font selector is usually more correct, but also suffers from attempts to make things up instead of relying on Opentype face names, making a mess more often than not (but less often that LibreOffice). Also it does not understand font faces split over multiple files.
3. font files are often buggy because font authors do weird things in legacy compatibility metadata layers to fix misbehaviours in legacy windows apps that do not understand modern font faces (breaking things for apps like Libreoffice that take the result at face value). Again, from the font maker point of view who cares, legacy metadata layers are for legacy apps, no modern app should try to interpret those, the weird things are only tested in legacy windows apps.
If you want to sort this mess, run
fc-scan -f \
/usr/share/fonts/neo-sans-intel/ | sort -t ';' -k1,1d -k4,4n -k5,5n -k6,6n -k2,2d -k7,7dr \
| uniq | column --separator ';' -t
If the font metadata is sane you should see Neo Sans Intel in the first column, the real font face names (Regular, Italic, Medium, Medium Italic, Light, Light Italic) in the second column, and sensible width weight and slant values in the 4th to 6th columns
If that is not the case the font files are buggy, and you need to either get their metadata fixed or declare overrides at the fontconfig level
Once the fontconfig output is sane everything else is an application (Libre Office, Gnome Font selector, etc) bug. Usually due to someone not understanding the OpenType font model and trying to shove font files into a simplistic regular/bold/italic/bold italic one face per file deprecated legacy model.
BTW Bold is not the same as Medium, there is no more reason to expect Medium to be used when asking a Bold Regular, than expecting Regular to be used when asking a Bold Light. Since your font family does not provide any Bold weight using the Bold button is open to interpretations.
Of course some font makers DO expect apps to understand Bold when they use some other hipster designation. It works in their Apple apps (and they did not test anything else).
What can I say, you want apps to understand Bold you state Bold in the face name, simple easy, stupid and reliable.
> 2. The GNOME font selector is usually more correct, but also suffers from attempts to make things up instead of relying on Opentype face names, making a mess more often than not (but less often that LibreOffice). Also it does not understand font faces split over multiple files.
The gnome font selector is not in the business of understanding how font faces are split over files. It shows the fonts that fontconfig tells us about
Exactly, it has no business of understanding how font faces are split over files, it should display one entry per face detected by fontconfig, and let fontconfig handle the assembling, instead of duplicating entries for the same face when it is split over multiple files.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.