[Freemint-list] XaAES Russian fonts

Vincent Rivière vincent.riviere at freesbee.fr
Tue May 9 13:54:20 MSD 2017


On 09/05/2017 at 00:56, Dima Sobolev wrote:
> It was to make compatibility with EmuTOS and STeem, which already
> used such a code. We just 'shifted' Latvian number as Latvian version
> in fact never exist,

For memories, here is the story.

- In 2010 we added Russian support in EmuTOS. As we didn't know any 
official Russian country code, we chose 19.

- Then Russian support was added to Steem, with code 19.

- In 2012 I discovered that Russian code was previously defined to 32 
(but unused) in FreeMiNT sources and TosHyp. So I changed the Russian 
country code in EmuTOS from 19 to 32.
https://github.com/emutos/emutos/commit/13aa2739d808cf87b8db89f850dc0d2412584b09

- Dima complained that it wasn't compatible anymore with other software 
(i.e. Steem).

- In 2013, after discussion here on the MiNT Mailing List, we agreed to 
finally officially adopt 19 everywhere for Russian. I checked it finally 
worked fine in EmuTOS + XaAES, after putting 19 in the NVRAM:
http://sparemint.org/mailinglist/Mailing-Lists/MiNT-List.201301/50FA661F.8010507@freesbee.fr.text
(BTW: Why is this period missing from MiKRO's archives?)

So at that time, there was no know issue.

> But seems that we should do one more change that time - in the place
> from which we have this double char Country code.
>
> /> static char countrycodes[] =
>>
>> "endefrukesitsefsgstrfinodksanlczhuplltrueebyuaskrobgslhrcscsmkgrlvilzaptbejpcnkpvninirmnnplakhidbd";
>>
>> As you can see, for some reason the index used isn't 19 but 32.
>
> This is now main issue. Somewhere 'ry' is still on the 31.

We may have forgotten that place. In this case, we must fix it.

> I tried to create and edit nvram-file (it was not exist in my
> installation) and put relevant settings,

Beware, you can't easily hack NVRAM files manually. You have to also fix 
the checksum, otherwise it will be considered as invalid. I'm not sure 
of how checksum may be handled with various emulators, though.

> but AFAIK it is related to EmuTOS only (and in fact - it doesn't work
> for Russian EmuTOS, to get Russian version of EmuTOS, I should
> compile it with an option UNIQUE=RU).

In EmuTOS, there is no know bug related to NVRAM / AKP. If it doesn't 
work, maybe there is a checksum problem as described above.

Note that a Russian-only EmuTOS (compiled with UNIQUE=ru) will always be 
displayed in Russian, even if the value of the AKP cookie (or NVRAM) is 
incorrect.

Beware, Jo Even said something like FreeMiNT keyboard tables could also 
change the UI language in the AKP cookie. Even if this behaviour looks 
like a nonsese, it should be considered.

> But - as I remember, EmuTOS could be on one Langiuage and then XaAES
> on another... So it should not depend on nvram...

 From my old messages, I see that XaAES language can be defined with 
"lang =" in xaaes.cnf. If this line is commented out, then the NVRAM 
country code (if valid) will be used by XaAES as UI language.

-- 
Vincent Rivière


More information about the Freemint-list mailing list