CJK characters are not appearing at all

• Feb 1, 2018 - 22:42
Reported version
3.0-dev
Priority
P2 - Medium
Type
Functional
Severity
S4 - Minor
Status
fixed
Regression
No
Workaround
No
Project
Priority (old)
normal
Status (old)
active
Component (old)
Code
Category (old)
bug report

Inputting CJK characters are not working at all.
I’ve been testing master nightly build for quite a long time,
Never been working.

Thank you!


Comments

kazuma yamamoto's report is on Mac environment, so I tested on Windows.

Rev: MuseScoreNightly-2018-03-28-0907-master-49068cc
OS: Windows10(64bit)
IM: Google Japanese IM

Although it is not very good, I could enter CJK characters via IM.
It seems it is degrade to the states before ericfontainejazz's fix.
https://musescore.org/en/node/43681#comment-662596

Problem 1:
The positioning of the input method frame.

Problem 2:
Special key sequence for IM, 'Ctrl-', 'F7', 'F8', 'F9' and so on is stolen by MuseScore.
https://musescore.org/en/node/43681#comment-663911

In reply to by werner

I tested on Windows with the latest nightly version.

Rev: MuseScoreNightly-2018-06-20-0941-master-dff4fcc
OS: Windows10(64bit)
IM: Google Japanese IM
Preference -> General -> Language -> "システム言語" (System Language(ja_JP))

Serious problem:
MuseScore crashed when I pressed special key sequence for Japanese IM.

example of key sequence for crash reproduction:

double clicking at title on score sheet
Japanese IM On
key press: a
key press: ctrl-i (Crash at this time)

ctrl-i is used to convert inputting characters to full-width katakana.

Similarly, these keys pressing also crashed.

ctrl-u (convert to full-width hiragana)
ctrl-o (convert to half-width katakana)
ctrl-p (convert to full-width alphabet)

The above key sequences are reproducible procedures, but it seems that there are other cases of crashing during key inputting via IM.

I encountered a crash several times while using IM on/off, F6, F7, F8, and F9 key.

OK, here is the another situation from Windows user.
He tested Japanese inputting on Windows 8.1.
and he even can't input any Japanese, then crash.

Using inputting method of Microsoft IME and ATOK 2015

In reply to by kazuma yamamoto

Improved, but CJK characters are still not working well when I type lyrics or texts on Mac.

OS: macOS High Sierra (10.13)
Arch.: x86_64, MuseScore version (64-bit): 3.0.0.19499
revision: 0526317

CJK Characters are not shown till pressing ENTER.
These should appear immediately after typing letters as like MuseScore ver 2.3.2.
Attached two file, how behaving in ver3 beta and ver2.3.2

MS3_CJK.gif

MS2_CJK.gif

Attachment Size
MS3_CJK.gif 114.14 KB
MS2_CJK.gif 642 KB
Priority P2 - Medium
Regression No
Workaround No

So, it works, but appearance of the symbols is different, isn't it?

In reply to by Anatoly-os

> So, it works, but appearance of the symbols is different, isn't it?

No. Although he(kazuma yamamoto) answered "yes", I think he made a misunderstanding your(Anatoly-os) reply.

The displayed symbol itself is correct as he expects, not different.
I think that he reported a problem about "behavior" not "appearance" of text during key inputting via IM.
That situation is "it works, but not very fine."

That situation is very similar to this:
https://musescore.org/en/node/43681#comment-220561

kazuma yamamoto's report is a Mac version behavior, but it is very similar to the past Windows version states.

Problem 1:
Inputting text via IM is not displayed(not appeared) until press [Enter] key or [→] key.

Problem 2:
The conversion candidate selection window of IM is not appear.

At later, I will also test on Windows version, and try to report that state.

(Edited: to the correct URL.)

In reply to by NOIKE

I tested this issue by "for Windows Version".

OS: Windows 10 (10.0),
Arch.: x86_64,
MuseScore version (64-bit): 3.0.0.4133,
revision: 0526317
IM: Google Japanese Input

> Problem 1:
> Inputting text via IM is not displayed(not appeared) until press [Enter] key or [→] key.

It occurred.

> Problem 2:
> The conversion candidate selection window of IM is not appear.

It was displayed, but it was displayed at a different position from the expected position.
I think improvement is necessary.
It is better to locate that window near the text cursor, same as in the version 2.3.2.

Ver. 3.0 BETA (3.0.0.4133)
V3_for_Win_4.png

Ver. 2.3.2
V2_for_Win.png

ok, so I've installed the chinese input method, and see that I can input chinese text, but as the previous comment of this thread illustrates, the input method window does not appear directly under the cursor (as I recall that problem before) and the inputted roman alphabet characters user inputs don't appear at all while typing...only appear once press spacebar (causing the input method to complete the conversion), and then see the resulting chinese text in musescore.

I think having the IME appear directly below cursor is more important than having intermediate latin appear, so I will focus on that first...

