At Fri, 27 Jun 2025 14:02:21 -0500 (CDT), "John D. Baker" <jdba...@consolidated.net> wrote: Subject: Fun with locales > > Some time ago, I learned that for GTK applications to choose "US Letter" > as the default paper size, I need to set something like "LANG=en_US.foo". > > I chose "en_US.US-ASCII". That seemed to work. > > Some applications, however, take exception to this locale and throw > interesting errors. Namely 'xlock' (x11/xlockmore) fails, complaining > about "Can't create FontSet blahblahblah,xyzzy" and some of the font > strings it prints look rather broken. There also appears to be a typo > somewhere and it also displays a message with "fonset" (sic).
That doesn't surprise me much. Many/most/all legacy X11 apps have
stupid default font choices, often still using XLFD specs and depending
on bitmap fonts with limited locales decades after we've had better
scalable fonts available by default in all X implementations.
You may find that the broken font specs are in the default resource
files, and updating those can help, though sometimes the app is just
hopelessly out of date.
> It worked fine for another user account on my system, but wasn't working
> any more for my regular account.
>
> The only change I'd made was setting "LANG=en_US.US-ASCII" in my
> '.xsession' script. Unsetting LANG entirely allowed 'xlock' to work.
> Setting LANG=en_US.UTF-8 allows it to work also.
There are still some terribly horrible choices in Xft APIs w.r.t. how
locales are treated when combined with use of legacy XLFD specs. This
only gets worse when dealing with font resolutions when handling broken
XLFD specs, and many/most users don't help this when they continue to
set the Xft.dpi resource incorrectly in an attempt to continue using
ancient bitmap fonts.
So, yes, ISO 10646 locales can often work better, assuming the modern
fonts are chosen as well.
There are some corner cases, e.g. with xcalc and xman, that get broken
partly because of stupid magic re-encodings of charsets in the default
.../locale/en_US.UTF-8/XLC_LOCALE file. These magic re-encodings are
also the origin of the infamous "Warning: Missing charsets in String to
FontSet conversion" message. They should all just be removed! Xman(1)
is more broken though. It is able to use fonts with iso10646-1
encodings, but it cannot handle UTF-8 output from nroff, so it must be
run with LC_CTYPE=en_US.iso8859-1 in the environment and
Xman*international:false in the resources, along with some new fonts
(explicitly specifying an iso8859-1 locale) in its resources as well.
There may be more I've forgotten already. I have a huge mess of
settings in my dotfiles that try to deal with getting UTF-8 everywhere
and to get properly scaled fonts on really-high DPI displays. Mostly
everything works relatively well, except for ancient apps that scale
their windows and buttons and such based on pixels, e.g. xv, xfig, etc.
While X apps could and should have always used physical on-screen
measurements for sizing things, the scaling of icons is one thing that
really never was tackled. CGM would have been an obvious choice but it
was maybe overly complex. The core GKS (X3.124 originally) might have
worked, and has certainly been around for long enough and was widely
used in some early graphics workstations.
--
Greg A. Woods <gwo...@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <wo...@robohack.ca>
Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>
pgpbC7Ds1tdvc.pgp
Description: OpenPGP Digital Signature
