Foreign Characters

Hi,

Playing around with Keyshow here, but struggling with some foreign characters... how do I type lower case 'a' with an umlaut.... ya know two dots above the ltter.

I've tried copying stuff from this type using OWB-MUI:

http://www.omniglot.com/language/time/months.htm

But when I paste into Notepad its garbaged:

Eg. März - fine in the browser... in notepad messed up.

Edit: And what about November... how do I type a with a wavy tilde sign above it? :S

A-umlaut = Alt-K followed by A = ä
A-tilde = Alt-J followed by A = ã

OWB and NetSurf support UTF-8 in the clipboard, however no other apps do (Pagestream should by now, but I'm locked out of the new 68k betas so can't check). If you copy from a browser to another app you either need to copy in local charset (option in the Edit menu for OWB-RA, in Prefs for NetSurf, not sure about OWB-MUI, I have a problem with fontconfig I can't be bothered to fix so it takes a week to start up) or paste into a UTF-8 clipboard-supporting app.

Same with MUI edition, you use the lower menu option.

Thanks guys, struggling with some Polish characters here:

What about n as is:

styczeń

And s as in:

środa

And z as in:

październik

And finally for now:

This funny mark underneath the a:

piątek

@djrikki

Neither of those are available in ISO-8859-15 (or -1 for that matter). If they were, it would be alt-F followed by S, N or Z. You probably need an Polish charset (ISO-8859-2 or ISO-8859-16) and a keymap to go with it.

Further to my earlier comments, it looks like OWB-MUI's UTF-8 clipboard support will not interoperate with any other application. NetSurf-RAOWB works one way (NS accepts OWB's UTF-8, but not the other way round)

@Chris

How's that? Are the IFF files from Netsurf and OWB different?

Here's an example from OWB with "abc" as the string:
> type hex CLIPS:0
0000: 464F524D 00000030 46545854 43485253 FORM...0FTXTCHRS
0010: 00000003 61626300 43534554 00000018 ....abc.CSET....
0020: 00000001 00000000 00000000 00000000 ................
0030: 00000000 00000000

@Thematic

OWB-MUI is completely broken as far as UTF-8 clipboard is concerned. It is using codeset 1 (undefined on OS4, apparently UTF-8 on MorphOS), and is setting this AFTER the text content.

FTXT is supposed to be processed sequentially, so you can change formatting throughout the text. This means that the codeset is assumed to be local charset for the text, and then gets changed to undefined/UTF-8 for the next non-existant block.

I've tweaked NetSurf so it accepts pastes of codeset 1 as being UTF-8 (in case there are any other broken MorphOS ports out there), but I can't do anything about it being set late, so it still won't work. Copying to OWB-MUI will never work as long as it expects codeset 1.

Your example from NetSurf:
0000: 464F524D 00000030 46545854 43534554 FORM...0FTXTCSET
0010: 00000018 0000006A 00000000 00000000 .......j........
0020: 00000000 00000000 00000000 43485253 ............CHRS
0030: 00000003 61626300 ....abc.

and the same from RA-OWB:
0000: 464F524D 00000038 46545854 43534554 FORM...8FTXTCSET
0010: 00000020 0000006A 00000000 00000000 ... ...j........
0020: 00000000 00000000 00000000 00000000 ................
0030: 00000000 43485253 00000003 61626300 ....CHRS....abc.

Actually, I'm missing two reserved LONGs from CSET somehow, so I'll add those.

edit Fixing a schoolboy multiplication error has made RA-OWB recognise NetSurf's UTF-8 clipboard text, so those two now communicate properly - and the hex dump of the clipboard is identical. It looks like OWB-MUI also has this error!

Thanks all.

I am trying to create a range of language files in Notepad, but experiencing problems with certain languages and the their foreign characters.

Quote:

While it's true the old 1.9 version was using 1 as codeset, i was still set BEFORE. No idea why you get it after on OS4.
Unicode to local charset copy could be done manually at that time, by using pulldown menu -> copy with local charset (or so).

Anyway, all this is irrelevant, because i've reworked UTF8 clipboard management since quite a while in OWB.

