<div dir="ltr">Hi ,<div><br></div><div>Since you mentioned that Writer exhibit the problem but Calc doesn't,you</div><div>might want to take a look at <span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">sw/source/core/doc/extinput.cxx.</span></div><div><br></div><div>If you're looking for IME code from vcl, I suggest that you grep InputContext as a keyword.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-07 5:51 GMT+08:00 Richard Wordingham <span dir="ltr"><<a href="mailto:richard.wordingham@ntlworld.com" target="_blank">richard.wordingham@ntlworld.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sunday I raised bug report 94753 about the apparent generation of<br>
lone surrogates in response to the use of Keyman for Linux under ibus<br>
as the input method editor. I have compiled Version 4.4.4.3.0+ with<br>
debug to facilitate my investigation; I think my compiler (gcc Version<br>
4.6.3) is too old to compile Version 5.0, which is where I noticed the<br>
problem.<br>
<br>
I use emacs as an IDE for debugging, but Emacs Version 24 does not seem<br>
able to cope with Version 4.4.4.3.0+.  The debugger gdb run from the<br>
terminal appears to be able to cope.  I have been trying to narrow down<br>
the source of the error by inserting fprintf() calls.  However, I cannot<br>
find where characters enter the program from the IME.  I am running<br>
Ubuntu 12.04 with the default desktop.  The IME is KMfL running under<br>
ibus.<br>
<br>
I set up fprintf() and abort() calls to monitor the apparent sole call<br>
of XmbLookupString (there are no visible calls of XwcLookupString) and<br>
also within the call of SalKDEDisplay::checkdirectInputEvent().<br>
However, inputting text from the Supplementary Multilingual Plane using<br>
the IME to input characters generates neither output from the fprintf()<br>
calls nor a core dump from abort().  Have I overlooked another route by<br>
which characters are reaching the program?<br>
<br>
My current suspicion is that Qt is not handling KMfL's replacement of<br>
one supplementary character by another properly, but I cannot<br>
demonstrate that.  My test input text sequence is the three characters<br>
dYH, which when applied to an instrumented program using X generates<br>
the characters U+1148F, U+114C0, U+0008 (also as symbol), U+114BF.  I<br>
suspect that U+0008 is only cancelling the low surrogate of U+114C0,<br>
and that this is happening in Qt code. I have seen similar behaviour<br>
with Konsole, which I believe is a Qt application.  Claws mail,<br>
Gnome-terminal, Emacs Version 24, gedit, Abiword and even LibreOffice<br>
Calc all exhibit receipt of the correct sequence of characters, namely<br>
<U+1148F, U+114BF>.  (Some of these do not display it properly, but<br>
that is another issue.)<br>
<br>
Richard.<br>
_______________________________________________<br>
LibreOffice mailing list<br>
<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Mark Hung<br></div></div></div>
</div>