Bug 706559 - Font variants not used correctly
Font variants not used correctly
Status: NEW
Product: Fedora
Classification: Fedora
Component: fontconfig (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
: FutureFeature, MoveUpstream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-20 19:15 EDT by David Woodhouse
Modified: 2015-08-13 06:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
LibreOffice with all three fonts displayed in regular, italic and bold face. (111.11 KB, image/png)
2011-05-20 19:16 EDT, David Woodhouse
no flags Details
GNOME (Evolution) font selector showing light style (36.94 KB, image/png)
2011-05-20 19:19 EDT, David Woodhouse
no flags Details
GNOME (Evolution) font selector showing regular style (37.68 KB, image/png)
2011-05-20 19:19 EDT, David Woodhouse
no flags Details
GNOME (Evolution) font selector showing bold style (38.45 KB, image/png)
2011-05-20 19:20 EDT, David Woodhouse
no flags Details
fc-list -v "Neo Sans Intel" (9.38 KB, text/plain)
2011-05-20 19:22 EDT, David Woodhouse
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 13416 None None None Never

  None (edit)
Description David Woodhouse 2011-05-20 19:15:31 EDT
I have installed some company-provided fonts for use in presentations etc.:

 $ ls /usr/share/fonts/neo-sans-intel/
NeoSansIntel-Italic.ttf       NeoSansIntel-MediumItalic.ttf
NeoSansIntel-LightItalic.ttf  NeoSansIntel-Medium.ttf
NeoSansIntel-Light.ttf        NeoSansIntel.ttf

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?
Comment 1 David Woodhouse 2011-05-20 19:16:32 EDT
Created attachment 500156 [details]
LibreOffice with all three fonts displayed in regular, italic and bold face.
Comment 2 David Woodhouse 2011-05-20 19:19:00 EDT
Created attachment 500157 [details]
GNOME (Evolution) font selector showing light style
Comment 3 David Woodhouse 2011-05-20 19:19:43 EDT
Created attachment 500158 [details]
GNOME (Evolution) font selector showing regular style

The 'Medium' option is identical to this
Comment 4 David Woodhouse 2011-05-20 19:20:37 EDT
Created attachment 500159 [details]
GNOME (Evolution) font selector showing bold style

This one definitely seems to be made up, or "emboldened"
Comment 5 David Woodhouse 2011-05-20 19:22:05 EDT
Created attachment 500163 [details]
fc-list -v "Neo Sans Intel"
Comment 6 Behdad Esfahbod 2011-05-21 19:21:06 EDT
This is a known issue that spans multiple modules.  I don't have any immediate plans to work on it unfortunately :(.
Comment 7 David Woodhouse 2011-05-22 06:17:57 EDT
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?
Comment 8 David Woodhouse 2011-05-22 06:20:10 EDT
Also, is there an upstream bug or discussion of the issue, that might help me to overcome my ignorance and devise such a workaround?
Comment 9 Nicolas Mailhot 2011-05-23 07:54:27 EDT
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.
Comment 10 David Woodhouse 2011-05-23 09:40:30 EDT
(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?
Comment 11 Nicolas Mailhot 2011-05-24 05:10:09 EDT
(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
 http://blogs.msdn.com/text/attachment/2249036.ashx
 http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf
 http://blogs.adobe.com/typblography/atypi2006/CSS%20&%20OT%2015.pdf

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.
Comment 12 Nicolas Mailhot 2011-05-24 05:27:36 EDT
(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
Comment 13 David Woodhouse 2011-05-24 06:21:23 EDT
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.
Comment 14 Fedora Admin XMLRPC Client 2012-01-10 10:41:56 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Fedora Admin XMLRPC Client 2012-03-21 21:38:04 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 16 Fedora End Of Life 2013-04-03 13:45:47 EDT
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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

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