I've also just built 3.0 master on Arch Linux Mate with IBus input method, and found a similar problem with position of the input method popup window. While in windows the popup was below the score view, however in linux the popup appears somewhat in a random position on the scoreview. I can drag the input window around, however when i type a new letter on keyboard, the input window jumps back to its original random position.

So there is probably something in the Qt wrapper to dictate exactly where whatever OS input method popup appears.

Hello ericfontainejazz

Thank you very much for solving the problem of CJK input !
Even though I don't have any programming knowledge, I can imagine it takes you a lot of works.
I'm so much appreciate.

One thing it's differ from Windows situation.
On macOS (10.13 High Sierra),
The input method window (The conversion candidate selection window) does NOT appear at all.

doing debugging, added some qDebug messages for all the QInputMethod signals, and found that the Qt is getting notified when the text position is moved around, but the area rectangles (for inputMethodCursor, inputMethodAnchor, and inputMethodInputItemClip) are always have left=0, top=0, right=0, bottom=0. So I'll continue investigating...

any CJK folks have requests about what IME's to test (I only have linux & win dev environment setup at the moment)...I know there used to be a popular google one, but when I go to https://www.google.com/inputtools/services/features/input-method.html and click the "Windows" link (https://www.google.com/inputtools/windows/) I get a 404...so sounds like google discontinued their Windows IME.

Also I don't know how all IMEs work for displaying pre-edit strings...I'm testing the Windows 10 IME but notice it doesn't display any pre-edit string...and musescore current master doesn't display pre-edit string either, so in that case user doesn't see any latin characters of pre-edit string while being inputted...but I think other IMEs do display the pre-edit string in the IME...so I just don't know what the proper protocol musescore is supposed to follow...but as it is my PR above isn't concerned with that question, as it just fixes IME window positioning.

Hello ericfontainejazz

I’m so much appreciate for your many efforts..
Thank you very much!

I’ve just installed Google Japanese IM on Mac,
And here also doesn’t display pre-edit string, and the input method window is not directly under the cursor.

I tested MuseScoreNightly-2018-12-08-0922-master-a9203cb.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4346, revision: a9203cb

IM: Google Japanese IM and Microsoft Windows 10 IME

The problem about "the IM window position" is not solved,.
(although it's position was changed.)

Google Japanese IM:
MuseScore_GoogleIM_2018-12-08.png

Microsoft Windows 10 IME:
MuseScore_MS-IME_2018-12-08.png

(to re-emphasize for anyone paying attention...this PR only fixes cursor position for Win...there is still an issue on my linux machine. And I haven't attempted to fix display of pre-edit strings...I'll look into this now...)

Noike or Kazuma (or whoever wants to be a guinea pig), if you want to test out my PR on Win, it is at: https://ci.appveyor.com/api/buildjobs/i5wdpvrtl42r8tro/artifacts/MuseSc… ...and let me know if it fixes the cursor positioning issue.

In reply to by ericfontainejazz

Oh, I'm sorry, I misunderstood that your PR has already been merged to master branch and reflected to nightly build.
I tested your pointed version you builded, MuseScoreNightly-2018-12-07-2116-master-00abf80.

It seems that the cursor positioning(the IM window positioning) issue is fixed!

ericfontainejazz's version MuseScoreNightly-2018-12-07-2116-master-00abf80:
MuseScore_GoogleIM_2018-12-09_eric_ver.png

I believe I've fixed the problem of the pre-edit string not appearing...turns out the score was missing an update after each keystroke

The Win rebuild of my PR should happen in the next 30 mintues or so...in case NOIKE wants to test, just go to https://ci.appveyor.com/project/MuseScore/musescore/builds/20878795 and go to "Artifacts" and download the .7z

The related problem on Linux I described I can't seem to figure out though...that almost seems like a problem with the linux input editor, or even possibly Qt...so I'm not going to worry about that.

Status PR created fixed

Fixed in branch master, commit 11a754d6db

fix #269036 IME Cursor rect, enable, update

Previously the InputMethod would appear at the bottom center of ScoreView. This is because someone's previous commit broke the main if statement in ScoreView::inputMethodQuery such that it would always fail. That resulting in undesired default fallback behavior which caused the cursor to appear below the bottom of the ScoreView, rather than immediately below the TextBase element that user wants to input to. Fixing that if statement allows my original code to work again.

Additionally I noticed sometimes input editor would fail to work after unselecting the text element. Turns out that was because the query for Im::Enabled was set to isEditing(). I found by always returning true for that case for TextBase objects, that resulted in the InputMethod to always work on subsequent edits.

There was also a problem with the pre-edit string not appearing while inputting, which was a result of forgetting to update the score after layout when inputting each character of pre-edit string.

Also added dummy slot functions for all signals that InputMethod can produce...right now just outputting debug messages. In the future might end up responding to those signals, although for now leaving as empty skeleton functions.

ericfontainejazz

Sooo great!
I also tested the recent nightly build on Mac and it works as well !!

Literally, You saved our MuseScore life in the near future!
Thank you so much for all your works :)