Red Hat Bugzilla – Bug 706559
Font variants not used correctly
Last modified: 2015-08-13 06:13:48 EDT
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?
Created attachment 500156 [details]
LibreOffice with all three fonts displayed in regular, italic and bold face.
Created attachment 500157 [details]
GNOME (Evolution) font selector showing light style
Created attachment 500158 [details]
GNOME (Evolution) font selector showing regular style
The 'Medium' option is identical to this
Created attachment 500159 [details]
GNOME (Evolution) font selector showing bold style
This one definitely seems to be made up, or "emboldened"
Created attachment 500163 [details]
fc-list -v "Neo Sans Intel"
This is a known issue that spans multiple modules. I don't have any immediate plans to work on it unfortunately :(.
I'm trying to package this particular font for internal use. Is there a way to work around it by using a fontconfig file to disable emboldening and set appropriate aliases?
Also, is there an upstream bug or discussion of the issue, that might help me to overcome my ignorance and devise such a workaround?
You should have patterns of fontconfig aliasing logic in fontpackages-devel (IIRC they are used by senamirmir fonts, fot example)
They may be enough to fix the styles at the fontconfig level (though style aliasing is a big mess, it is not as robust as family aliasing)
However, libreoffice is its own can of worms and tries to out-quess fontconfig so till this libreoffice code is buried you may have different results than in other apps
Generally speaking, changing the fonts so their metadata is fontconfig-friendly is usually the best choice.
(In reply to comment #9)
> Generally speaking, changing the fonts so their metadata is fontconfig-friendly
> is usually the best choice.
I ought to be able to do that by taking apart the existing TTF files and rebuilding them, right? All I need to do is work out what you mean by 'fontconfig-friendly'... :)
In what way is the current metadata, as shown in the attachment in comment 5, not "fontconfig-friendly"?
Is this a bug in the font, which I should be asking them to fix "upstream", or just something we don't really cope with very well?
(In reply to comment #10)
> (In reply to comment #9)
> > Generally speaking, changing the fonts so their metadata is fontconfig-friendly
> > is usually the best choice.
> I ought to be able to do that by taking apart the existing TTF files and
> rebuilding them, right?
Yes (if you can do it legally). Change the font in fontforge, or script the modification with ttx, whatever works best for you
> All I need to do is work out what you mean by
> 'fontconfig-friendly'... :)
> In what way is the current metadata, as shown in the attachment in comment 5,
> not "fontconfig-friendly"?
I don't claim to know fontconfig/pango innards, but at a guess fontconfig is confused by the way the fonts declare styles twice, both the legacy way (regular, bold, italic, with medium in the family name) and the modern way (with medium in the style name)
Medium is a weight attribute and should only appear in the style name to be WWS-compliant. Regular is a *different* width attribute so Regular Medium is a train wreck (see
http://nim.fedorapeople.org/Understanding%20fonts%20and%20fontconfig.tar.gz ignore all the parts except the naming section, the fontconfig syntax at the end is especially unreliable but the naming section is solid)
If you want the full story read
Remembering that fontconfig does *not* implement the naming fixing heuristics described in the Microsoft paper, so for a font to work it needs to declare the naming that would be produced by this heuristic directly
> Is this a bug in the font, which I should be asking them to fix "upstream", or
> just something we don't really cope with very well?
If upstream wants its font to work with Linux they need to change the font yes. However it may break compatibility with old windows versions and old windows apps. What confuses fontconfig is probably the info added to make those apps understand those fonts.
(In reply to comment #11)
> Medium is a weight attribute and should only appear in the style name to be
> WWS-compliant. Regular is a *different* width attribute
weight attribute, not width attribute
Thanks, Nicolas, for the extremely helpful response, and your presentation.
I'll probably start by trying to provide a fontconfig config file which 'fixes' the problems, since I'm unlikely to get traction with "upstream". Even when something is egregiously broken, they don't really like fixing it. It's probably better for me to have the *same* TTF files as the ones which are installed on the Windows machines.
Btw, the URL http://blogs.msdn.com/text/attachment/2249036.ashx doesn't seem to work any more. I could get it from http://wayback.archive.org/web/*/http://blogs.msdn.com/text/attachment/2249036.ashx though.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here: