darks wrote:

With friends' help, it seems just a bug? Seems in XP, there's all right.

But I've tested, in mac OSX, it exits.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment5172

Rubidium wrote:

In the linux builds you can enter CJK characters via e.g. xcin. As said before it also works in Windows.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment5876

Rubidium wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7226

hoserama99 wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7392

si wrote:

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.

Attachments

• Screen shot 2010-01-21 at 20.47.12.png (457.30 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7412

si wrote:

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.

Attachments

• Screen shot 2010-01-21 at 20.53.50.png (1754.23 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7413

hoserama99 wrote:

Ah, I understand now. I'll take a look.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7414

hoserama99 wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7415

planetmaker wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7416

hoserama99 wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7421

Rubidium wrote:

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.

Attachments

• fcitx.png (80.18 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7437

planetmaker wrote:

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).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7440

hoserama99 wrote:

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?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment7442

planetmaker wrote:

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...

Attachments

• Bildschirmfoto 2010-10-08 um 17.15.58.png (232.17 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment8888

Zydeco wrote:

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 http://www.mediafire.com/file/etow00r840qrodc/openttd-1.1.0-RC1-universal+CJK.zip

Attachments

• mac_os_x_cjk.patch (16.03 KiB)
• cjk-10.4.png (784.03 KiB)
• cjk-10.6-chat.PNG (184.59 KiB)
• cjk-10.6-field.PNG (34.76 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment9724

michi_cc wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment9725

Zydeco wrote:

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 plistgen.sh for this.

Attachments

• plistgen-64-10.6.patch (0.66 KiB)
• mac_os_x_cjk.patch (16.36 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment9726

Rubidium wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment9735

Zydeco wrote:

The original files are from WebKit, they just support Mac OS X 10.6
http://svn.webkit.org/repository/webkit/trunk/Source/WebKit/mac/Plugins/Hosted/WebTextInputWindowController.h
http://svn.webkit.org/repository/webkit/trunk/Source/WebKit/mac/Plugins/Hosted/WebTextInputWindowController.m
They are also present in mozilla and chrome, differently modified:
http://src.chromium.org/svn/trunk/src/third_party/mozilla/ComplexTextInputPanel.h
http://src.chromium.org/svn/trunk/src/third_party/mozilla/ComplexTextInputPanel.mm
That license is the FreeBSD license, so it's GPL-compatible

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment9736

Rubidium wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment9737

planetmaker wrote:

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

"

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484#comment9744

michi_cc closed the ticket.

Reason for closing: Implemented

More or less in r25686 - r25693.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2484