Now, when copying, i store the first chunk as ID_CHRS (with data converted to local charset), and the second as ID_UTF8 (which is not 1, but no idea if it's the same value as OS4).
When pasting to OWB, the ID_CHRS chunks will first be tried (and converted from local charset to UTF8) and if ID_UTF8 chunks are found, they'll be used instead.

Other MorphOS applications work that way, and it behaves just nice.

As for input, OWB for MorphOS uses MapRawKeyUCS4() to handle input. I guess only the MapRawKey() fallback was used on the OS4 port. If there's anything similar in OS4 API, kas1e should make use of it to handle unicode input.

Can anyone interested in a full UTF8 only Input option for AmigaOS4.x please send me a list of all the current European language key-combinations for umlauts and other extended character marks please?

I'm going to be putting together a Universal Input Method Editor for AmigaOS4 and AROS

I was originally intending this for adding only Japanese to start with...but I may as well handle the basic "special case" characters

@fab

Quote:

Very strange.

Quote:

That looks like quite a good system. Nobody has officially said how this should be handled on OS4. I suspect Detlef would have had something to say on the matter, but sadly he disappeared years ago.

Quote:

MapRawKey is the only option, the output then has to be converted to UCS4. It's a bit vague, but AIUI the output from MapRawKey is always in local charset (however, it may well be in the keymap's chrset)

Is kas1e still working on OWB? I thought he'd given up. Would be nice to have a new version with the bugs fixed, the current one is too unstable for my taste (but a vast improvement on RA-OWB in all other respects).

@belxjander

Your best bet is to read through the keymap files.

btw, I added you to the openamiga project ages ago, did send you an email but didn't get a reply so don't know if you got it.

Check out bullet API.

@Chris - Yeah I got that Email, but the machine setup I am using decided to develop an allergy to any factory spec CPU capability ...
any usage above 80% factory spec of 2.5GHz and it switches itself off

@LiveForIt - I am not talking about Display,

@ChrisH + LiveForIt - Japanese and Chinese Input is not just a matter of a simple keymap
(there are over 350,000 Unique Kanji for Japanese alone...
I have seen an official dictionary, think of 2:1KG bags
of sugar, side by side as a book, it is a bit larger)

so combinations of
"a ka/ga sa/za ta/da na ha/ba/pa ma ra ya wa" is just the first of 5 rows... this won't fit a standard keyboard,

there are no less than 45 distinct Hiragana characters,
of which there are 3 modifiers,

In addition to this THE ENGLISH KEYBOARD REMAINS UNMODIFIED at the keymap for provision of the standard A-Z/a-z and symbols mappings...

so please don't assume that a keymap will solve the issue
it won't... that is why I am making the Perception IME to
deal with such things for languages unable to be supported
by keymaps alone.

I *will* be making a modified US Latin1 layout for use with
jp106 layout Keyboards (such as the one I used typing this)

Apologies if this seems offensive, but "bullet.library"
and "keymaps" are only small pieces of what I need to do.

Look at Windows or Linux or Mac OS for a "Language Bar" or
UIM/SCIM/IM-JA/...

this kind of tool is what I am working on for a complete
handler of any "Keyboard" device being attached to AOS4
and later on AROS as well.

//UTF8-NEW//Japanese//
「日本語はちょっと違うでしょう、でもねこの漢字はもちろんむずかしくないね。ごめんなさいでもこの漢字は英語のケーボードはむずかしにはいちゃたないでしょうね」//UTF8-END//
//Romaji-NEW//
NihonGoHaChottoChigauDeshou, DeMoNeKonoKanjiHaMochironMuzukashiKunaiNe.GomennasaiDeMoKonoKanjiHaEigoNoKeeBoodoHaMuzukashiNiHaiChattaNaiDeShouNe
//Romaji-END//

There is "Kanji" as Feelings or "Kanji" as Characters...
which do I mean? the only way to know is which character
and the normal limitations of a keyboard do not suffice
therefore use of the spacebar and enter/return keys are
changed when the IME is in Japanese/Chinese modes...
there is additionally "double-entry" modifiers as well.

