Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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/ :


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links