Bug 706559 - Font variants not used correctly [NEEDINFO]
Summary: Font variants not used correctly
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-20 23:15 UTC by David Woodhouse
Modified: 2023-09-08 12:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:
ahmed0zake: needinfo? (dwmw2)


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


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 13416 0 None None None Never

Description David Woodhouse 2011-05-20 23:15:31 UTC
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 23:16:32 UTC
Created attachment 500156 [details]
LibreOffice with all three fonts displayed in regular, italic and bold face.

Comment 2 David Woodhouse 2011-05-20 23:19:00 UTC
Created attachment 500157 [details]
GNOME (Evolution) font selector showing light style

Comment 3 David Woodhouse 2011-05-20 23:19:43 UTC
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 23:20:37 UTC
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 23:22:05 UTC
Created attachment 500163 [details]
fc-list -v "Neo Sans Intel"

Comment 6 Behdad Esfahbod 2011-05-21 23:21:06 UTC
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 10:17:57 UTC
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 10:20:10 UTC
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 11:54:27 UTC
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 13:40:30 UTC
(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 09:10:09 UTC
(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 09:27:36 UTC
(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 10:21:23 UTC
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 15:41:56 UTC
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-22 01:38:04 UTC
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 17:45:47 UTC
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

Comment 17 Jimm 2020-02-10 22:01:12 UTC Comment hidden (spam)
Comment 18 Kurwa69 2020-04-22 10:42:47 UTC Comment hidden (spam)
Comment 19 SatSale 2020-08-10 04:10:27 UTC Comment hidden (spam)
Comment 20 nsetak 2020-11-14 03:54:44 UTC Comment hidden (spam)
Comment 21 Bis Matrimony 2020-11-15 15:09:20 UTC Comment hidden (spam)
Comment 22 margotjack 2021-01-30 19:27:51 UTC Comment hidden (spam)
Comment 23 davitomasi 2021-02-03 20:57:51 UTC Comment hidden (spam)
Comment 24 davitomasi 2021-02-03 20:58:16 UTC Comment hidden (spam)
Comment 25 davitomasi 2021-02-03 20:58:29 UTC Comment hidden (spam)
Comment 26 barbara 2021-02-07 19:24:27 UTC Comment hidden (spam)
Comment 27 barbara 2021-02-07 19:25:50 UTC Comment hidden (spam)
Comment 28 Slavynskas 2021-02-19 14:14:33 UTC Comment hidden (spam)
Comment 29 murtsdf 2021-02-26 22:00:13 UTC Comment hidden (spam)
Comment 30 murtsdf 2021-02-26 22:02:05 UTC Comment hidden (spam)
Comment 31 barbaraduarte 2021-03-23 16:31:46 UTC Comment hidden (spam)
Comment 32 dibis52094 2021-06-23 12:54:36 UTC Comment hidden (spam)
Comment 33 MICHEAL KORDS 2022-05-26 15:35:01 UTC Comment hidden (spam)
Comment 35 modrk 2023-03-26 23:37:21 UTC Comment hidden (spam)
Comment 36 modrk 2023-05-11 00:24:50 UTC Comment hidden (spam)
Comment 37 sapreen 2023-06-20 11:24:54 UTC Comment hidden (spam)
Comment 38 alfi printing 2023-08-15 22:12:30 UTC Comment hidden (spam)
Comment 39 ahmedzake 2023-09-08 12:02:43 UTC Comment hidden (spam)

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