Bug 44 - fontconfig should set font weight with usWeightclass value
Summary: fontconfig should set font weight with usWeightclass value
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://partners.adobe.com/asn/develop...
Depends on:
Reported: 2003-03-08 05:05 UTC by Ken Joseph
Modified: 2003-03-12 01:51 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Extract width and weight from OS/2 table (9.21 KB, patch)
2003-03-09 22:58 UTC, Keith Packard
Details | Splinter Review

Description Ken Joseph 2003-03-08 05:05:55 UTC
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.

usWeightClass Description
============= =========
100 Thin
200 Extra Light
300 Light
400 Normal (Regular)
500 Medium
600 Demibold
700 Bold
800 Extra Bold
900 Black

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.
Comment 1 Keith Packard 2003-03-09 22:57:38 UTC
I've extracted the weight and width information from the OS/2 table; does the
following patch look reasonable?
Comment 2 Keith Packard 2003-03-09 22:58:57 UTC
Created attachment 29 [details] [review]
Extract width and weight from OS/2 table
Comment 3 Ken Joseph 2003-03-11 00:06:37 UTC
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.
Comment 4 Ken Joseph 2003-03-11 01:29:10 UTC
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.
Comment 5 Keith Packard 2003-03-11 09:00:21 UTC
> 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.
Comment 6 Ken Joseph 2003-03-11 17:42:44 UTC
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 :)
Comment 7 Keith Packard 2003-03-12 14:19:57 UTC
I've added the weight values from the OS/2 table and also the width values.
Comment 8 Ken Joseph 2003-03-12 20:51:20 UTC
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

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.