Re: [hatari-devel] GEMDOS filename handling

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Am Mon, 18 Aug 2014 23:33:47 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On maanantai 18 elokuu 2014, Thomas Huth wrote:
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > > 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.
> 
> Not gui modules, just the function drawing the text.
> 
> > 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.
> 
> Latter was what I was proposing for drawing the text, before
> I knew what encoding the SDL GUI font was using.
> 
> For internal representation I didn't propose anything, i.e.
> for now leaving file strings as they come from the system.

Ok, seems like I just understood you completely wrong... Sorry about
that!
I thought you suggested to use Atari encoded strings through the whole
emulator.

> > > 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
> > story)
> > 
> > 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.
> 
> Sounds good to me.

I can try to add the missing characters, but for the next two weeks,
I'll likely have no access to my computer, so if you want to have a try
first, you're welcome.

 Thomas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/