[Indic-computing-devel] Re: NCST Indix Examined

[Tapan S. P. <ta...@ya...>]

Keyur, Koshy,

First off, I dont think the transformation suggested by Keyur can be
considered the "same as" UCS-2.  For instance, in some ISO encodings, such
as those for Cyrillic, Arabic, etc, the code point range 128...255 was used
for the special characters required for each such script, which would get
mapped to completely different (and unrelated) values in UCS-2.

So Keyur unless you are doing a table based mapping for all of these
encodings, which doesnt seem possible since you dont know the source
encoding, you are probably doing the wrong thing.  (Actually even if you
are doing things this way you would still likely end up with the wrong
result, since the fonts for such encodings are indexed by the ISO-style).

I think that is why Koshy suggested to test your server on those encodings,
and I tend to think things would break (badly) also, since initial
characters in the range 128..255 would be interpreted as multi-byte chars
in UTF-8, causing all kinds of funky UCS-2 characters to be emitted (and
eventually rendered, again, funkily).  In short, it would be a mess.  At
least this is how things would happen in my imagination of how your code
works.  Please correct me if I am wrong.

Still, I must say, I have been following your discussion closely, and as
time goes by, I am more and more convinced by Keyur's line of reasoning.

Remember, X was designed and developed in a time when we were dealing with
a (ISO) Latin-only world, with no idea of supporting complex scripts and /
or fonts , where 8-bit char codes most likely meant glyph codes as well, so
the distinction was moot.  At that point in time there was no idea of
supporting complex scripts and issues such as ligatures, conjuncts,
positioning, etc., nor even the idea of true type (not to mention
open-type) fonts and cmap tables.

As we move into the 21st century, it seems very much out of the X frame of
view to have the client worrying about the specific font it will use and
the corresponding mapping table, as well as positioning issues.  To me this
seems clearly within the domain of the X Server, and its rendering engine.
If the X protocol is vague on this issue, it is my opinion that the X
protocol should change, not our approach to this problem.

So this becomes a deeper issue of modifying the X Server to support Unicode
and Open (or True) Type Fonts, which must be going on elsewhere as well.
Anyone know?

For one place, see http://www.io.com/~kazushi/xtt/, a Japanese effort for
making the X Server ttf-friendly, in order to support Japanese on the
server-side...

In a possibly un-desired tone, I venture to say we have lived under the
shadow of a latin-dominated computing world for long enough.  It is time we
make our voice heard, and make sure solutions to support our languages are
not ad hoc, but rather made at the most appropriate level for the overall
architecture...

--Tapan




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com