On Wed, Jan 22, 2003 at 07:03:43PM -0500, Owen Taylor wrote: > [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.
Just like to note that I couldn't read like this because XIMStringConversionPosition is typedef'd in <X11/Xlib.h> as unsigned short. -Thep. > * 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 > -- Theppitak Karoonboonyanan Thai Linux Working Group (TLWG) http://linux.thai.net/thep/ _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
