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
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.
Should we not include font name 1 if fontname 16 is present?
(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
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.
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?
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.
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
(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
I've just coded the library to prefer the 'preferred' names over the other names.