It seems that fontconfig assigns a font weight value of 200
to all fonts which have their bold bit set in the fsSelection value
of OS/2 font table regardless of whether the font is demibold,
bold or black. This causes applications to pick a wrong font
when there are several fonts with the same family and bold bit set
but with different styles.
For example, I have Zurich Bold and Zurich Black typeface.
They are both Zurich family and both have set their bold bit on.
But they are both given font weight value 200. Somehow
applications see them as same face and display them as the same
Bold or Black face. They should be given different font weight value
greater than 100.
I think font weight values should be set not by the bold bit but
by the usWeightClass value in the font OS/2 table. The OpenType
OS/2 table information on Abode site
shows the following table.
200 Extra Light
400 Normal (Regular)
800 Extra Bold
So I think it makes more sense if fontconfig assigns
font weight values based on usWeightClass value in OS/2 font table
rather than just the bold bit.
I've extracted the weight and width information from the OS/2 table; does the
following patch look reasonable?
Created attachment 29 [details] [review]
Extract width and weight from OS/2 table
It seems the patch will keep the existing font weight scale
for backward compatibility as it assigns 100 to medium typefaces,
200 to bold faces and anything else in between. I hope
we could assign usWeightClass values to font weight
just as is because the new font-weight scale (100, 200, .. 900) is
simpler and more generally accepted values for font weight
as I found out they are also used in CSS2 style.
On the other hand, we can use constants such as "Bold" and "Demibold"
to complement the existing weight scale.
Besides this, I don't find anything unreasonable.
There's PANOSE entry in the OS/2 table that you might take
into consideration when you compute font weight and width.
The following URL has information about PANOSE entries.
The PANOSE describes how you can associate a font
with other fonts of similar appearance. The bWeight and bProportion
value tells about font weight and width. Sometimes PANOSE values
are more accurate than usWeightClass or usWidthClass. For example,
Arial Black (ariblk.ttf) has usWeightClass value of 400 (Normal) and
bWeight value of 10 (Black).
I wasn't sure if we should accept PANOSE values, but it's good to
know about them.
Maybe you should consider PANOSE values when you calculate
font weight and width. A special way of getting the average value
might be needed.
> It seems the patch will keep the existing font weight scale
> for backward compatibility
Yes, the numeric values are recorded in cache files so I can't change the values
without invalidating the cached informatio. Plus, fontconfig uses the distance
between values to prioritize selection, so an application asking for regular
weight will prefer a font of normal weight over a font of light weight.
> There's PANOSE entry in the OS/2 table that you might take
> into consideration when you compute font weight and width.
I'm not sure I want to use panose numbers for the advertised weights; those are
generally used to select varients with the same family name (according to CSS2),
and not for font matching. Perhaps we will want to add panose based matching as
a separate activity at some point, but I think that's a very different activity
than selecting among several varients of a particular family.
Okay, I understand.
I think I'm okay with the patch.
And I agree that PANOSE is not relevant to this matter.
Thank you. You've done a great job.
I look foward to seeing this patch incorporated
in the next release of fontconfig :)
I've added the weight values from the OS/2 table and also the width values.
I came across some broken truetype fonts
with an invalid usWeightClass value.
I ran ttmkfdir in a directory full of fonts
and it displayed "unknown usWeightClass 5" messages
for these fonts:
DIPLOMA.TTF from AltSys foundry
EUE_____.TTF from AltSys
MILES.TTF from Monotype
MARLBO.TTF from AltSys
I found out they all had usWeightClass values of 5.
I think we should devise a workaround to
these invalid usWeightClass values such as
assigning the default "Medium" as weight or
multiplying 100 and then converting to fontconfig