Re: [I18n] Re: [I18n]XIM Protocol Questions: StringConversionCallback
Attached is a proposed patch to fix the XIM protocol in Thai XIM.
It's composed of:
- a patch to use safe values in Thai XIM which should work regardless of
the signness of XIMStringConversionPosition, and in accordance with
the re-interpretation of the protocol,
- a patch to Xlib.h to change typedef of XIMStringConversionPosition
to (signed) short.
I have also prepared another patch for GTK+ imxim, which depends on
whether the latter patch to Xlib.h is applied. I'll post it as a follow-up
to GNOME bug #101814 soon.
-Thep.
On Mon, Feb 17, 2003 at 11:02:45PM +0700, Theppitak Karoonboonyanan wrote:
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.
diff -Nuar xc/lib/X11/imThaiFlt.c xc.thximconv3/lib/X11/imThaiFlt.c
--- xc/lib/X11/imThaiFlt.c 2003-02-20 17:14:49.0 +0700
+++ xc.thximconv3/lib/X11/imThaiFlt.c 2003-02-20 17:20:52.0 +0700
@@ -602,11 +602,11 @@
#define IC_GetContextChar(ic) \
(IC_RealGetPreviousChar(ic,2))
#define IC_DeletePreviousChar(ic) \
- (IC_RealDeletePreviousChar(ic,1))
+ (IC_RealDeletePreviousChar(ic))
Private unsigned char
#if NeedFunctionPrototypes
-IC_RealGetPreviousChar(Xic ic, XIMStringConversionPosition pos)
+IC_RealGetPreviousChar(Xic ic, unsigned short pos)
#else
IC_RealGetPreviousChar(ic, pos)
Xic ic;
@@ -619,10 +619,13 @@
XIMStringConversionCallbackStruct screc;
unsigned char c;
-screc.position = pos;
+/* Use a safe value of position = 0 and stretch the range to desired
+ * place, as XIM protocol is unclear here whether it could be negative
+ */
+screc.position = 0;
screc.direction = XIMBackwardChar;
screc.operation = XIMStringConversionRetrieval;
-screc.factor = 1;
+screc.factor = pos;
screc.text = 0;
(cb-callback)((XIC)ic, cb-client_data, (XPointer)screc);
@@ -651,11 +654,10 @@
Private unsigned char
#if NeedFunctionPrototypes
-IC_RealDeletePreviousChar(Xic ic, XIMStringConversionPosition pos)
+IC_RealDeletePreviousChar(Xic ic)
#else
-IC_RealDeletePreviousChar(ic, pos)
+IC_RealDeletePreviousChar(ic)
Xic ic;
- XIMStringConversionPosition pos;
#endif
{
XICCallback* cb = ic-core.string_conversion_callback;
@@ -664,7 +666,7 @@
XIMStringConversionCallbackStruct screc;
unsigned char c;
-screc.position = pos;
+screc.position = 0;
screc.direction = XIMBackwardChar;
screc.operation = XIMStringConversionSubstitution;
screc.factor = 1;
diff -Nuar xc/lib/X11/Xlib.h xc.thximconv3/lib/X11/Xlib.h
--- xc/lib/X11/Xlib.h 2003-02-20 17:16:07.0 +0700
+++ xc.thximconv3/lib/X11/Xlib.h2003-02-20 17:14:08.0 +0700
@@ -1303,7 +1303,7 @@
} string;
} XIMStringConversionText;
-typedefunsigned short XIMStringConversionPosition;
+typedefshort XIMStringConversionPosition;
typedefunsigned short XIMStringConversionType;
Re: [I18n] Re: [I18n]XIM Protocol Questions: StringConversionCallback
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
Re: [I18n] Re: [I18n]XIM Protocol Questions: StringConversionCallback
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
[I18n] Re: [I18n]XIM Protocol Questions: StringConversionCallback
[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
Re: [I18n]XIM Protocol Questions: StringConversionCallback
On Sat, Dec 28, 2002 at 09:59:39AM -0800, Hideki Hiura wrote: From: Theppitak Karoonboonyanan [EMAIL PROTECTED] * Should the client return the string in reversed order? No. 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. OK. Thank you for the clarification. 2. XIMStringConversionSubstitution * How can the input method know if the client supports only Retrieval, but not Substitution? Some applications, such as terminal emulators, may choose to support only Retrieval, but not Substitution. And the input method should not try to mess up the buffer in that case. Does the protocol define the XIMStringConversionCallbackStruct::text to be set to NULL by the client in that case? Unfortunately, it is not assumed that the XIMStringConversionCallbackStruct::text to be set to NULL. All right. So, I may have to redesign the input method scheme. In fact, we have levels of restrictions in Thai input method, and the Substitution I designed would be optional for each level (as alternative to mere rejections of key events). In the case of terminal emulators you mentioned as an example, there won't be reliable case to support the String Conversion feature by terminal emulator itself, since a terminal emulator does not hanlde the clent buffer itself: it belongs to the apps running in the terminal emmulator. Yes. I realize this. And there's no reliable way further than that to access buffers of the apps on the terminal. So, context-sensitive input method seems impossible for the case. But peeking the terminal emulator's screen buffer read-only does help in filtering out illegal sequences (although it doesn't work well in case the app is running on a remote session through delayed network). If the client supports retrieval via string conversion, it is assumed that the client has direct access the buffer thus it is also assumed to have the operation to substitute. OK. Does this mean we need to have some input method protocol for console-based applications? (quite off-topic, sorry) Thank you, -Thep. -- Theppitak Karoonboonyanan Thai Linux Working Group (TLWG) http://linux.thai.net/thep/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]XIM Protocol Questions: StringConversionCallback
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.
2. XIMStringConversionSubstitution
* How can the input method know if the client supports only Retrieval,
but not Substitution?
Some applications, such as terminal emulators, may choose to support
only Retrieval, but not Substitution. And the input method should not
try to mess up the buffer in that case. Does the protocol define
the XIMStringConversionCallbackStruct::text to be set to NULL by the
client in that case?
Unfortunately, it is not assumed that the
XIMStringConversionCallbackStruct::text to be set to NULL.
In the case of terminal emulators you mentioned as an example, there
won't be reliable case to support the String Conversion feature
by terminal emulator itself, since a terminal emulator does not
hanlde the clent buffer itself: it belongs to the apps running
in the terminal emmulator.
If the client supports retrieval via string conversion, it is assumed
that the client has direct access the buffer thus it is also assumed
to have the operation to substitute.
--
hiura@{freestandards.org,OpenI18N.org,li18nux.org,unicode.org,sun.com}
Chair, OpenI18N/Open Internationalization Initiative, http://www.OpenI18N.org
Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA eFAX: 509-693-8356
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
