MacOSX VM has some problems with m17n

Tetsuya HAYASHI tetha at st.rim.or.jp
Wed Oct 29 11:12:44 UTC 2003


Hello, JMM. and MacOS VM staff.

When I use Squeak for MacOS X with "m17n" package, I found some 
problems.
There are two problems, one is about handling filename, another is about
handling InputMethod(=IM). I traced that these causes was in VM.
I've tried to solve these problems and made VM patches.
Now, I send two patch files attached to this mail.
I hope your opinion, because I couldn't solve it completely.


[First: for sqMacFileLogic.c]
I found a problem about handling filenames encoded in Japanese
character code (= Kanji, this is two byte code). It is caused by using
a const value ("kCFStringEncodingMacRoman") with calling MacOS APIs in
"sqMacFileLogic.c" module. It crash a two byte character sequence.

I guess that there are two solutions.
A) One is using an *API function* instead of the const value.
B) Another is using *other const value* such like
"kCFStringEncodingUTF8".

Now, I don't know which is better solution, but it is clear that
"kCFStringEncodingMacRoman" is not good for Multilingualization.

So, I tried above "A)" idea and attach this patch as a diff file
(sqMacFileLogic.c.diff).
I use an API function named "CFStringGetSystemEncoding()" instead of
the const value. This function return a suitable encoding value
dynamically according to user's Language Environment of MacOS X, for
example, in Japanese environment, return
"kCFStringEncodingMacJapanese", and with this value, file APIs can
handle two byte characters correctly.
It works well, for me and japanese.
But, I'm afraid some problems would be occurred in another Language
environments.
And, I suspect that the idea "B)" should be better solution.
I hope your opinion.

[Second: for sqMacUIEvents.c]
This is a trial patch. It needs "m17n" package in VI. Its reason is
described later.

Usually, japanese people use IM for typing Kanji characters.
IM sends some characters in *Unicode* to application (=VM) as *one
key-in event of TSM*, after editing a Kanji character sequence. It
seems that IM has two key-in phase.

But, "sqMacUIEvents.c" exactly... a function named
"recordKeyboardEventCarbon()" send only one character and ignore two
or more characters. (in this function, check byte size of characters
from TSM, such as 'actualSize != 2' at line 1727.  Actually, IM (or
TSM) sends some characters and byte size would be more two, so this
check will destroy a Kanji character sequence).

I changed logic as follows in patch (sqMacUIEvents.c.diff).
1) make a buffer for characters from IM
2) loop buffer size and send contents of this buffer to VI

This patch enable to input kanji characters using IM, and may also
other languages using IM (Hangul, Chinese, ... I haven't tested).
However, there is an issue that is usage of Unicode, not MacRoman.
This is a serious dilemma :(
The "m17n" package can handle Unicode key-in event, but without this
package, VI will occur an error.

I hope that someone would try to solve this problem and fix it in
smart way.
... of course, I also continue to do.


In addition,
I've heard that by MS-Windows, such like problems has not occurred ...
I can't believe it :-P

--
Tetsuya HAYASHI <tetha at st.rim.or.jp>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sqMacFileLogic.c.diff.gz
Type: application/x-gzip
Size: 1240 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20031029/67e20593/sqMacFileLogic.c.diff.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sqMacUIEvents.c.diff.gz
Type: application/x-gzip
Size: 1668 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20031029/67e20593/sqMacUIEvents.c.diff.bin
-------------- next part --------------





More information about the Squeak-dev mailing list