Korean text input issue

[KevinH]

One last thing to check. Does the greyed out pre-composed characters issue in Korean show up when editing text in some other Qt widgets too (not just CodeView)?

Please try in the Find and Replace fields or in the MetaEditor text input fields and please let me know if the same problem still happens in those widget types.

[BeckyEbook]

In other windows there is no problem.
The cursor changes to block and then it is OK.

[KevinH]

So it is something specific to CodeView, then. Very strange.
CodeView is a QPlainTextEdit window that has QT::WA_InputMethodEnabled set by default inside Qt.

Calibre uses a QTextEdit and not a QPlainTextEdit for its CodeView editor equivalent (at least I think it does). So could you please try the same Korean Input Method test in Calibre's CodeView editor equivalent and let me know if it fails in the same way or is okay like Find and Replace?

[KevinH]

@BeckyEbook,

I just wonder if the new Sigil Preference setting to double the cursor width might be impacting this issue, ie. somehow preventing CodeView from moving to block cursor too.

If and when you get a free moment, please make sure that Preference setting is off and Sigil has been restarted and retest.

Thanks!

[BeckyEbook]

In my case, the double cursor width option is certainly disabled.

[KevinH]

Originally Posted by BeckyEbook

In my case, the double cursor width option is certainly disabled.

Thanks.

It was worth a shot.

I just do not understand why QLineEdits (like Find and Replace) and as used in the Meta Editor nicely switch from insertion cursors to block cursors when using the Koran IME on Windows while our CodeView (QPlainTextEdit) does not.

I can see no setting that should impact that.

[BeckyEbook]

Ad Calibre Editor.
It's a bit more complicated than that.
a) the problem with the strange marking of matching tags in calibre also occurs (one might suspect that this is related to the miscounting of characters when there is a "composing string" glyph between tags while typing).
b) the problem of greying does not exist, because both when typing and the finished mark are in one colour (white in dark mode and black in light mode).
c) outside the editor (e.g. the "Find" window) it behaves as Sigil does, i.e. correctly.

[KevinH]

Originally Posted by BeckyEbook

Ad Calibre Editor.
It's a bit more complicated than that.
a) the problem with the strange marking of matching tags in calibre also occurs (one might suspect that this is related to the miscounting of characters when there is a "composing string" glyph between tags while typing).
b) the problem of greying does not exist, because both when typing and the finished mark are in one colour (white in dark mode and black in light mode).
c) outside the editor (e.g. the "Find" window) it behaves as Sigil does, i.e. correctly.

I am confused. So there are two issues?

A. When highlight matching tags the highlight of the ending tag is "off" because of the "composing string" glyph.

and

B. The "composing string" glyph is somehow rendered in a colour that does not show up against the black background, white background, or line highlight color.

Problem A can be made to go away by disabling the highlight matching tag pair. Right?

Why can't problem B be made to go away by just changing the line highlight colour?

I keep looking at the OP's video but he/she types so fast I can not see the Problem B happening at all just Problem A.

What am I missing?

[BeckyEbook]

Yes, in Sigil, once the highlighting of matching pairs of tags is turned off, the A problem stops bothering.

However, it is not possible to specify a line highlight colour that does not interfere with reading the content and is neither white nor black nor grey, as this will in any case prevent the text being typed/typed from being read.

[DiapDealer]

It looks like the virtualkeyboard module and plugin is non-starter, here. The plugin pulls in the module whenever windeployqt is run. But even with the Microsoft Korean IME installed and active, debug output shows that neither the plugin nor the module are in use. Seems use of QtVirtualKeyboard needs to be implemented through C++ or QML.

[KevinH]

Originally Posted by BeckyEbook

Yes, in Sigil, once the highlighting of matching pairs of tags is turned off, the A problem stops bothering.

However, it is not possible to specify a line highlight colour that does not interfere with reading the content and is neither white nor black nor grey, as this will in any case prevent the text being typed/typed from being read.

Hmm ... on my macOS in my normal dark mode the line highlight colour is a medium-light purple so it nicely shows either dark or light pixels well.

So what happens if we turn off the line highlight colour by setting it to match the background colour?

Is the lack of a line highlight colour and no matching tag highlighting the only reasons that Find and MetaEditor are okay?

[KevinH]

@DiapDealer,
Can you recreate both problems A and B with your current setup?

[BeckyEbook]

Originally Posted by KevinH

So what happens if we turn off the line highlight colour by setting it to match the background colour?

Is the lack of a line highlight colour and no matching tag highlighting the only reasons that Find and MetaEditor are okay?

Two images in dark mode.

[KevinH]

The funny thing is that as far as I know, there is no way for CodeView to detect that someone is in the middle of a "composing string" and then they pause.

To map tag pairs, CodeView grabs the entire source of the CV as text and then parses it to create a list of tag beginning and end (matching) starting positions and ends so it knows where to highlight.

But when in the middle of composing a character, a placeholder for the "composing string" is not added because the total number of char16 (QChars) are not known fully until the actual character to be input has been fully formed.

Qt and the IME really should not be injecting parts of a incomplete character into the document until the actual fully formed character is ready.

So there really is nothing we can do about Problem A.

[KevinH]

Problem B is strange too. Why is it rendered so faintly? Is it because it is rendering an incomplete "composing string"? Is the colour meant to indicate it is incomplete? I wonder where in the Qt code the colour is determined? Is it taken from a Windows setting?