Bug: reversion to default colour when typing Korean character

[DIV]

I have encountered a weird bug.
It's reproducible, but only in very particular circumstances:

1. Add a comment as Typewriter text or Text Box text, in the default font (set to Segoe Print?) and in the default colour (e.g. blue). The text can be in English or Korean (or whatever).
2. Change the colour of the text.
3. Type a Korean character (in the middle of the existing text) using the Microsoft IME.

Desired behaviour: the existing text retains the modified font colour, and the new text also takes on the modified colour.
Actual behaviour: the existing text reverts to the default colour, whilst the new text nevertheless takes on the modified colour.

See attachment.

PDF_reversionToDefault_RevA.pdf

Note: none of the nominally used fonts in the attachment support Korean characters — behind the scenes the Korean characters are automatically being rendered in Malgun Gothic (as per the embedded font subset).

Version: Editor 9.4 build 363.0 (installed)
Operating System: Windows 8.1 x64

—DIV

[Paul - PDF-XChange]

Hi DIV,

what should I be typing to get the Korean character? Google Translate says 할 is "Hal" but when I type that in the IME I don't get the character you show.

image.png

It also is not doing the colour thing you report. Can you perhaps make a video of the process so I can more easily reproduce things? From what I am seeing it appears to be working as expected, the colours are not changing but matching those around it.

I don't think I am testing this right.

[rakunavi]

Hi DIV, Hi Paul,

This issue is also reproduced in the Japanese environment. It may be a common issue in 2-byte language environments that use IME for character input. This issue occurs with text content as well as comments.

Please see the attached verification video. Also attached are the sample files used and after the issue occurred. The verification was done on a Japanese version of Windows 10 with the English language pack installed.

• CapturedVideoWithSample.zip

In the video, I first add English strings to text containing both English and Japanese and verify that the issue does not occur. Next, Japanese strings are added with Microsoft IME, and it is verified that the issue occurs. This issue occurs only when typing with the IME. In other words, it does not occur when Japanese text is copied from the clipboard.

I had the same problem just the other day, so when I read DIV's post, I immediately understood what DIV pointed out. I had given up on reporting it because I didn't know how to reproduce it, but DIV's post solved the mystery.

Hoping that the above information will be of some help to you.

Best regards,
rakunavi

- PDF-XChange Editor Plus Version:9.4 build 363.0
- OS Version: Windows 10 Home/Pro 21H2 Build 19044.1889
- PC Model: Lenovo IdeaPad C340-15IWL / HP ProDesk 600G1

[DIV]

Thank-you so much, rakunavi!
I am not familiar with making videos for such things, so you've done us a favour with that, and also verifying that you can reproduce it with another two-byte language.

Actually, I feel that this may be a recent regression in Editor, because I reckon I have been undertaking this type of action for the past few years, and never noticed the problem before. But I cannot say with 100% certainty, because I might also be doing something slightly different that I hadn't realised.

Paul, the "colour issue" is the only issue of relevance.
It doesn't matter which Korean character is typed in — there is nothing at all special about "할", for example (with Korean enabled in the IME type successively "gkf", and then arrow across or type something else to 'confirm' the character).
The same "colour issue" also happens if the original text is entirely Korean. (I only made the original text English in the examples so that it would be easier for Tracker to spot the difference.)

Paul, maybe it will already be clear from the video, but in your sample I couldn't see that you had tried to change the colour of the original text (to differ from the default colour!) before typing in the Korean text from the IME.
Yes, I can see that you must have typed "hal" in the IME, which gives "ㅗ미". As mentioned above, the particular character isn't important (although in your case it was sort of a half-character followed by a character).

—DIV

[DIV]

Indeed, I cannot get this bug to occur in Editor version 9.2 build 358.0 (portable), which I also have installed on my system.

PDF_reversionToDefaultNot_RevA.pdf

[Paul - PDF-XChange]

Hi guys,

thanks for the details on this, I have reproduced the issue and raised the associated ticket: RT#6234: Double bit character style inconsistencies

As in other cases, the ticket is for internal use, so ask here if you need a status report.

cheers

[Paul - PDF-XChange]

Hi guys,

RT#6234: Double bit character style inconsistencies is set to status resolved. Please confirm the fix in the current build is as expected.

Please and thanks

[rakunavi]

Hi Paul,

The issue reported above has been resolved in Ver 9.4 build 364.
I appreciate all the hard work and efforts of the support and development team.

Best regards,
rakunavi

[Stefan - PDF-XChange]

[DIV]

Yep. Confirmed resolved at my end too (now on 9.4.364.0, installed on 64-bit Windows 8.1).
Thanks!

[Sean - PDF-XChange]