Re: Language Setup Document (Re: Text drawing bug - gaps after 16th character ...)

[Kazunobu Kuriyama]

Pete French wrote:

> > So please avoid discussing it based on your own interpretation, leading
> > you to wrong viewpoints and conclusions.
>
>
> O.K. I didnt realise that there was a C standard for multi-byte . Have
> gone and looked it up (9and am trying to understyand what the hell it is
> trying to do).

You'll find it the hell literally...

> > I'm afraid what you observed with Russian characters is irrelevant to
> > the multibyte
> > representation. Actually, as you noted, each of them is represented with
> > 8-bit.
>
>
> ...or can be. They are represented as 16 bit in Unicode (and have to be
> as their values are outside the rnage of a single byte).
>
> I just tried to convert 0x400 tomutibyte representation to see what
> would happen though, and got a sinzezero byte ?! (but no error return)

Broadly speaking, Unicode defines a one-to-one mapping from an integer 
to a glyph
or the shape of a character, and is independent of encoding.  To display 
a unicode
datum on the screen, you need to convert it into an object in another format
in such a way that the underlying API (X library etc.) can accept it.
The actual character to be displayed is determined by the locale or encoding
in use, which relates the resulting object to the position of a given 
font table.

> At this point I shallshut up as I think I have no clue what I am talking
> about. I'm going to stick to doing everything in Unicode, much easier...
>
> -bat.
The problem we have been talking about lies in how to convert a Unicode
datum into another one which can be accepted by the underlying API to 
display
the character. The ways of conversion include utf8, multibyte, wide 
char, ...
The real hell on the earth.

- KK