Ambrose Li wrote:> On Mon, Mar 07, 2005 at 08:40:42AM -0500, Owen Taylor wrote: > > >>What font is selected when those conflict? > > > For the particular example I gave in the bug, the font with > lining figures is always selected. I don''t know why this is the > case; the "expert" one not being selected is probably because > it''s not complete, but I don''t know why it would not select the > font with oldstyle figures (perhaps it''s slightly incomplete too).That was a rhetorical question :-). I dont'' think there is a reasonable answer. (Prior art of fontconfig not withstanding.) The question of multiple fonts that are the "same" but have different glyph repetoires (like an expert font), or different glyph variants (old-style vs. lining) is a difficult one. The future here is OpenType fonts where everything is combined into one font. I don''t know if it makes sense to try and combine multiple Type1 fonts under the hood. Clearly, having to specifically select the expert font for a few characters to get old style numbers or ffi ligatures isn''t a good user interface. But I''d worry that we''d just outsmart ourselves here. Expert font tend, in my experience, to be each slightly different.> BTW, "Apollo MT" is a very mild example. I have another typeface > "Poetica Chancery" with 21 fonts which is much worse: in gimp 2, > it appears as 3 instances of "Poetica" (always the same capitals > font) and 18 instances of "Poetica Italic" (always the same > italic [i.e., cursive] font). And all these (all of them having > the same weight and the same slant, except the capitals because > originally italic faces had the property that lowercase letters > are slanted but uppercase letters are not slanted) should either > be in the same family (just "Poetica", but have to be able to > select any of the 21) or else split to 21 distinct families in > order to be useful. > > My feeling is that trying to map everything to the CSS model is > hopeless, unless we want to create fake font families on the fly.That''s exactly what I think we should do. Note that I''m proposing considerably *less* "fake" font families than what Windows does, since windows only allows four variants (bold/italic/bold italic) of each family.> Mapping font properties to CSS properties might be somewhat > fruitful, but most commercial Type 1 fonts have variants that > bear absolutely no relationship to CSS properties."Most"? "absolutely no"? I would dispute that. Most font variants are in fact quite representable in the CSS model. If you browse, say, through the Adobe type libary, you''ll find that 90+% of the fonts fall into the CSS model. Something like Poetica is going to be a mess to handle no matter how we encode it. "Poetica Ampersands"??? there are> also some more surprising inventions from the commercial font > world, such as typefaces that distinguishes between two variants > of small caps (e.g., Emigre''s "Mrs Eaves"). With the current > behaviour, commercial fonts are almost completely useless.Clearly having every face be accessible is a necessary goal. Regards, Owen
Keith Packard wrote:> Around 18 o''clock on Mar 6, Ambrose Li wrote: > > >>I was told that "there''s not much that can be done currently, >>since the fonts don''t differentiate themselves enough for >>pango to generate unique font descriptions for them." > > > There''s the limitation -- pango doesn''t expose the varients in any > extensible fashion, it has only two variables (weight/slant) and a limited > number of values for each one (2 each?). > > Pango should, in addtion, provide a list of style names for each family > for applications which want to select by name. As many TrueType fonts > provide extensive localization for these style names, it''s not even a > terrible localization problem. > > Owen just needs more people complaining so that he''ll figure out how > to provide a more comprehensive style solution.The bug referenced in Ambrose''s mail: http://bugzilla.gnome.org/show_bug.cgi?id=95043 gives details about how I want to implement it. (See comments 6 and 9) I don''t want to have overspecified font descriptions where we have *both* a textual description of the style and also CSS properties. What font is selected when those conflict? I''d certainly rather if fontconfig did the work here to make fonts conform to the CSS model. If that isn''t going to happen, it can be done at the Pango level, with some work and inefficiency. Regards, Owen
On Mon, 2005-03-07 at 09:49 -0800, Keith Packard wrote:> Around 8 o''clock on Mar 7, Owen Taylor wrote: > > > I don''t want to have overspecified font descriptions > > where we have *both* a textual description of the style and also > > CSS properties. What font is selected when those conflict? > > Hand them all to fontconfig and let it sort this out. When specified, and > explicit style name always overrides the CSS style values.When someone asks me what happens in a corner case, the last thing I want to do is say "I don''t know, go ask Keith" :-) Would you count it as expected that: desc = pango_font_face_describe (face); pango_font_description_set_weight (desc, PANGO_WEIGHT_BOLD); /* Use desc */ Ignores the call to set_weight? (because describe() sets some "face name" field) There is a considerably conceptual advantage to having PangoFontDescription not be over-specified, and I''m reluctant to give that up. Regards, Owen
On Mon, 2005-03-07 at 12:40 -0800, Keith Packard wrote:> Around 14 o''clock on Mar 7, Owen Taylor wrote: > > > Would you count it as expected that: > > > > desc = pango_font_face_describe (face); > > pango_font_description_set_weight (desc, PANGO_WEIGHT_BOLD); > > > > /* Use desc */ > > > > Ignores the call to set_weight? (because describe() sets some > > "face name" field) > > (did you mean "style name"?)"face name" would be more likely as a Pango name, since Pango also follows CSS in using "style" for Normal/Oblique/Italic.> Hmm. Sequence doesn''t exist in fontconfig. I think that might make a > difference for the user...Well, the sequence doesn''t really exist in fontconfig because fontconfig doesn''t expose any family or face objects, or even, really, the *notion* of family or face, other than as accidental coincidences of strings for listed fonts. There is nothing in the fontconfig API that would prevent it from listing two fonts with the same family and style but different CSS properties. I''ve tried to keep things much more structured and constrained for Pango, and thus hopefully simpler for the programmer.> If you think of the style name as restricting the available variants to the > selected style, or selecting a sub-family with the ''postscript name'', then > the ''set_weight'' call is no more ignored than if face was already black; > it''s requesting the ''bold'' variant of ''Cloister Old Style Roman'' which > doesn''t happen to have a bold variantThe logic follows, yes. I''d rather not have to explain it to my users that way :-)> Consider the fonts I just got -- named Cloister Old Style Roman, Cloister > Old Style Italic, Cloister Old Style Bold and Cloister Old Style Bold > Italic. All of these advertised a single style named ''Roman'' (the humor > of a ''Roman'' ''Italic'' font clearly escaped the publisher). > > If the ''description'' returned is used by the application to present > information to the user and to select fonts, then we have a problem as it > should contain the style name so the user can read it, but it shouldn''t > have the style name as a constraint on the selection. Perhaps those two > notions could be separated somehow?The API is already there for Pango: http://developer.gnome.org/doc/API/2.0/pango/pango-Fonts.html#pango-font-face-get-face-name This is the API that is used by the font selector and currently returns the fontconfig ''style''. (needs extension to handle localized names ... get_face_name_for_language() likely) Regards, Owen
On Mon, 2005-03-07 at 13:39 -0800, Keith Packard wrote:> Around 16 o''clock on Mar 7, Owen Taylor wrote: > > > The logic follows, yes. I''d rather not have to explain it to my users > > that way :-) > > I''m less concerned about the logical complexity than the outright > impossibility of modifying a selected face with a different slant or > weight. If every font description includes a normative style name, then > you would want to eliminate any API accepting a description which sets the > subordinate style selector values. > > It seems like the descriptor would need an informative style set by the > system and a normative style selected by the user.Perhaps the name PangoFontDescription is confusing. It doesn''t describe a font (or face), rather it is a description of the needs of an application to Pango. So, there would never be a reason to include informative information in it.> > (needs extension to handle localized names ... > > get_face_name_for_language() likely) > > If you come up with a useful abstraction which you think could live in > Fontconfig, let me know. I''m not going to add (more) code which isn''t > actually useful...I think, when I looked at it before, what is provided by fontconfig-2.3 should be sufficient to provide the API I want. Regards, Owen
On Mon, 2005-03-07 at 18:03 -0500, Ambrose Li wrote:> On Mon, Mar 07, 2005 at 05:26:58PM -0500, Owen Taylor wrote: > > > 4) Attempt to merge face name and style/weight values > > > (so a face name of ''black'' and a style of ''italic'' would > > > yield a black italic font). > > > > > > 4) seems likely to be fragile and cause weird effects when faced with > > > unusual fonts. of 1) and 2), I suggest that 1) is a better choice as your > > > abstractions may never capture all of the possible variations (outline > > > anyone?) present in the ''face name''. So, that leaves 3). I think it''s a > > > poor choice as it makes the face_name="italic", weight="bold" case very > > > confusing, and leaves us with an imperative spec rather than a declarative > > > one. > > > > Well, I still haven''t changed my opinion away from: > > > > 5) Don''t add "face name", do whatever munging on fontconfig output > > is necessary to create artificial family names. > > Actually I am not sure what the difference between (4) and (5) really is. > > Option (4) tries to come up with a combined font name that describes > all its attributes. Then use this artificial font name (which includes > the original attributes) to do font selection.The difference between 4 and 5 is that with 5 I don''t have to add a confusing, duplicative, extra entry to PangoFontDescription. (And also consequently, if we implemented things that way, current Pango/GTK+ programs would be fixed, rather than it taking effect in the future as programs are updated to use a new API.)> Option (5) tries to subtract things from the face name until it comes > up with a probable family name, and if that fails do further munging. > We then create artificial attributes from any leftover from the original > name. Then we use the artificial family name, together with the original > plus artificial attributes, to do font selection. > > Is the above understanding correct? If it is, (5) sounds even more > fragile than (4); if not, I don''t understand how the two differ...There are multiple ways that 5 could be implemented. I don''t think it would be particularly fragile. Without fontconfig support, it might be particularly slow. Regards, Owen
On Mon, Mar 07, 2005 at 08:40:42AM -0500, Owen Taylor wrote:> What font is selected when those conflict?For the particular example I gave in the bug, the font with lining figures is always selected. I don''t know why this is the case; the "expert" one not being selected is probably because it''s not complete, but I don''t know why it would not select the font with oldstyle figures (perhaps it''s slightly incomplete too). BTW, "Apollo MT" is a very mild example. I have another typeface "Poetica Chancery" with 21 fonts which is much worse: in gimp 2, it appears as 3 instances of "Poetica" (always the same capitals font) and 18 instances of "Poetica Italic" (always the same italic [i.e., cursive] font). And all these (all of them having the same weight and the same slant, except the capitals because originally italic faces had the property that lowercase letters are slanted but uppercase letters are not slanted) should either be in the same family (just "Poetica", but have to be able to select any of the 21) or else split to 21 distinct families in order to be useful. My feeling is that trying to map everything to the CSS model is hopeless, unless we want to create fake font families on the fly. Mapping font properties to CSS properties might be somewhat fruitful, but most commercial Type 1 fonts have variants that bear absolutely no relationship to CSS properties; there are also some more surprising inventions from the commercial font world, such as typefaces that distinguishes between two variants of small caps (e.g., Emigre''s "Mrs Eaves"). With the current behaviour, commercial fonts are almost completely useless. (I had hanged onto Gimp 1 for a very long time until I decided to switch a few weeks ago for my tablet and also better handling for non-Latin fonts; however, the much-worse font handling w.r.t. Type 1 was basically the reason I was so reluctant to switch.) Regards, Ambrose
Around 18 o''clock on Mar 6, Ambrose Li wrote:> I was told that "there''s not much that can be done currently, > since the fonts don''t differentiate themselves enough for > pango to generate unique font descriptions for them."There''s the limitation -- pango doesn''t expose the varients in any extensible fashion, it has only two variables (weight/slant) and a limited number of values for each one (2 each?). Pango should, in addtion, provide a list of style names for each family for applications which want to select by name. As many TrueType fonts provide extensive localization for these style names, it''s not even a terrible localization problem. Owen just needs more people complaining so that he''ll figure out how to provide a more comprehensive style solution. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050306/57be3226/attachment.pgp
Around 9 o''clock on Mar 7, Ambrose Li wrote:> My feeling is that trying to map everything to the CSS model is > hopeless, unless we want to create fake font families on the fly.Which is precisely what font foundaries often end up doing. I bought a family last week (Cloister Old Style) from myfonts.com only to find that the four standard variants had four separate family names. I had to go edit them with fontforge. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/a537470b/attachment.pgp
Around 13 o''clock on Mar 7, Ambrose Li wrote:> I have been wondering whether someone has entertained the idea > that fontconfig (or some other layer) can have a config file > that specifies something like "the italic version of this > font is that font" or "the bold version of this font is that > font", or, "to get CJK/Cyrillic/Hebrew/Arabic characters from > this font, use that font".You can do this when matching fonts, but you can''t change what names are returned for each font. I''ve avoided this strenuously because of trademark issues; font vendors get very nervous when you talk about representing their fonts with different names. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/433531e6/attachment.pgp
Around 16 o''clock on Mar 7, Ambrose Li wrote:> So even if we consider free fonts (even the GPL sense of free), and > even if we consider TrueType and not Type 1, we still have to deal > with this exact same problem.Of course. Windows has forced the world to admit to only four styles for each family; any family with more than that has to find another way to express them through the Windows UI. Fortunately, the GPL fonts will permit changing of the family and style names to fix this problem. It''s just a bug. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/3b0251ae/attachment.pgp
Around 16 o''clock on Mar 7, Owen Taylor wrote:> The logic follows, yes. I''d rather not have to explain it to my users > that way :-)I''m less concerned about the logical complexity than the outright impossibility of modifying a selected face with a different slant or weight. If every font description includes a normative style name, then you would want to eliminate any API accepting a description which sets the subordinate style selector values. It seems like the descriptor would need an informative style set by the system and a normative style selected by the user.> (needs extension to handle localized names ... > get_face_name_for_language() likely)If you come up with a useful abstraction which you think could live in Fontconfig, let me know. I''m not going to add (more) code which isn''t actually useful... -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/a704210b/attachment.pgp
Around 8 o''clock on Mar 7, Owen Taylor wrote:> I don''t want to have overspecified font descriptions > where we have *both* a textual description of the style and also > CSS properties. What font is selected when those conflict?Hand them all to fontconfig and let it sort this out. When specified, and explicit style name always overrides the CSS style values. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/df99f3e2/attachment.pgp
On Mon, 2005-03-07 at 14:22 -0800, Keith Packard wrote:> Around 16 o''clock on Mar 7, Owen Taylor wrote: > > > Perhaps the name PangoFontDescription is confusing. It doesn''t describe > > a font (or face), rather it is a description of the needs of an > > application to Pango. So, there would never be a reason to include > > informative information in it. > > Thanks for the clarification. > > I see several options for pango then: > > 1) "face name" wins > 2) abstract style/weight wins > 3) last set wins > 4) Attempt to merge face name and style/weight values > (so a face name of ''black'' and a style of ''italic'' would > yield a black italic font). > > 4) seems likely to be fragile and cause weird effects when faced with > unusual fonts. of 1) and 2), I suggest that 1) is a better choice as your > abstractions may never capture all of the possible variations (outline > anyone?) present in the ''face name''. So, that leaves 3). I think it''s a > poor choice as it makes the face_name="italic", weight="bold" case very > confusing, and leaves us with an imperative spec rather than a declarative > one.Well, I still haven''t changed my opinion away from: 5) Don''t add "face name", do whatever munging on fontconfig output is necessary to create artificial family names. Though I''m somewhat worried that this isn''t efficiently implementable and would require shadowing the entire fontconfig font database. Regards, Owen
Around 16 o''clock on Mar 7, Owen Taylor wrote:> Perhaps the name PangoFontDescription is confusing. It doesn''t describe > a font (or face), rather it is a description of the needs of an > application to Pango. So, there would never be a reason to include > informative information in it.Thanks for the clarification. I see several options for pango then: 1) "face name" wins 2) abstract style/weight wins 3) last set wins 4) Attempt to merge face name and style/weight values (so a face name of ''black'' and a style of ''italic'' would yield a black italic font). 4) seems likely to be fragile and cause weird effects when faced with unusual fonts. of 1) and 2), I suggest that 1) is a better choice as your abstractions may never capture all of the possible variations (outline anyone?) present in the ''face name''. So, that leaves 3). I think it''s a poor choice as it makes the face_name="italic", weight="bold" case very confusing, and leaves us with an imperative spec rather than a declarative one. At least, that was my reasoning when selecting the ''face name'' wins rule for fontconfig. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/eee05984/attachment.pgp
On Mon, Mar 07, 2005 at 05:26:58PM -0500, Owen Taylor wrote:> > 4) Attempt to merge face name and style/weight values > > (so a face name of ''black'' and a style of ''italic'' would > > yield a black italic font). > > > > 4) seems likely to be fragile and cause weird effects when faced with > > unusual fonts. of 1) and 2), I suggest that 1) is a better choice as your > > abstractions may never capture all of the possible variations (outline > > anyone?) present in the ''face name''. So, that leaves 3). I think it''s a > > poor choice as it makes the face_name="italic", weight="bold" case very > > confusing, and leaves us with an imperative spec rather than a declarative > > one. > > Well, I still haven''t changed my opinion away from: > > 5) Don''t add "face name", do whatever munging on fontconfig output > is necessary to create artificial family names.Actually I am not sure what the difference between (4) and (5) really is. Option (4) tries to come up with a combined font name that describes all its attributes. Then use this artificial font name (which includes the original attributes) to do font selection. Option (5) tries to subtract things from the face name until it comes up with a probable family name, and if that fails do further munging. We then create artificial attributes from any leftover from the original name. Then we use the artificial family name, together with the original plus artificial attributes, to do font selection. Is the above understanding correct? If it is, (5) sounds even more fragile than (4); if not, I don''t understand how the two differ... Regards, Ambrose
On Mon, Mar 07, 2005 at 09:52:16AM -0800, Keith Packard wrote:> Which is precisely what font foundaries often end up doing. > I bought a family last week (Cloister Old Style) from > myfonts.com only to find that the four standard variants > had four separate family names. I had to go edit them with > fontforge.Which brings up another question: I have been wondering whether someone has entertained the idea that fontconfig (or some other layer) can have a config file that specifies something like "the italic version of this font is that font" or "the bold version of this font is that font", or, "to get CJK/Cyrillic/Hebrew/Arabic characters from this font, use that font". (This is basically how WordPerfect 5.0 handled fonts.) Perhaps it had been suggested and even voted down; I don''t know :-) Now that the WangNew fonts are here, the point is probably a little bit moot, but back in the days that we had almost no free CJK fonts, a specification like "the bold version of AR PL Mingti2L Big5 is Kochi Gothic" or "the italic version of AR PL SongtiL GB is AR PL KaitiM GB" would solve a lot of problems (and is typographically sound). Regards, -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org> http://ada.dhs.org/~acli/
Around 14 o''clock on Mar 7, Owen Taylor wrote:> Would you count it as expected that: > > desc = pango_font_face_describe (face); > pango_font_description_set_weight (desc, PANGO_WEIGHT_BOLD); > > /* Use desc */ > > Ignores the call to set_weight? (because describe() sets some > "face name" field)(did you mean "style name"?) Hmm. Sequence doesn''t exist in fontconfig. I think that might make a difference for the user... If you think of the style name as restricting the available variants to the selected style, or selecting a sub-family with the ''postscript name'', then the ''set_weight'' call is no more ignored than if face was already black; it''s requesting the ''bold'' variant of ''Cloister Old Style Roman'' which doesn''t happen to have a bold variant. Consider the fonts I just got -- named Cloister Old Style Roman, Cloister Old Style Italic, Cloister Old Style Bold and Cloister Old Style Bold Italic. All of these advertised a single style named ''Roman'' (the humor of a ''Roman'' ''Italic'' font clearly escaped the publisher). If the ''description'' returned is used by the application to present information to the user and to select fonts, then we have a problem as it should contain the style name so the user can read it, but it shouldn''t have the style name as a constraint on the selection. Perhaps those two notions could be separated somehow? -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/e813d23b/attachment.pgp
On Mon, Mar 07, 2005 at 12:40:59PM -0800, Keith Packard wrote:> > Consider the fonts I just got -- named Cloister Old Style Roman, Cloister > Old Style Italic, Cloister Old Style Bold and Cloister Old Style Bold > Italic. All of these advertised a single style named ''Roman'' (the humor > of a ''Roman'' ''Italic'' font clearly escaped the publisher).I had written my previous reply too quickly. In fact I can pull out an example from the free fonts world. Consider the WangNew fonts (that I previously mistakenly said would make my wild suggestion a bit moot). It has - HanWangMingBlack:style=Regular - HanWangMingBold:style=Regular - HanWangMingHeavy:style=Regular - HanWangMingLight:style=Regular - HanWangMingMedium:style=Regular among many others. Now these obviously are parts of the same typeface "HanWangMing", just different weights. So even if we consider free fonts (even the GPL sense of free), and even if we consider TrueType and not Type 1, we still have to deal with this exact same problem. Regards, Ambrose
Around 17 o''clock on Mar 7, Owen Taylor wrote:> 5) Don''t add "face name", do whatever munging on fontconfig output > is necessary to create artificial family names.You can already use fullnames, although fontconfig doesn''t (currently) match on them. It still seems wrong to me though; style names are a superset of the CSS2 catagories, most applications just want to list the available styles by name. This CSS2-based artificial restriction is only visible to applcation programmers; exposing that to users, or making it really hard to hide from them doesn''t seem like a good idea to me. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/9dd70ab9/attachment.pgp
Around 18 o''clock on Mar 7, Ambrose Li wrote:> Option (4) tries to come up with a combined font name that describes > all its attributes. Then use this artificial font name (which includes > the original attributes) to do font selection.That wasn''t what I intended to describe. I was thinking that we''d examine the face name provided and then select bits from the slant/weight values which weren''t expressed in the style name. So, if you ask for face name "black", weight ''bold'' and slant ''italic'', the requested weight would be overridden by the expressed style but the slant would be used to select a black italic face. Note that I also suggested that this seemed more confusing than just having style name override weight and slant values. I agree that option 5) seems even more fragile; depending on extracting unexpressed varients in the face name and merging them with the family name. The alternative would be to just use Postscript Fullname and ignore styles altogether. That''s where Windows has pushed many fonts. I see CSS2 style/weight values as less-precise than face names and I''d really like to see applications move towards just using the face names when asking the user to select a style. Font substitution is a different matter; for that, you''d extract the face name, style and weight and hand them back to fontconfig which would prefer fonts with a matching face name and fall back to fonts with the nearest available style and weight. I guess I don''t see why having two separate and well defined mechanisms for selecting a font variant is all that bad; applications will likely have clear reasons to prefer one over the other in different situations. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20050307/1798c66d/attachment.pgp
Hi, I recently filed a bug in gimp related to font selection, and was told that it is currently technically impossible to fix. So I wonder if the problem might be at the fontconfig level. Precisely, I''ve got a lot of commercial Type 1 fonts; fontconfig has never been able to handle them properly (from a user''s viewpoint, that is). I gave an example in my gimp bug report (gnome bug #169314): The typeface "Apollo MT" has 9 fonts, corresponding to regular, italic, and semi-bold (each with three variants: lining figures, old-style figures, and "expert"). Fc-list correctly lists all 9 fonts. However, gimp cannot distinguish between the different variants of each style, so in gimp, only 3 fonts (regular, italic, and semi-bold with lining figures only) are available. I was told that "there''s not much that can be done currently, since the fonts don''t differentiate themselves enough for pango to generate unique font descriptions for them." So my question is, - Is the "style" attribute returned by fc-list useful at all for differentiating between fonts (for the purpose of font selection)? - If the above is no, would this be a bug in the fontconfig level? At the pango level? or higher up? (Gnome bug 95043 seems to suggest that it''s a bug at the fontconfig level.) Thanks very much. Best regards, Ambrose