Marc Lehmann writes: > "unix", in general, only supports characters from the portable filename > character set, so "in theory" there is no problem at all, as characters > >127 do not exist in that set. True, but in real life, I would assume most Unix systems are quite happy with using any bytes in path names except '/' and '\0'. It's then up to the site-specific or user-specific locale what charset these are interpreted to be in. I would also guess that very few Unix installations actually use UTF-8 locales now and in the immediate future. However, GTK+ 2.0 will use UTF-8. (And GTK+ 1.3 as used on Windows use it already.) It's good to start thinking a bit on the implications now. What I was looking for with my message was mostly an okay (or strong opposition) to adding code to GIMP at this point to convert back and forth between the file system charset and UTF-8. (As I said, said code would expand to semantically no-op g_strdup() calls on GTK+ 1.2.x, and thus would mostly be just a cosmetic issue.) One decision would be good to make now: Are the file names passed around in PDB calls in UTF-8 or in the "file system" charset (the current locale's charset)? Both approaches have pros and cons: - pass around UTF-8: GIMP and plug-ins have to convert to the current locale charset before doing system calls with path names. OTOH the strings can be directly passed to GTK+. - pass around path names as they are in the system: GIMP and plug-ins have to convert to UTF-8 when passing path names to GTK+ for display, and from UTF-8 when receiving pathnames from user input. OTOH they can be directly used in file system calls. My guess is that the second approaches is preferrable? --tml
