FS#2484 - [OSX] Cannot enter CJK characters

Attached to Project: OpenTTD
Opened by CHEN,Bill (darks) - Wednesday, 31 December 2008, 03:06 GMT
Last edited by Michael Lutz (michi_cc) - Monday, 05 August 2013, 20:44 GMT
Type Bug
Category Interface
Status Closed
Assigned To No-one
Operating System Mac OS X
Severity Medium
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Only CJK characters cannot be typed in openTTD, but many other unicode languages may not have this problem.

Take general typing Simplified Chinese Pinyin for example.
1st, type the pinyin,using all latin words to show the Chinese pronunciation.
2nd,choose the right characters for the pinyin just typed.
3rd,confirm the characters just chosen and finish the CJK typing.

In openTTD, all typing boxes (including but not limited: edit the company name, the groups' name, the player's name) cannot let the player to choose the right characters, but is able to type the Unicode languages.
##I've tried Thai, no problem, but only shows the blocks. it's the config of fonts easy to solve.

So, I have a plan to solve this CJK typing problem by adding a new dialog box for CJK. But I'm sorry that I don't know how to program and fix it.

the details about the dialog box to type CJK
1st, if the players using the CJK IM to type CJK, then the dialog box active.
2nd, let the player type CJK characters just like the above general typing in this dialog box.
3rd, press ENTER to let the characters input to the typing boxes,just like edit the company name and so on.


PS. My English is not good. If there's any questions about above, contract me. MSN: chen-bill-bill<AT>
This task depends upon

This task blocks these from closing
 FS#2782 - [OSX] Port hopelessly outdated 
Closed by  Michael Lutz (michi_cc)
Monday, 05 August 2013, 20:44 GMT
Reason for closing:  Implemented
Additional comments about closing:  More or less in r25686 - r25693.
Comment by CHEN,Bill (darks) - Wednesday, 31 December 2008, 07:35 GMT
With friends' help, it seems just a bug? Seems in XP, there's all right.

But I've tested, in mac OSX, it exits.
Comment by Remko Bijker (Rubidium) - Wednesday, 01 April 2009, 10:19 GMT
  • Field changed: Type (Feature Request → Bug)
  • Field changed: Summary (Type CJK characters in openTTD → [OSX] Cannot enter CJK characters)
  • Field changed: Operating System (All → Mac OS X)
In the linux builds you can enter CJK characters via e.g. xcin. As said before it also works in Windows.
Comment by Remko Bijker (Rubidium) - Sunday, 03 January 2010, 17:40 GMT
  • Field changed: Status (New → Not confirmed)
Unconfirmed only because there's no developer that can confirm it. Given the amount of information given it seems to be a valid bug report though.
Comment by Brad Oliver (hoserama99) - Monday, 18 January 2010, 21:10 GMT
I'm afraid I don't know how to reproduce this as I'm unfamiliar with how to enter CJK characters on the Mac. If someone can post step-by-step instructions, I can take a swing at it.
Comment by Si (si) - Thursday, 21 January 2010, 20:49 GMT
To enter CJK characters on the Mac:

1. Turn on a Chinese/Japanese/Korean input method in System Preferences --> Languages and Text --> Input Sources (OS X 10.6).
2. In the screenshot, I've turned on Pinyin – Simplified Chinese.
3. Then, as you start typing the Pinyin romanization, it'd come up with a dialogue to choose different words: e.g. 你好吗 (How are you). Pressing space bar should then turn the romanization into characters.

It is not possible to type such characters in the Mac version. In fact I'm not sure if it is possible to do some unicode characters on the Mac version either, e.g. I can't get accented words e.g. type "déjà vu" into OpenTTD.
Comment by Si (si) - Thursday, 21 January 2010, 20:57 GMT
As this second screenshot shows it is simply not possible to enter CJK characters onto OpenTTD because the dialogue box for choosing words won't show up.

I don't have OpenTTD on Windows/Linux so I don't know how this compares to the situation on those platforms.
Comment by Brad Oliver (hoserama99) - Thursday, 21 January 2010, 21:04 GMT
Ah, I understand now. I'll take a look.
Comment by Brad Oliver (hoserama99) - Friday, 22 January 2010, 01:03 GMT
For those in the know, does the Win32 port work correctly when using a Pinyin IME? If so, can someone post a screenshot and/or directions so I can check it out in Windows here?

Running some tests here on my Mac, the game accepts and uses Unicode characters when typed directly. For example, if I switch to a German keyboard layout and hit the key right of "p", I get a nice ü as I should. The Mac port does ignore dead keys so you can't do a Opt-U then U on the US layout to get a ü, but I don't see that as a huge issue.

Dumping in a pre-formed string of pinyin characters from the Mac IME is problematic, though, and in looking at the source I don't see that the other platforms are dealing with this either.
Comment by Ingo von Borstel (planetmaker) - Friday, 22 January 2010, 09:28 GMT
Well. Ideally you'd get exactly those characters which the key displays and which it generates by default, given your localization - without the need for detours. That's what a standard users expects to happen.
Comment by Brad Oliver (hoserama99) - Friday, 22 January 2010, 16:09 GMT
Then it sounds like the Mac port is behaving as the other platforms. When I switch keyboard localizations, single keypresses generate the proper Unicode characters.
Comment by Remko Bijker (Rubidium) - Saturday, 23 January 2010, 18:40 GMT
As the bug reporter already said: it works on Windows.
As the attached image shows: it works on Linux (minus me missing some font).
As the bug reporter already said: it does not work on Mac OS X.

