On Fri, Jan 31, 2003 at 11:43:21PM +0700, Theppitak Karoonboonyanan wrote: > 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.
Since the release date of XFree86 4.3.0 is very close, I think this issue needs clarification, rather than leaving it partially done. If there is no objection, I will patch Xlib.h so XIMStringConversionPosition becomes (signed) short. However, another question is raised: How is the backward range boundary counted? For example: given a text buffer ABC|DE [012|34] <-- index where '|' means caret position (currently 3), if I want to retrieve "BC", how should I pass the parameter? a) position = 0, factor = 2, dir = BackwardChar b) position = -1, factor = 2, dir = BackwardChar For a): because saying "starting position = 0" means absolute index 3, counting backward by factor 2 we get (3,1), sorting the range we get (1,3), and "BC" is got. For b): "starting position = -1" means absolute index 2, counting backward by factor 2 we get (2,0), and "CB" is got in that direction, meaning "BC" in logical order. Thanks, -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
