Re: Font lookup ranges [was Re: Notes on Pango Xft backend]

Keith Packard <keithp keithp com> 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

 - 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:

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]