On Fri, Jan 24, 2003 at 11:38:30AM +0700, Theppitak Karoonboonyanan wrote: > 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)
Since XIMStringConversionPosition is unsigned, the only way to address backward positions is move in the direction specified. Yeah, but the ending position also has to be indicated by the direction, as stated in the spec. I may miss this point by too much concern that the retrieved string must be in logical order. So, possibilities are: 1) XIMStringConversionPosition should be signed, and the retrieving range is as Owen said 2) XIMStringConversionPosition is still unsigned, and the retrieving range is (caret+position*direction, caret+position*direction+factor*direction) But 2) makes no sense for XIMLineStart, XIMLineEnd, for example. Therefore, may I conclude that typedef-ing XIMStringConversionPosition as unsigned short is a bug? -Thep. > > > > 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 > > > _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
