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

[Arun S. <ar...@sh...>]

On Thu, Feb 21, 2002 at 09:46:55AM -0800, Keyur Shroff wrote:
> 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. 

The man page for XDrawString maintains the ambiguity about what the
arguments represent - character or glyph codes. So it's possible to call
XDrawString with glyph codes, which get transmitted via PolyText*
requests and assuming the X server can look up the glyph by glyph code
and render the font.

In general, I don't have any doubts that both implementations are
_possible_. It's just a matter of which one has more desirable properties.

In the following stack:

Application -> Toolkit (eg: Qt) -> Xlib -> X protocol -> X server -> renderer

we certainly know that the input to the Toolkit is character code. But
beyond that,  implementations could do what they want.

> 
> 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.

A client side implementation will have to enhance the X protocol to
transmit the cmap tables to the client. Also, there is talk of using
"local client side fonts" and transmitting glyphs to the server on the
XFree86-render mailing lists. In this implementation, fonts are
accessible to the client, but not th server.

More on this below.


> 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.

Few clients will call XDrawString directly. They may call

gtk_label_new("KA")

and then a library like pango can take over, convert "KA" to a glyph
string and then call XDrawString with the glyph string.

http://cvs.gnome.org/lxr/source/pango/pango/pango-layout.c
http://cvs.gnome.org/lxr/source/pango/libpango/glyphstring.c
http://cvs.gnome.org/lxr/source/gtk+/gtk/gtklabel.c

Based on my web searches, other reasons why people might have gyrated
towards client side solutions:

- Project management issues, licensing issues (My
  conclusions/speculation)

  People working on gnome or KDE might find it easier to get their code
  into their own repositories than the XFree86 one.

  People wanting to keep their code under GPL and not the MIT/X style
  licenses.

- "Glacial" speed of X server development

http://www.xfree86.org/~keithp/talks/xtc2001/paper/
http://www.xfree86.org/pipermail/render/2001-August/001291.html

I'd also like to write up a proposal for a binary distribution strategy
for IndiX. It's my belief that we'll end up with both client side and
server side solutions, which could possibly be installed on the same
machine side-by-side. Fortunately, the apps don't get affected and may 
even dynamically choose one using LD_PRELOAD.

	-Arun