use of the "-" symbol can mean "1" or "ichi" *OR* it can
mean the extension of the vowel[aiueo//Japanese Order]
following it.

Japanese selects 1 or 2 consonants of english with a vowel
or the vowels without.
with the option of... a- being an aa sound...
with the option of double-typing the first consonant
introducing either a doubling or other sound modifier.

Chinese also introduces 4 "tones" in addition with between
1 letter + tone, through to 7 letters + tone for selecting
any *single* Pictograph.

Please note... the Japanese I entered is spaceless and is reliant entirely on the reader being able to parse the correct Kanji.

so "Checkout the bullet API" is barking entirely up the
wrong tree... as display is already done

I am talking about *INPUT* which is entirely seperate from "Display"...

grrr...

That sounds like an interesting project indeed!

So you basically need to make individual keys do different things based on the context and/or mode you're currently in, partly based on keys having been used beforehand (or even afterwards )? Sort of like what is already being done with dead/deadable keys, except much more complicated and using many more of the available keys?

Obviously the existing keymaps and the system support for them cannot handle this.

Hopefully you will be able to build on some of the basics of the keyboard handling system (one end) and the input system (other end) , though, to make an extension which will plug in nicely. It might be something to include in the OS on a longer term.

Best regards,

Niels

@Belxjander

I agree with Niels. Having this in OS4 will be necessary at some point. I suggest that you check with ssolie to coordonate efforts.

Off topic but,

英語のケーボードはむずかしにはいちゃたないでしょうね

huh?

@kilaueabart

英語のケーボードはむずかしにはいちゃたないでしょうね

huh?

英語 = Eigo = "English" as said in Japanese,
日本語 = Nihongo = "Japanese Language" in the Japanese Language

the 語 Kanji literally means language...
the 英 Kanji has an imprecise reference to English from the UK

日本 is the Kanji name for Japan itself
( nihon & nippon are both valid for this Kanji pair)

English~Keyboard Difficulties~Data Entry~Wanted~You agree?
inexact but approximate word replacement without meaning.

Japanese and English don't literally mean the same thing due
to major structural differences...

English has a LOT more structure than Japanese,
mostly to do with "verb ending" and particles as
modifiers to what is said.

@all

and yes, I will co-ordinate with ssolie once I finally get
to writing this into an AOS4.x system of my own.

Ive also got a couple of other projects lined up as well,
which includes building a "developer cluster" for making
an accessible network system for developers that don't have
access to AmigaOS 4.x equipment for themselves.

but the "Perception IME" will be slotting into the existing
locale.library setup adding another library which will
remain optional.

I'm not going to force anyone to need the full installation
but when the additional library is present,
it will be *fully* functional.

@nbache

> That sounds like an interesting project indeed!

I have several open-source projects to work from which helps

> So you basically need to make individual keys do different
> things based on the context and/or mode you're currently > in, partly based on keys having been used beforehand (or > even afterwards )? Sort of like what is already being done
> with dead/deadable keys, except much more complicated and > using many more of the available keys?

not just individual keys but "string" based.
AIUEO K/G* S/Z* T/D N H/B/P* M* R Y W ordering instead of
Aa-Zz ordering for a start...

Not only single-deadable keys but double / triple and
for specific Chinese Entry examples...
there ARE currently full 8 key entry combinations
for selection of which list of symbols prior to triggering
display of the list to select...

so the "dead key" system on AmigaOS would not cope as
it would at best only handle double or triple combinations

there is a minimum of 3 keys for selecting singular Kanji
or Chinese Pictographs...for the most basic of entries.

> Obviously the existing keymaps and the system support for > them cannot handle this.

Seriously, this is *way* past dead-keys as I require
to have a typed string typed normally before triggeriing
any of the "string conversion" options using space or enter
which will then popup a menu listing of Kanji

state will be held along with Japanese 106 Keymap recognition
of the extra "Japanese only" keys on my own jp106 keyboard

These are not marked in English at all and have fixed functions.

Japanese also has like Chinese the attribute of being a
seperate written and spoken language...
each (written/spoken) is literally its own language
with translation skills required.

Certain words are used written but never spoken,
and there are the spoken words that are never written.

and for each Kanji you can have from 1 through to 5 different spoken words based on context.

> Hopefully you will be able to build on some of the basics > of the keyboard handling system (one end) and the input
> system (other end) , though, to make an extension which
> will plug in nicely. It might be something to include in
> the OS on a longer term.

I'm planning for this entire "extension" to the OS to be
added in a simple manner and make use of the existing options
that are already part of the OS itself where possible
just to apply the KISS rule.

so any inclusion later for the OS itself, will remain "optional".

SSolie and the rest of the OS developers only need to work
with me for the sum total of a documented mechanism for
Perception to slot into the rest of the OS with.

Beyond that there will be no requirement other than the existing standard locale.library and intuition.library API Interfaces to remain unchanged long-term.

I will be making Perception itself open-source once I can work out an acceptable license so that it can be a "3rd-party" addon option.

I *will* actively support and accept submissions and deal with this myself.

I will not burden the AOS4.x team with supporting it at all
I am more than willing to work entirely on my own as needed.

I just hope some users will support the additional addons
after buying the OS and working out which they need.

> Best regards,

> Niels

Quote:Ah, so the string is displayed "normally" while typed and then converted? I can see this is very far from dead keys in its construction, although the user will probably feel some similarity.

Quote:Sounds great! Hope a useful cooperation can be made.

Personally I don't have any knowledge of any of these languages, other than knowing they are a challenge to fit into computer input systems in general ). But it would be great for everybody to know they were supported (at least better than now) in our favourite system.

So best of luck with your work!

Best regards,

Niels