Hello!
First of all, thank you to the development team for addressing the issue with displaying multi-byte characters for Chinese, Japanese, and Korean.
According to public information, the original creator of this text editor was Ukrainian, so the display and editing of multi-byte characters were not considered during its initial development.
Some programmers have attempted to support the display of CJK (Chinese, Japanese, Korean) text, but they eventually gave up due to the large amount of code modification required and changes in the program architecture. Therefore, we are deeply grateful to the KIDE development team for improving FastColoredTextBox, making it the most significant advancement so far.
There are two existing issues:
When a single line of text exceeds the display range, the horizontal scroll bar fails to display correctly. Even when it does appear, the stretch range of the horizontal scroll bar control is incorrect.
The cause of this problem is that although CJK characters have been assigned the correct width, the "visible" and "Maximum" properties of the horizontal scroll bar are still calculated based on the width of a single character.
The final solution to this issue can reference the handling in the source code of Windows' built-in "Notepad." When rendering character graphics, if the text is in ANSI encoding, the character's width should be calculated based on its encoding length.
For example:
Take "hello," with decimal encoding "104,101,108,108,111," consisting of 5 ASCII characters. If the width of each character is 8 pixels, then the starting position of the first character is 0, the second character is at position 8, the third at 16, the fourth at 24, and the fifth at 32.
Now, take "川崎" in "GB2312" encoding:
The decimal encoding for "川" is "180,168."
The decimal encoding for "崎" is "198,233."
Each character consists of two character encodings, which we refer to as double-byte (Full-width).
When rendering the graphic for each character, its width should be set to 8*2=16 pixels, ensuring that each character has an appropriate width and that the characters in each line are aligned properly.
This is the universal method used by multi-language text editors for character display.
Of course, some developers use another method—calculating the width of each character based on the font settings and then performing addition to render the characters accordingly. This makes the characters appear more compact, although only certain image processing software (like Photoshop) adopts this approach.
2. The second problem is the problem of the scroll bar eating characters, which means that in CJK characters, when the scroll bar is dragged horizontally, the characters on the left will disappear in advance. This problem should also be caused by the double-byte encoded characters mentioned above being calculated according to the single character width.
If the first problem is solved, then this problem will not exist.
