[EMAIL PROTECTED] (Hideki Hiura) writes:
> > From: Theppitak Karoonboonyanan <[EMAIL PROTECTED]>
> > * Should the client return the string in reversed order?
>
> No.
>
> > The cause of my doubt is that the X11R6.4 "Xlib C Language X Interface"
> > section 13.5.7.3 "Input Method Semantics - String Conversion Callback"
> > describes the text retrieval portion in terms of "starting position"
> > and "ending position", which could also imply the order of the retrieved
> > characters in the returning buffer to be reversed in cases of backward
> > retrievals.
>
> Sorry for the confusion due to the vague definition. I do not have any
> implication on the order of the string to be reversed in the case of
> backward retrieval when I wrote the specification.
> The order of the string retrieved should always be in the logical
> order in the client buffer.
Hmmm, I think some more clarification is needed here.
I just got around to reviewing Theppitak's patch for GTK+
and it doesn't really seem to agree with how I read the spec.
The region to retrieve is defined in terms of three quantities:
XIMStringConverisonPosition position;
XIMCaretDirection direction;
short factor;
The Xlib spec says:
XIMStringConversionPosition specifies the starting position
to be returned in the XIMStringConversionText structure. The
value identifies a position, in units of characters, relative
to the client's cursor position in the client's buffer.
The ending position of the text buffer is determined by
the direction and factor members. Specifically, it is the
character position relative to the starting point as defined
by XIMCaretDirection. The factor member of
XIMStringConversionCallbackStruct specifies the number of
XIMCaretDirection positions to be applied. For example
if the direction specifies XIMLineEnd and the factor is 1,
then all characters from the starting position to the end
of the current display line are returned. If the direction
specifies XIMForwardChar or XIMBackwardChar, then the
factor specifies a relative position, indicated in characters,
from the starting position.
So, the way I read this, is that the string to be returned
is defined by the algorithm:
* Start at the caret position
* Move abs(position) characters backwards or forwards. A negative
value of position means move backwards, a positive value,
move forwards.
* This defines one end of the string.
* Then move 'factor' positions, with the type of position
to move defined by 'direction'. 'factor' will always be a
positive quantity.
* This defines the other end of the string.
Theppitak's current patch only implements XIMForwardChar and
XIMBackwardChar and implements them differently. Instead
of retrieving the range:
(caret+position, caret+position+factor*direction)
It retrieves the range:
(caret+position*direction, caret+position*direction+factor)
Thanks,
Owen
(The spec is also missing information about what members
of the XIMCaretDirection enumeration are allowed in this
place; it doesn't matter much for GTK+ which can really only do
XIM[Forward/Backward]Char XIM[Forward/Backward]Word anyways,
but I assume XIMAbsolutePosition/XIMDontChange are not allowed
at all.)
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
