[tlug] Problem sort-of solved ( GTK2: Displaying Japanese font names in Romaji)

[Matt Gushee <matt@example.com>]

Well, "solved" is a relative term, I guess ...

Stephen J. Turnbull wrote:
> > > > > > "Matt" == Matt Gushee <matt@example.com> writes:
>
>     Matt> That's a bit different from mine. My fonts.cache-1 contains
>     Matt> entries like

> That looks f**ked to me, because it's not "en,ja", it's "en,ja,en",
> since when you look at your fonts.cache-1 you see three names, the
> first of which is mojibake.

You're right. I saw what I wanted to see, and ignored the rest. And 
didn't at first catch the correspondence of the language ids to the font 
names.

>     Matt> Here's something interesting, though. Many of the entries in
>     Matt> fonts.cache-1 begin like this:
>
>    "DFHsm3.ttc" 1 "ÇcÇeÇoï~ê¨ñæí©ëÃW3,~~~~~~~~W3,DFPHSMincho\\-W3:
>
> My guess is that the en,ja,en in the familylang is causing you to pick
> up the mojibake in en* locales.  I wonder if you could edit
> fonts.cache-1 to make that xx or ru ro something that you will never
> have in a locale....

Well, I ended up editing the damn thing. I (1) changed all instances of 
'en,ja,en' to 'en,ja'; (2) deleted all the mojibake names; and (3) moved 
the English names before the Japanese ones. As always, thanks for the 
sage advice.

But I don't like it. It's fragile, it doesn't fix what gets 
auto-generated--*and*, here's the creepy thing, it appears that in 
certain cases the per-user font cache in my home directory, which gets 
auto-generated at intervals, can mask the hacked one in the font 
directory [see also Meta-rant below]. At least that's my best guess. 
Because last night, I edited the cache file in the font directory, and 
finally had legible names for my Japanese fonts. I then proceeded to use 
a couple of the newly accessible fonts in an OpenOffice document. But 
when I reopened it today, all the glyphs in those fonts had disappeared!

I tried deleting my personal cache file, but it appears that apps using 
Xft (?) require that file to start. Copying over my hacked cache file 
and setting it read-only didn't work too well either. Eventually I got 
my nicely-named fonts back, but I'm not sure exactly how.

By the way, it appears that Fontconfig's config files (e.g. 
/etc/fonts/{fonts|local}.conf) don't affect the behavior of fc-cache. At 
least, the documentation is all about configuring font *selection*; I 
also had a look at the source code today. I'm not much of a C 
programmer, but I saw that there is an FcDirScanConfig function, one of 
whose arguments has a type of FcConfig*, and a FcDirScan function, which 
simply invokes FcDirScanConfig with a value of 0 for the FcConfig*. And 
fc-cache uses only DirScan :-(

~ Meta-rant ~
I get frustrated by the growing amount of seemingly random behavior on 
Linux systems, which emulates one of the most annoying aspects of 
Windows. Case in point: making certain fonts accessible by hacking a 
cache file, only to have them later become inaccessible again, *without 
the hacked file having been changed.* Of course, we know that the 
behavior isn't really random, but its causes are deeply hidden.

I have to wonder: is this an *inevitable* side effect of the effort to 
make Linux more "user-friendly?" Or is it due to the particular 
(Windows-like) model of user-friendliness that is favored by the 
mainstream? Or what?

--
Matt Gushee
: Bantam - lightweight file manager : matt.gushee.net/software/bantam/ :
: RASCL's A Simple Configuration Language :     matt.gushee.net/rascl/ :