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

[<jk...@Fr...>]

ks> It says that X protocol does no translation of character
ks> sets. It doesn't mean that characters 'codes' are not to be
ks> honored by the X server. X protocol also doesn't EXPLICITLY
ks> says that glyph codes have to be passed in the request.

The protocol says very clearly that fonts in X are collections of
glyph bitmaps indexed by a glyph index.  It states that the values
used in text drawing requests are indices into the font.

It also states very clearly that 'character codes' (i.e code points of
any character set) are not used in the protocol.

It states very clearly how the drawing requests are to place the
bitmaps of the specified glyphs next to each other (i.e, it disallows
reordering or substitution of glyphs).

X clients rely on the X server placing the exact glyphs specified, at
the exact pixel coordinates specified by them, when implementing user
interfaces.

There is a whole sub-standard (the X Logical Font Description) that is
used by clients to select fonts with desired font encodings so that
everything 'just works'.

This is one of the cornerstones of X's design.

ks> Everywhere it says about "values" passed in the request. It
ks> was left for implementation to decide what are these
ks> "values". 

You are implying ambiguity in the specification where none exists.

If you had a question about this, you could have asked on the XFree86
lists.

I wonder what you are hoping to achieve by arguing about the X
protocol on /this/ list:

- If there was really a doubt, you could have asked for clarification
  from the rest of the X community; I see no mail from you on this
  topic in the XFree86 archives.

- You haven't run the test suite.

- A cursory search in the XFree86 archives for ``glyph indices'' or
  other keywords would have revealed enough.

The initial review of IndiX had been posted on <indic-computing-devel>
to make public the rationale for why it wouldn't be bundled in the
'Bootable OS' sub-project.

As and when IndiX gets re-designed to be protocol compliant, we'll be
happy to look at it again.

Regards,
Koshy
<jk...@fr...>