>>>> "Ville" == Ville Skytt <Ville>
writes:
> If we're going to patch this, let's either not be
wildcarding
> it quite so much, or add some code to tell us why there's a
> problem (see the 21.5 input-method-xlib.c code for an example)
Ville> Yep, a real fix would of course be very welcome.
Don't hold your breath, it's an XFree86 bug (IMHO). What's happening
is that XFree86 apparently deals with a "utf-8" character set, but
doesn't know what "ISO 10646-1" is. I don't understand how an
organization where Markus Kuhn regularly posts to its I18N list can
get I18N so wrong, but they do. :-(
Ville's patch isn't actually as bad as it looks because what actually
happens (in theory, remember we're talking XFree86 I18N here) is that
each charset used by the locale is matched against each XLFD. So
something like
-adobe-courier-medium-r-*--*-120-*-*-*-*-iso8859-*, (more stuff)
actually will start by collecting as many Latin-* Adobe Courier fonts
as are relevant to the locale (which for UTF-8 is all of them, even if
it's actually en_US.utf8, how broken do you want it, we can give it to
you ;-), then go on to handle (more stuff) in the same way for any
desired charsets not yet added to the X Font Set.
Still, it's really preferable to have the users, not us and not X,
making decisions about what fonts are (a) common (last ditch resort)
and (b) good-looking and common enough to deserve a try in the defaults.
The best way to suppress the warning is change LANG to something other
than *.utf8.
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.