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

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

Joseph Koshy wrote:

>
>If the X server is doing arbitrary glyph reordering and glyph
>substitution unknown to the X client, then this translation will go
>wrong in the client.
>
Possible. The proposal over here:

http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/

may be relevant. It is basically saying that the X selections should be 
UTF8_STRINGs and not glyph codes (which may be different between 
different fonts).

However, if your point was that the client can't easily map (x[1], y[1], 
x[2], y[2]) to a UTF-8 string,  I don't think it would be much harder 
than the existing algorithms in:

xc/lib/Xaw/AsciiSink.c - FindPosition()

In a nutshell, the server, which has the knowledge of complex glyph 
codes and reordering, responds to client requests for XQueryTextExtents. 
I do see the problem of  increased network traffic - but I see it as 
unavoidable. If we have to do the same thing on the client side, we'll 
have to communicate the information in the open type cmap tables over 
the X protocol to the client.

>
>I don't think the requirement of X applications running unchanged with
>Indic scripts is a feasible one.
>
I'd qualify that with "as things stand today". However, if Xlib is made 
fully Unicode or UTF-8 capable, I believe (based on my limited 
understanding of X) that we could make it work, with server side 
modifications only.

Another observation: X doesn't seem to be consistent on where the 
character -> glyph mapping should be done. While many sources hint that 
the codes in the requests (for eg: PolyText, RENDER extension etc) 
should be glyph codes, there are others who indicate that the values 
stored in XSelections should be UTF-8. In one case the X server doesn't 
know about the character codes, in the other it does. This is true of 
the X protocol also - some bits on the wire indicate glyph codes 
(PolyText16) and some (UTF8_STRING) indicate character codes.

Does anyone know how the Indic support on MS windows works with network 
transparent protocols like Citrix ? Their marketing literature (talk 
about thin clients) seems to hint at pushing the complexity to the 
windows terminal server side (Windows Terminal Server = analogous X 
client). In that respect, it makes sense to push the complexity to the X 
client, because, the X server could be a very low powered hand held, not 
capable of dealing with the complexity. This is the only argument I can 
find in favour of doing reordering etc on the X client side.

I think we should bring this up on the right XFree86 fora and resolve it 
there.

    -Arun