IME related problems

• Apr 11, 2012 - 14:43

We Japanese use 2 byte characters for Japanese letters. To write lyrics, we have to turn on IME which convert the combination of key inputs to a 2 byte character - Hiragana , and waits until getting a space input for converting Hiraganas to Kanji - Chinese characters, or Enter key for fixing it.
So, MuseScore doesn't get a space directly, which leads not to jump to the next note.
To move on to the next note, we have to change IME's mode for Japanese to English mode, then hit space bar once, and change the input mode to Japanese. This is very cumbersome and so slow.

Is there any way to move the cursor to the next note ?
If no, we really want a keyboard shortcut to go to the next note and back.

One more our difficulty is while IME gathering inputs and storing Hiraganas, we can't see what we inputted.
Nothing changes in the blue box. We want the blue box as text-box in HTML like this .


Comments

Thanks a lot for reporting this. Do you think this issue is applicable to all CJK languages?

I searched if we had an issue for this before, but apparently not.
A chat with lasconic revealed that this problem is introduced with MuseScore 1.2 since previously you navigate go to the next/previous syllable/word with the arrow keys. Not anymore in 1.2 since now arrow keys are used reposition a syllable/word.

In reply to by [DELETED] 5

Sounds like you're saying that space cannot work to move to next / previous note when using this form of multibyte character input, and that's why the arrows should move to next / previous note rather than acting as a 1sp nudge? Presumably the 0.1sp and 0.01sp nudges could still work as is?

I'd still prefer a different solution if possible, though. The ability to nudge lyrics, chords, and indeed all text items by keyboard is too important to limit in this way.

Ideally, it seems that getting space bar to in IME the same it does in "regular" mode would be ideal. Is that out of the question?

If so, the next thing I'd propose is that a *different* shortcut be used as the alias for space/shift-space. Tab/shift-Tab, for instance, which currently has no useful function in lyric entry. This doesn't solve the problem for chords, but I don't know that anyone would likely be using multibyte characters in chords. And I take it that none of this is an issue in ordinary text, since space has no special function there?

Truth be told, though, what I would *really* prefer to see long term is for nudging to be enabled without needing to enter Edit Mode. Edit Mode is currently locked to a single item at a time, but nudging would ideally be applicable to many selected items at once. You can currently drag multiple items at once, but not nudge as far as I can tell. Although it would require an adjustment to our current ways of doing things, I think it would be cool to have a new "nudge mode", enabled with some keystroke (Enter, maybe). So instead of double-clicking a single item to enter Edit Mode and thereby nudge it, you'd hit Enter and *all* currently selected items would become nudgeable.

Seems this would also address my other concern with nudging, which is that some element types (like text) cannot be be budged vertically - only horizontally. I assume that's because the nudging is tied into Edit Mode, and the up/down arrows have their own regular function for text, ad would hence need to be special-cased (as left/right apparently are). With a "nudge mode", I would think all items would be handled the same.

In reply to by Thomas

Yes, I think so cause IME for CJK works as a front end processor.

I tried arrows which nudge the text a little bit. I've just read the discussion.
If I was there, I should have "recall" him the reason not to change it. -)

In reply to by YAMAKAWA

I wrote the irrelevant point.
IME for CJK are using 1 byte space (space input) for converting a set of key inputs, and it doesn't hand 1 byte space to MuseScore.
I think MuseScore may be able to handle double byte space as well as single byte space during Lyrics mode.

Double byte space is mapped at u3000 in Unicode, 0x81,0x40 in shif-JIS.

Do you still have an unanswered question? Please log in first to post your question.