Re: [Indic-computing-devel] ComputeWidth

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

On Fri, Feb 22, 2002 at 01:25:58PM +0530, Tapan S. Parikh wrote:
> 
> It still seems to me mistakes can be made...
> 
> Take an example text = (a b c d e) [char codes]
> 
> But after reordering = (f-a, f-b, f-c, f-e, f-d) [glyph codes]
> 
> Then if ComputeWidth returns 4, wouldnt the client improperly assume char
> codes (a, b, c, d) were selected, and not the correct (a, b, c, f)?

Usually, a text widget's (such as gtktext) idea of a selection is
offsets into the character buffer (not the glyph string buffer). So I'm
not sure what it means to say that (a b c f) is selected.

A request such as XComputeWidth could send the string "abcde" over the
network in a single request. The X server could compute the glyph
string, compute the widths and compute the number of syllables selected
(using the IndiX algorithm). Further, it could convert the number of
syllables to the number of characters and send it back to the client.

As a result, (a b) may be selected or (a b c d) may be selected, but not
(a b c) assuming that (c d) is a syllable.

> If this is indeed a prb, It seems one way to handle this would be to use an
> algorithm like Keyurs on the client to make sure only full syllables are
> highlighted...

Sure, it could be done on the client (as it is done in IndiX) - but the
number of round trips to the server to compute the width of each syllable
could be large, depending on the size of the selection.

Reading XFree86 lists, people wanting to optimize X performance are
often told that 

	- Text requests are not a problem
	- Optimize round trip latencies
	- Optimize image performance

At this point, XComputeWidth is purely a latency reducing, bandwidth
conserving optimization.  XQueryTextExtents provides all the necessary
functionality needed for correctness.

	-Arun