Re: Font priorities
- From: Keith Packard <keithp keithp com>
- To: Owen Taylor <otaylor redhat com>
- Cc: Keith Packard <keithp keithp com>, Stefan Baums <baums u washington edu>, GTK-I18N Mailing List <gtk-i18n-list gnome org>
- Subject: Re: Font priorities
- Date: Tue, 04 Feb 2003 23:02:50 -0800
Around 0 o'clock on Feb 5, Owen Taylor wrote:
> With FreeSans being sorted above Raghindi because it matches the
> "en" language tag. But "Luxi Sans" has already taken care of
> the "en" language tag. So, this sorting is completely bogus
> from a user point of view (if not from a mathematical point
> of view.)
It's included in the list at all because it covers codepoints that aren't
covered by Luxi Sans. It seems you are suggesting that the language tags
should be ignored once the coverage fills the specified language set. An
interesting idea, but somewhat difficult to explain.
> One possible thing we'll be able to do in future versions of Pango, is
> that I plan to do script detection, so I'll be able to tell that
> a run of text is in Devanagari ... if you then had a table mapping
> from language => script, you could tell that the 'en' language
> tag _couldn't_ be appropriate for the Hindi text, though you would
> have no idea what language tag _was_ appropriate.
With everything but Han, it's pretty easy to map script ->
list-of-languages, which would suffice for this case. But, Han requires
additional support and so I think Pango will (eventually) need to expose
language tags to the application. I can't see a reasonable way to make
things work right without them.
> - fontconfig ignores all the fonts in the sans-serif alias, and
> goes to a different one, because it has 'en' coverage. Even
> though fontconfig already found Luxi Sans for 'en'.
I'll have to think how this might work in a specification and the
implementation; it's somewhat intuitive to describe like this, but a
formalism seems hard to capture.
> But then again, I don't think people are really understanding the weak/
> strong binding system, so any elegance for that is basically an
> implementation detail.
Yes, the weak/strong stuff is essentially an implementation detail that
leaked through to the API and configuration stuff because it wasn't
possible to make things "just work" in all cases without manual
intervention. A more automatic scheme would be preferred.
-keith
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]