The only conclusion I can make is that the Mac OS X port does not behave like the other platforms.
   fcitx.png (80.2 KiB)
Comment by Ingo von Borstel (planetmaker) - Saturday, 23 January 2010, 22:25 GMT
Mac is not behaving as other platforms here. Even if I switch to Chinese localization and to Chinese within OpenTTD, I still cannot enter Chinese characters as the latin-to-chinese replacement & selection window is not present (e.g. when typing the text of a new sign on the map).
Comment by Brad Oliver (hoserama99) - Saturday, 23 January 2010, 22:58 GMT
I ran the app on Windows to see where the divergence happens. On Win32, the IME input window is provided by the OS and blasts a series of WM_ key events to the game once you "commit" the Chinese string, from what I can tell. That's different from OS X, where we must signal entry and exit from the IME within the app, deal with rendering the uncommitted text, and then take the committed string and send each character to the game in discrete events in the Cocoa backend.

Let me think about this. Maybe there's a clever hack to force OS X to at least draw the IME in an invisible overlay window which would remove a lot of the burden. I assume there's no special IME handling going on in the SDL backend on Linux, it's all done externally in xcin? Does xcin position the IME window relative to the mouse cursor or am I way off?
Comment by Ingo von Borstel (planetmaker) - Friday, 08 October 2010, 15:20 GMT
Actually... the selection window opens and adopts according to the input. Just the talkback from there to OpenTTD does not work. Thus most is indeed already there...
Comment by Zydeco (Zydeco) - Thursday, 24 February 2011, 19:29 GMT
This patch will allow CJK input on Mac OS X 10.4 or later.
On 10.6 it uses the new API, where the input window will appear under the focused field, on 10.4 and 10.5 it just shows a global input window at the bottom of the screen, see the attached screenshots.
It doesn't work properly with the quickdraw backend, so compile with --disable-cocoa-quickdraw.
I've tested it on 10.4 (ppc and i386), 10.5 (i386) and 10.6 (i386 and x86_64), and it seems to work, but I've probably left something out.
I've uploaded a universal debug build of 1.1.0-RC1 with the patch, you can get it at
Comment by Michael Lutz (michi_cc) - Thursday, 24 February 2011, 22:21 GMT
I noticed quite a lot of #if !__LP64__ in the code. Is all that code really
not needed on 64-bit platforms or would there be some limitations for code
compiled as 64 bit?

I have to admit that I'm no OSX programmer, but when I had a brief look
at the topic before, for me the documentation seemed to point at NSTextInput,
which OpenTTD would have to implement, to support all text input features
including marking of still unconverted char sequences and more.
Comment by Zydeco (Zydeco) - Thursday, 24 February 2011, 23:36 GMT
The code in #if !__LP64__ guards calls functions that do not exist in the 64-bit API, it is there to support Mac OS X 10.4 and 10.5, which use Carbon Text Services Manager.
For 10.6, the Cocoa text input system is used, but the code is conditinally compiled checking for both 10.6 and 64-bit, so that a 32-bit binary compiled on 10.6 will use the Carbon Text Services when running on 10.4 or 10.5, and the cocoa text input system on 10.6.
The main difference between both is that in the cocoa version, the input panel is a normal window, which can be placed under the current focused field by OpenTTD.

I realized this won't work on 64-bit on 10.5 so I'm attaching an updated patch that adds code in IMEController for that (at the end of -interpretKeyEvent:string:) to default to the older input handling that supports combining characters but not other input methods, but since this isn't a good option, maybe it's better to change the Info.plist to ensure the 64-bit version is only used on 10.6 or later, I'm attaching a patch to for this.
Comment by Remko Bijker (Rubidium) - Sunday, 27 February 2011, 08:52 GMT
About the plistgen diff: the PPC builds are supposed to work on 10.3.9 as well.

To what extent are the new files really from Apple? Especially as applying that patch, making an OSX binary and then distributing that seems to be violating the license of those files.
Comment by Zydeco (Zydeco) - Sunday, 27 February 2011, 09:33 GMT Comment by Remko Bijker (Rubidium) - Sunday, 27 February 2011, 10:06 GMT
I guess I wasn't clear enough.

The license states: "Redistributions in binary form must reproduce the above copyright notice [...] in the documentation [...]". To me that reads like adding "Copyright (C) 2009 Apple Inc. All Rights Reserved." to readme.txt. That in its turn would be extremely misleading as maybe a hundred lines of source code (less than 0.05%) is Apple's, and even only when it is an OS X binary.

In any case, the patch doesn't make sure part 2 of the license is fulfilled and that's my main concern. Preferably some automatic way of packaging the licensing stuff with the documentation, but only for Mac OS X, is needed.
Comment by Ingo von Borstel (planetmaker) - Wednesday, 02 March 2011, 13:21 GMT
Possibly a solution like mozilla uses with its licenses / credits can be found ( about:license when FF is open). It's of the form

Apple/Mozilla NPRuntime License

This license applies to the file modules/plugin/base/public/npruntime.h. (This code only ships in the Mac OS X version of this product.)

Copyright © 2004, Apple Computer, Inc. and The Mozilla Foundation.
All rights reserved.

bla bla...

A bit besides this point, they also add in their credits
Optional Notices

Some permissive software licenses request but do not require an acknowledgement of the use of their software. We are very grateful to the following people and projects for their contributions to this product:

* The zlib compression library (Jean-loup Gailly, Mark Adler and team)
* The bzip2 compression library (Julian Seward)
* The libpng graphics library (Glenn Randers-Pehrson and team)
* The sqlite database engine (D. Richard Hipp and team)
* The Nullsoft Scriptable Install System