so I can use it whit iconv_open(), as I did not find a native Amiga API for encoding.
I assume you're using Newlib for the iconv functionality, not a statically-linked libiconv? And you're fine with the iconv conversion functions? I mean, it's not as straightforward as one would expect.
Yes I noticed, it looks like I need to know the length of the output, anyway I have not looked too much into it yet, only looked at one simple example.
I have my own UTF8 routines some where from many years ago, I just did not finish it because the codeset table was missing, it might be better to build a C++ Class around that as that's what I want to do anyway.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I think this one gives me the wrong CodeSet, this is the one from locale prefs?, I need the one from Input Prefs.
Quote:
AFAIK there are no other functions than the iconv ones, but for converting from/to unicode you can use the DFCS_MAPTABLE from IDiskFont->ObtainCharsetInfo().
Yes this looks correct, I think this will work for me, for encoding.
I will try more tomorrow.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I get “ISO-8859-1”, but should get “ISO-8859-15”, so I think this one has some thing to do locale prefs.
Yes it does, as already explained by joerg.
The CHARSET environment variable tells you which system charset you have in your system. Clearly this is ISO-8859-1, so you must have selected a language name without any code page extension as your first language back when you set up your languages in Locale prefs.
You may have selected a keyboard with ISO-8859-15 encoding in Input prefs, but that does not make any difference to your system charset (which among other things makes Locale select the font character sets you need to display correctly the characters present in your system charset).
So if you want a system which is purely using ISO-8859-15 (like I have), you need to make the correct language selection in Locale prefs: delete all chosen languages, select as your first one a language with Euro sign/ISO-8859-15 extension, and after that select any secondary language choices.
Locale is complicated, but only because life is complicated (in this case life with multiple languages and alphabets supported in the same OS).
I think this one gives me the wrong CodeSet, this is the one from locale prefs?
No, it's the right one, and yes, it is the one from Locale prefs.
If you want the system charset to match what you have chosen as a keyboard encoding in Input prefs, go set the system charset (in Locale prefs as explained in my previous post).
No, it's the right one, and yes, it is the one from Locale prefs.
I want the encoding that is the same as if type on the keyboard, so Input Prefs one is correct one for me, I'm not saying that encoding in Getenv Charset is wrong for some one else, but in my case its not the correct one.
I use English menus in workbench and programs, but use a Norwegian keyboard settings. Simple because there are not many programs that do support locals translations, so just keeps it more consistent to use English.
If this was another type of application I was making then yes you be right.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I want the encoding that is the same as if type on the keyboard, so Input Prefs one is correct one for me,
There is none, the charset encoding is set by Prefs/Locale, it's the only charset setting and used for everything, incl. keyboard input.
But you have to select a keyboard mapping using the same charset in Prefs/Input, therefore the charset is displayed there and there are different keymap files, for example Norwegian for ISO-8859-1 and for ISO-8859-15.
Quote:
I use English menus in workbench and programs, but use a Norwegian keyboard settings.
You have to select english in ISO-8859-15 ("english (€)") instead of english (using ISO-8859-1) as first language in Prefs/Locale. With your current prefs for example ALT-e doesn't work, with the Norwegian ISO-8859-15 keymap it's the € but since you have selected the wrong charset in Prefs/Locale it's wrong and can't be displayed.
Locale is complicated, but only because life is complicated (in this case life with multiple languages and alphabets supported in the same OS).
Would Unicode (UTF-8 or UTF-16) improve the situation? Can someone explain in layman terms if and why it would be difficult to make the whole OS use Unicode?
Locale is complicated, but only because life is complicated (in this case life with multiple languages and alphabets supported in the same OS).
Would Unicode (UTF-8 or UTF-16) improve the situation? Can someone explain in layman terms if and why it would be difficult to make the whole OS use Unicode?
Offtocpic? This entire thread is offtopic , you started by bitching about the prefs programs and ended up talking about how to find the system / input charset (they are the same...)
Offtocpic? This entire thread is offtopic , you started by bitching about the prefs programs.
Yes but that topic can take many pages whit arguing, I'm shore some one disagree whit me, or have there own apennines about the topic, and so it might end up 10 pages about that.
Anyway if you start bitching about it, who knows when its going to end.
Quote:
and ended up talking about how to find the system / input charset (they are the same...)
I think you can argue all day long, but they are not the same, some times a picture tell more then 1000 words.
Timezone prefs is a new program that was added to OS4.0 in March 2006. What it Does is set up the automatic daylight saving clock changes. Just tell it to use locale prefs and automatically switch from and to DST, click advanced, turn the top two options off, save and you never need to use it again.
Time prefs is for setting your local date and time and a server to ensure the clock is correct.
They do two different jobs so two different programs.
Amiga user since 1985 AOS4, A-EON, IBrowse & Alinea Betatester
Which raises the question as to why it exists in the first place. There's already a Timezone tab in Locale prefs, add the missing couple of options to that and scrap it.
One more attempt and then I'll let you write a buggy program....
Input prefs sets the keyboard map. This maps keystrokes to codes. At the moment these are single bytes sequences for the most as far as I can recall.
Those 8 bit numbers are then used by MapRawkey et al according to the character set specified in Locale.prefs.
There is no distinct input character set. Sometimes the name of the character set that the author of the keymap expects you to use is included in the "English description field"
That is a convenience to enable people to use the right keyboard with the right character set, but you can't rely on it, you can't rely on the format of it to parse it etc etc. Particularly if it happens to be a custom third party charset.
Quote:
unless people here are mind readers, they should stop telling me what I want.
When you are asking for help always tell the full story. You will get the best help that way.
Without knwoing what you really want, have you studied keymap.library ?
Which raises the question as to why it exists in the first place. There's already a Timezone tab in Locale prefs, add the missing couple of options to that and scrap it.
Why not, but then it depends on if someone has had the time to do it, if there are any underlying consequances, to the change etc etc.
No matter how much you ignore it it's still an user error, your settings are broken, you use ISO-8859-1 as charset (english_ISO-8859-1 instead of english_ISO-8859-15 as first language in Prefs/Locale) but a keymap in ISO-8859-15 which obviously can't work with it. The "CountryName" your broken program displays is just the file name of the non-working keymap file (KEYMAPS:n_ISO-8859-15) you are currently using.
@Amigo1 No, Unicode does not magically fix anything. There are multiple ways to encode characters and Unicode is just another one in a long list starting somewhere near EBCDIC.