|Re: [hatari-devel] GEMDOS filename handling|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Am Sat, 16 Aug 2014 15:17:32 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> On lauantai 16 elokuu 2014, Thomas Huth wrote:
> > NAK, again, this is really the wrong way to go. I think we really
> > should rather support (western-style) UTF-8 strings in the GUI
> > instead. I did something similar for Ballerburg SDL, too, see:
> > http://git.tuxfamily.org/baller/baller.git/?p=baller/baller.git;a=blobdif
> > f;f=src/sdlgui.c;h=185fbce139cea6d82b419a9f422da33fcdfa2d5a;hp=e25dcaaf21
> > 658c87a0c442596d3f4d3c5f45f98b;hb=fce95fd6a8225038d8f17554284a6db4ff571ca
> > 3;hpb=ad6a2a99bac840403793baff42f4a88cba9aa30c
> This differs from what I proposed only in one relevant aspect,
> Using latin1 instead of Atari encoding for font indexing.
Well, no, you've got to see it from the outside of the sdl-gui:
You proposed that the gui modules should be fed with Atari encoded
strings from the other parts of the code.
That could cause a major headache later when we introduce i18n.
Now the GUI is fed with UTF-8 instead, which should be the right
approach in the 21st century.
What the GUI is doing internally with the UTF-8 strings is just up to
the GUI. If it translates the strings to latin1 for rendering, or if it
translates them to some Atari or marsian encoding internally now does
not matter for the rest of the code anymore.
> Note that you need to add also filename -> UTF-8 conversion
> for things to work properly for OS versions that don't mount
> file systems with UTF-8 (older Linux & Windows). You can
> probably re-use Max code for that, as it already handles
> host <-> Atari and UTF-8 <-> Atari conversions, you just need
> to shortcircuit it a bit.
Actually, that's why I had this "has_utf8" magic in my patch for
Ballerburg: When that variable was not set, the GUI assumed latin1
instead by simply not doing the UTF-8 to latin1 convertion.
(of course that fails for non-latin1 locales, but that's another
By the way, the Windows codepage 1252 seems to be a superset of latin1,
so by adding the missing characters to our font.bmp files, we could
easily support that codepage, too.