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