LANG, locale, unicode, setup.py and Debian packaging

Donn donn.ingle at gmail.com
Sun Jan 13 08:50:49 EST 2008


> If you can all ls them, and if the file names come out right, then
> they'll have the same encoding.
Could it not be that the app doing the output (say konsole) could be 
displaying a filename as best as it can (doing the ignore/replace) trick and 
using whatever fonts it can reach) and this would disguise the situation?
 I don't think one can call any string a plain ascii string anymore.

I have been looking for somewhere online that I can download files obviously 
in a non-ascii set (like japan someplace) but can't find anything easy. I 
want to see exactly how my system (Kubuntu 7.10) handles things.

> I never heard before that font files use non-ASCII file names, 
They are files, named as any other file - those that are created by people get 
called whatever they want, under whatever locale they used.
Still, I don't fully understand how this is all handled.

> don't see the point in doing so - isn't there typically a font name
> *inside* the font file as well, so that you'd rather use that for
> display than the file name?
Yes, but sometimes I can't reach that - segfaults and so forth. I also need to 
write the filename to a text file for logging. 

> Of course, *other* files (text files, images etc) will often use
> non-ASCII file names. 
Same as font files - I am talking mainly about TTF files here. Mainly Arrr, 
pass the rum, matey fonts ;) (Which I don't use in designs, but have kept 
over the years.)

> However, they won't normally have mixed 
> encodings - most user-created files on a single system should typically
> have the same encoding (there are exceptions possible, of course).
Well, if I am collecting fonts from all over the place then I get a mixed-bag.

> > Meaning, I am led to assume, the LANG variable primarily?
> Yes.
Thanks. Good to know I'm on the right track.

\d



More information about the Python-list mailing list