I'll have to look into the codebase with charset issues in mind (I've worked with international software for around 15 years now).
Thanks, that would be much appreciated! I filed a bug with some more details on what exactly breaks where.
On file versus display encodings, off hand I think you're correct. However... for the local filenames, things might get tricky. It might be that things need to work in the local encoding, or... it might be that the encoding of the filesystem needs to be used.
I think at least on Linux, the kernel translates from/to filesystem encoding and presents everything in the locale encoding regardless of filesystem (if properly configured). And on Windows, is there such thing as different filesystems at all?
Hiding these issues for many people is the recent change to UTF-8 for the local encoding setting (such as with RedHat 8.0). Since the local encoding is the same as the encoding needed for internal/display calls, programmers don't notice the potential problems. Also... if users and programmers aren't actually testing with non-ASCII names (i.e. names with characters outside of $00-$7f) then they will also not see any problems even if they exist for their configurations.
True, obviously nobody ever tested Sodipodi/Inkscape with non-ascii filenames (even though "Sodipodi" is written in Russian on the site :)
_________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2...