"DejaVu Sans Condensed", "DejaVu Serif Condensed", and "Arial Narrow", are each font families of four faces with weight and slant variants. However, usually none of these appear in the family list of gfxPlatform::GetFontList. The reason is that only the "Preferred Family" name is being included in the list. OpenType fonts can have both a "Font Family name" and a "Preferred Family" name (and it looks like OpenType 1.5 will also have a "WWS Family Name" - WWS == weight/width/slope). http://www.microsoft.com/typography/otspec150/name.htm "Up to four fonts can share the Font Family name" and these should be weight and slant variants. The "Preferred Family" can be shared by fonts with addition weight variations, width variations, and variations in other attributes. As CSS 2.1 only enables specification of weight and slant variations (and cannot select fonts through other style variants) the "Font Family name" is often the most useful to CSS. Sometimes the "Preferred Family" is most useful as it can then include addition weights beyond regular and bold. I think the best solution for the font preferences dialogs is to provide both the "Font Family name" and "Preferred Family" (and "WWS Family Name" when that is available), so the user can select families like "DejaVu Sans Condensed". Determining whether a family in the output from FcFontList is a "Font Family name" or "Preferred Family" is difficult. (With fontconfig-2.5.0 at least) the first family returned name is in the language corresponding to LC_CTYPE (at the time fontconfig first inspected this - the value is cached) if possible. If the language is an exact match with the language corresponding to the name, then the first family is a "Font Family name". Usually, however, fontconfig doesn't record the territory of the name, while the locale usually has a territory so the language is an approximate match, in which case the first family is a "Preferred Family" (when present). I think the best thing to do is to list all family names that have a language exactly matching the first family name returned. This can be determined using the FC_FAMILYLANG property available since fontconfig 2.2.97 (2004-12-05).
(In reply to comment #0) > I think the best thing to do is to list all family names that have a language > exactly matching the first family name returned. This can be determined using > the FC_FAMILYLANG property available since fontconfig 2.2.97 (2004-12-05). fontconfig localize name has different meanings. "さざなみゴシック" is localized name of "Sazanami Gothic". However, when we get the pattern from "Sazanami Gothic", the font is rendered as AAed outline. But when we get from "さざなみゴシック", it is rendered as bitmap glyph font. This is Fedora's default settings.
I think this qualifies as an enhancement, not as a bug, you're really asking for more font attributes to be displayed in the prefs dialog. The underlying "bug" is that CSS 2.1 doesn't support a rich enough set of CSS attributes to specify all faces within a family (e.g. condensed/expanded faces, faces of differing stylistic quailities that are group in the same family as with Minion Pro from Adobe). Some fonts try to solve this by adding in extra family names, most do not. Some fonts add extra names for compatibility with older names (e.g. Hiragino Kaku Gothic Pro W6) or for localized names (e.g. ヒラギノ角ゴ Pro). The Futura family on the mac has condensed faces but the only family name is "Futura". For examples, see the full list of fonts and other family names attached to bug 417444: https://bugzilla.mozilla.org/attachment.cgi?id=303947 In general, fonts are grouped according to their preferred family name if one is present, the first family name otherwise. We have to cheat this a bit sometimes (e.g. Osaka-Mono on the mac) but in general that's true both on the mac and windows. Font utilities like FontBook on the mac follow this and that's what users use when reporting bugs. On the mac we currently have to deal with the family names made up by the Quickdraw API which don't follow these rules (for examples, view the FF2 font prefs dialog on the mac). I think a much better solution would be to support the CSS3 font-stretch property post-FF3. Note: OpenType 1.5-style WWS names don't really help either this is more of an effort to push anything that doesn't specify weight, width or slope into the family name. Something like DejaVu Sans Condensed would still have a WWS name of DejaVu Sans since condensed implies the width.
(In reply to comment #1) > fontconfig localize name has different meanings. "さざなみゴシック" is > localized name of "Sazanami Gothic". However, when we get the pattern from > "Sazanami Gothic", the font is rendered as AAed outline. But when we get from > "さざなみゴシック", it is rendered as bitmap glyph font. This is > Fedora's default settings. Wow, that is completely evil!
This behavior described in comment 0 is only since fontconfig 2.4.2 (2006-12-02). Before this change the first family was usually the first family (with an approximately matching language I assume) listed in the OpenType name table, which was usually the "Font Family name". http://gitweb.freedesktop.org/?p=fontconfig;a=commitdiff;h=253ec7609c13b46c717c801206ebb1a6c7f06e27 If we are going to implement font-stretch with initial value "normal" as currently described in the CSS3 draft http://www.w3.org/TR/2002/WD-css3-fonts-20020802/#font-stretch then providing families with non-normal width as options may seem a little strange (though I don't see anything to say that CSS "normal" must correspond to any particular OpenType width value). However, I do see a difference between the width property and the weight and slope properties. Weight and slope are often used to emphasize text in the same paragraph with the regular variant. I can't think why width would be varied within the same paragraph. Width is more often useful to a user who wishes to fit more text on the screen or make the text easier to read. Some people notice that this choice is no longer available. https://bugs.launchpad.net/ubuntu/+bug/93155 Providing all "Font Family name"s as options is an easy way to allow the user to choose. Providing a preference for preferred width is another option, but, as most families don't have a variety of widths, this option may often not be so helpful.