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