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 http://partners.adobe.com/asn/developer/opentype/os2.html 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.
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. http://developer.apple.com/fonts/TTRefMan/RM06/Chap6OS2.html 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 equivalent.
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.