Re: Hangul Jamo and wcwidth()

[Markus Kuhn <Markus.Kuhn@xxxxxxxxxxxx>]

Otfried Cheong wrote on 2000-03-06 11:23 UTC:
>  * adheres to Markus' definition of ``wcwidth()'' to select between
>    the two fonts, so that Emacs should work fine on a UTF-8 aware
>    terminal emulator.
>
> There are two exceptions to the last point. First, I had to
> arbitrarily make a decision for the user-defined range U+e000..U+f8ff.
>
> Second, I find the behaviour of "wcwidth" for the conjoining Johab
> range irrational.  It doesn't make any sense to make the leading
> consonant full-width, with vowels and finals being half-width. I don't
> want to have to split my glyphs over two fonts to see the Johab
> elements on software that doesn't support conjoining.  (On a
> conjoining renderer the result of conjoining should of course be
> full-width.)

Actually, I believe that X11 fonts should remain completely free of any
conjoining Jamo (U+1100 - U+11F9). This way, the question whether they
are half-width or full-width will not matter in practice.

Is anyone seriously planning to use ISO 10646-1 Level 2 for encoding
Korean? It is rather storage-space inefficient to decompose the Hangul
syllables (factor 3 blow-up).

I had always assumed that all Hangul that finds its way into POSIX
files, filenames, etc. will be exclusively from the precomposed
syllables in the U+AC00-U+D7A3 range. I thought of the conjoining Jamo
more as things that you might use temporarily inside input methods, but
nothing that should every be printed to the screen.

My fonts do not contain any U+1100 - U+11F9 Jamo, except for 6x13.bdf,
which contains the final consonant forms that appear at the moment in
the keysym mapping file of xterm. I simply copied these jamo from the
halfwidth positions to look at the keysym mapping. I guess I should
better remove them before they confuse anyone.

We also have to discuss urgently, whether the Korean keysym -> Unicode
mappings make any sense at all as they are at the moment. I simply
copied those that Richard Verhoeven <river@xxxxxxxxxx> had in his
original mapping table, and I am not sure whether either of us knew too
well what we are supposed to do here.

Have a look at the xterm keysym2ucs.c mapping on

  http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c

and let me know, how you would like the Korean part to be mapped (if
mapping makes sense at all, since Korean keysyms should probably go
directly into a proper Hangul input method).

Is there already a Korean input method available that could easily be
modified to output UTF-8 instead of the old KS C 5601? If yes, then I'd
rather prefer to remove the entire Hangul part of xterm's keysym -> UCS
mapping as it is probably completely useless.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/