Bug 7673 - preferred family name should be used
Summary: preferred family name should be used
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2_1
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Keith Packard
QA Contact:
URL: http://www.microsoft.com/typography/o...
Depends on:
Blocks: 8842
  Show dependency treegraph
Reported: 2006-07-28 06:36 UTC by Denis Jacquerye
Modified: 2006-12-02 13:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Denis Jacquerye 2006-07-28 06:36:24 UTC
OpenType fonts can have Name ID:
1. family name
2. subfamily name
16. preferred family name
17. preferred subfamily name

Some fonts have Name ID 16 and 17 but fontconfig still only uses Name ID 1 and 2.
Name ID 1 and 2 are for legacy systems that are not capable of handling more
than 4 subfamilies (Regular,Bold,Italics,Bold Italics). Fontconfig can handle
more than 4 subfamilies but does so with Name ID 1 and 2, which is wrong for
Windows fonts.

Suppose a font is DejaVu Sans, with one variant being Book and another being
ExtraLight. For legacy systems users the two fonts have different family names,
Name ID 1. But for more recent systems they can have the same preferred family
name, Name ID 16. However fc-list will not return any match in ExtraLight if
"DejaVu Sans", name ID 16, is searched. fc-list will only return a match in
ExtraLight if "DejaVu Sans Light", name ID 1, is searched.

fc-list should match name ID 16 first and fallback on name ID 1 if not
available. The same goes for name ID 17 and 2.
Comment 1 Keith Packard 2006-09-01 12:22:23 UTC
Should we not include font name 1 if fontname 16 is present?
Comment 2 Denis Jacquerye 2006-09-04 22:45:01 UTC
(In reply to comment #1)
> Should we not include font name 1 if fontname 16 is present?

From what I understand fontname 16 should be used whenever possible, fontname 1
is legacy.
A font family should have the same fontname 16 across fonts, and different
fontname 1 to be useable on legacy systems.
From a designer's point of view, it seems more practical to be able to have a
whole font family under the same hood.

I guess fontname 1 should still be matched when fontname 16 does not. So it
should be kept and used when necesarry. In any case most fonts have fontname 1
because Windows still uses legacy.
Comment 3 Keith Packard 2006-09-04 23:28:14 UTC
Ok, so we retain the current policy of grubbing every imaginable name out of the
font file and sticking that in the family element.

Right now, I'm using the order that the names appear in the font to choose which
name is listed first in this element; is there any particular reason to do
somthing different, like prefer name 16 first?
Comment 4 Denis Jacquerye 2006-09-04 23:46:05 UTC
If the first name in the list is what is displayed in apps, yes Name ID 16
should be first. It is the "preferred family name" in the OT specs after all. 
Otherwise I don't think it makes much difference in the match results to have
name ID 16 ordered before name ID 1.
Comment 5 Keith Packard 2006-11-13 14:20:11 UTC
I can easily add preferred name/style information to the font information, the
question is which should be listed first. The first name often guides
applications in presenting font lists, so we're going to end up listing all Deja
Vu fonts under the same family name which will often confuse users who are now
used to seeing different styles listed as different families. Contrast this with
Comment 6 Denis Jacquerye 2006-11-13 14:42:27 UTC
(In reply to comment #5)
It's tough to say which should come first, the legacy name or the preferred
name. Many users are used to legacy, but preferred names seem to make more sense.

Could the order legacy vs. preferred be set at compilation time or in a
configuration file?

Comment 7 Keith Packard 2006-12-02 13:08:19 UTC
I've just coded the library to prefer the 'preferred' names over the other names. 

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.