Keith Packard <[EMAIL PROTECTED]> writes:
> > - They pull up a Traditional Chinese document (not itself tagged) > > in their word processor and see that it is a mix of MS Gothic and > > AR PL KaitiM Big5. > > > > - They select "AR PL KaitiM Big5" from the font menu. > > > > - The display doesn't change because Xft is still finding > > MS Gothic which matches the language tag. > > It matches the locale language tag, but the document doesn't have a > language tag. Are you suggesting that the locale language tag be used for > documents which have no language tag? Hmm. This is getting complicated. Yes, GTK+ does this currently ... it always provides a default language tag for every Pango context based on the locale; the idea is that: - most documents a user views are in their own language. - user's will typically not be offended by seeing their own variants for characters with multiple display variants, even for other lanugages. - we then don't need a _separate_ mechanism for configuring the default fonts for different users. [...] > Somehow, we need to use the language tag when selection which fallback > font to pick, but not when choosing between "real" family names provided > by the application. > > Hmm. It feels like there is a cut-over in the list of families; the first > part of the list is "language tag independent" -- family names provided by > the application should normally be preferred to families selected by > language tag, family names used as fallbacks should be ordered by language > tag fit. This seems similar to the idea of "explicitely specified" fonts I tried to develop in: http://mail.gnome.org/archives/gtk-i18n-list/2002-May/msg00053.html Though I was thinking of doing language-tag selection for both "explicitely specified" and "not explicitely specified" fonts, just not between the two. > Here's a suggestion (please feel free to knock holes in it): > > Tag entries in the family list as to whether they're language-tag selected > or not language-tag selected (or perhaps just whether they're "fallback" > or "non-fallback" entries). Edits relative to those entries are > contaminated and the resulting entries inherit that state. Now the config > file tags the 'sans-serif' alias as a 'fallback' entry; now those entries > are matched based on the distance from the language tag (as well as the > order within the list). That sounds reasonable to me; I was thinking of a slightly different mechanism which would effectively track a position in the family list where everything before that position was not fallback, and everything after that position was fallback: Basically, we want family names that were explicitely given by the user, or family names where the expansion only involved <prefer> elements. But that's probably even more complicated to implement, magical, and confusing. Regards, Owen _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
