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

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

On Tue, Feb 19, 2002 at 01:44:57AM -0800, Joseph Koshy wrote:
> 
> as> However, if your point was that the client can't easily map (x[1],
> as> y[1], x[2], y[2]) to a UTF-8 string, I don't think it would be
> as> much harder than the existing algorithms in:
> as> xc/lib/Xaw/AsciiSink.c - FindPosition() 
> as> In a nutshell, the server, which has the knowledge of complex
> as> glyph codes and reordering, responds to client requests for
> as> XQueryTextExtents.
> 
> Well, the Xaw widget set doesn't seem to be using XQueryTextExtents()
> at all.

That is for efficiency reasons. man XTextExtents. XQueryTextExtents
(something more powerful than that) was the proposed new mechanism.

> 
> I'd really like to see this 'not so hard' algorithm whose existence
> you have postulated :).
> 

The existing algorithm in Xaw:

// startx = x[1]
// pixel_width =  x[2] - x[1]
FindPosition(textpos, startx, pixel_width)
	nchars = 0
	curpos = startx 
	while 1:
		// Uses XFontStruct for efficiency
		width = compute the width of the next char in the text buf
		nchars++;
		curpos += width
		if (curpos >= startx + pixel_width)
			break;

	// everything starting from textpos to textpos + nchars is "selected"


The proposed new algorithm:

FindPosition(textpos, startx, pixel_width)
	// Make a single request to the X Server - this doesn't exist in
	// the X protocol yet
	nchars = XComputeWidth(textbuf[textpos:end-of-line], startx, pixel_width,
		               // other args font etc)

	// everything starting from textpos to textpos + nchars is "selected"

The X server would deal with all the context sensitive reordering and joining
and computes nchars. I don't have an algorithm for doing this, but am
postulating that the X server has all the information that it needs to
compute nchars.

> as> I think we should bring this up on the right XFree86 fora and
> as> resolve it there.
> 
> I think that it would be prudent to first understand how the X window
> system actually works.

Is it really that important ? :)

> Especially so, if you are going to claim that
> the X protocol specification is ambiguous/in error, and that the error
> has been undetected for the two decades (or so) that the specification
> has been around :).

I just said it was inconsistent in the use of character codes vs glyph
codes - not that it was ambiguous or in error. This seems to be a
consequence of it being designed at a time, when the distinction between
the two was not as important as it is today.

And you yourself (along with others on this list) accepted that certain
references were ambiguous. What's all the fuss about then ? :)

I think, where we stand today, both the approaches are feasible and we
need to come up with the pros and cons of each approach. I've given
several tangible advantages of implementing it on the X server. Perhaps
you could articulate your thoughts on why you think it should be done in
a client side library ?

	-Arun