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

[Keyur S. <key...@ya...>]

Hi,

--- Joseph Koshy <jk...@Fr...> wrote:
> The distinction between characters and glyphs is
> important even for
> Latin scripts.  Consider ligatures and diacritical marks;
> some Latin
> encodings have separate character codes for the
> diacritical marks; a
> "c" and a "cedilla" (two code points) together can have a
> different
> glyph in these languages.  Similarly "f", "f" and "i"
> combine to form
> a distinct glyph "ffi".
> 
> The X protocol was explicitly designed NOT to support
> these kinds of
> transformations.

True. So now you are agree on the point that under existing
X Protocol requests we can't handle such complexity. Indic
scripts have similar complexity; even more than this.

> One place in the X protocol specification uses the phrase
> 'string of
> characters'.  Now the word 'character' has (today) become
> an
> overloaded phrase, with meanings ranging from the visual
> representation (the letterform), the 'abstract' character
> itself, the
> code point assigned to the character in a given encoding,
> a specific
> glyph in a font, etc.  The exact meaning is usually clear
> from the context.
> 
> Nowhere does the X11 protocol specification say that
> 'character codes'
> are to be used in text drawing requests.  In fact, it
> EXPLICITLY
> states that the semantics of character `codes' are NOT to
> be honored by the X server.

It says that X protocol does no translation of character
sets. It doesn't mean that characters 'codes' are not to be
honored by the X server. X protocol also doesn't EXPLICITLY
says that glyph codes have to be passed in the request.
Everywhere it says about "values" passed in the request. It
was left for implementation to decide what are these
"values". Actually at that time, there was no distinction
between character codes and glyph codes.

> 
> If you change this, you'll end up with some other
> "protocol", not the
> X protocol.  This new graphics "protocol" is however:

I think while talking about X, you are simply ignoring the
fact that X Window system is not merely the X Protocol but
it consists of X Protocol, X library, X server, and font
renderer used by the X server. Since now all the font
renderers used by X Server do have mapping table which maps
from character codes to glyph codes, it is not possible for
an X client to specify particular glyph to be displayed
just by passing glyph codes in XDrawString unless there is
"char codes = glyph codes" in the font. 

Can client use any X TrueType font for Indic with Unicode
encoding and determine which glyph to use for character
"KA"? It is not possible for the client since the font is
loaded by the server and the glyph information is again
kept by the font renderer which is not directly accessible
by the client. The client will simply pass the Unicode
value of the character "KA" in XDrawString16 call and the
font renderer will take care of it. You can try this out by
writing a simple application to draw glyph for character
"KA" from some Unicode encoded Indic font.

So even if X protocol didn't entertain character codes to
be passed in the protocol request, that documented feature
(as you said) doesn't match with current scenario in X
Window system. Does it mean that all X clients are *now*
violating X protocol specification?

> 
> a. inconsistent
>    i. how do you map a screen coordinate back to position
> in the text
>       stream if you are doing complex text rendering?

This is certainly not the job of X server.

> b. incomplete
>    i.  how do you specify text in a different character
> encoding?

OpenType font allows you to design your font in _any_
encoding currently in use. 

>    ii. how do you access glyphs in a font that do not
> correspond to
>        a `character'?

This should be done using some intermediate tables in the
font like GSUB table in OpenType font. Indic scripts have 
many glyphs which don't have any character code value in
Unicode but as you must be knowing these glyphs are getting
displayed in IndiX which use OpenType font.

> 
> c. suffers from new problems
>    i.  If you are indexing fonts using character codes,
> how do you use
>        fonts that do not contain glyphs of 'letters'?
>        You don't want glyph combining and reordering
> happening for
>        the glyphs in a symbol font for example.

Your font must specify some character encoding. There will
be a mapping table from "character code" in this encoding
to "glyph code". Using this mapping table, you can display
all the glyphs from your font.

On the other hand I would like to ask you that how one can
determine glyph id for a character when all the font
information is kept by the server?

> However, you don't need to change the X server to support
> Indic
> scripts.  Here is one way how it would work:
> 
> >> Client side Indic Rendering I
> 
> o this is efficient in terms of network bandwidth (glyph
> indices are sent over)

Not necessary for Indic script. There is one-to-one,
one-to-many, many-to-one, and many-to-many mapping between
character codes and glyph codes. I gave few examples in one
of my earlier mail. It means that 'm' character codes may
be mapped to 'n' glyphs and it is possible that n > m. 

> o it doesn't break anything; you are still using the X11
> protocol :)

This point we'll skip until we decide whether passing
character codes actually breaks the Xprotocol.

I think other points have already been addressed by Arun,
so I will wait for response from you and other people.

Regards,
Keyur


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com