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.
XIMStringConversionPosition is defined in the XIM spec document as unsigned also (CARD16). I'm trying to decide whether to include your patch to change it to signed in 4.3. Does anyone know if there is a good reason why it was made unsigned in the spec document, or was that a mistake? Is there any existing code that will break if it's made signed and "negative" values start being used? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
