Text caret position shifts when typing Japanese #447
Comments
|
Created by: benfry This is likely due to the fixes for #194, #226, #342 which were major problems that prevented people from working at all. Do I understand correctly that Japanese works as long as you use a truly monospace font? Does it work correctly if you use the default monospaced font (meaning that you don't change anything in Preferences)? I'm just trying to understand the severity of the issue. |
|
Created by: TN8001
There is no true monospace font (one alphabetic character for one Japanese character) in Japanese as far as I know.
To restore the default settings, do I just delete "C:\Users[UserName]\AppData\Roaming\Processing"? Language: Japanese However, it does not do font fallback, so when I type Japanese, I get substitute characters (small rectangles).
There is no problem if you do not enter Japanese, but you may want to enter comments or text strings. Chinese would be the same, and I am sure there are other languages that are affected (I am not familiar with the other languages). |
|
Created by: benfry I see… I wasn't aware that it wasn't a true monospace—I hadn't noticed that the larger/wider Latin characters used with the CJKV “monospace” fonts weren't the same width (they're very wide for Latin!) So we'll need to do some work to update the fixes for those other bugs (which finally got us reliable widths across devices, OS zoom, low-res/hidpi/retina) with a way to handle the changing widths. Thanks for the report. |
|
Created by: Sardtok The Chinese and Japanese characters themselves are monospaced, but the latin characters are typically "half-width". There are also "full-width" latin characters, but they have separate codepoints from the ASCII/ANSI characters. There are a few small "combining" characters in the syllabic alphabets. Not in the combining sense of Unicode, as they are separate characters, but they read as a single sound together with the character they modify. But they are still the same width, with a bit of extra whitespace on one side. One of the syllabic alphabets can also be input in half-width: These are all A's, first full-width latin, full-width katakana, half-width (ASCII) latin and half-width katakana. So, it's complicated. I think Japanese is probably the most complicated of the CJK languages (EDIT: layout-wise). Chinese uses only Chinese characters, Korean usually doesn't use Chinese characters much anymore and stick to Hangul a syllabic monospaced alphabet, and Japanese uses a mix of Chinese characters along with two syllabic alphabets and sometimes also the latin alphabet, but the syllabic alphabets and the Chinese characters are monospaced, except for the half-width katakana. Some punctuation, and some small vs. large versions of characters where the small versions combine with other characters: I cannot speak for other Asian scripts like Thai, or for that matter the Arabic script families which use diacritics for vowels that modify the whole size of the consonant pattern characters, and writing direction gets really weird when mixing LTR and RTL in those scripts (that's as far as my knowledge of the Arabic languages stretches from my general linguistics courses from ages ago). |
|
Created by: benfry Understood; like I said, I didn't realize the already wider-than-normal Latin characters weren't actually full width. Anyone want to help with a fix? It's a combination of the hard-coded with handling as a result of that the issue list I noted above, and probably an extra update or two inside |
|
Created by: TN8001
This is a serious issue for me and I would love to help. However, I am not aware of any detailed change history to date.
The cause itself is clear. This was changed to take the size of each character. static int getTabbedTextWidth(Segment s,
FontMetrics metrics, int x,
TabExpander e, int startOffset) {
int nextX = x;
char[] txt = s.array;
int txtOffset = s.offset;
int n = s.offset + s.count;
for (int i = txtOffset; i < n; i++) {
int charWidth = metrics.charWidth(txt[i]);
if (txt[i] == '\t') {
if (e != null) {
nextX = (int) e.nextTabStop(nextX, startOffset + i - txtOffset);
} else {
nextX += charWidth;
}
} else if (txt[i] == '\n') {
} else {
nextX += charWidth;
}
}
return nextX - x;
}Perhaps this is sufficient? static int getTabbedTextWidth(Segment s,
FontMetrics metrics, int x,
TabExpander e, int startOffset) {
int nextX = x;
char[] txt = s.array;
int txtOffset = s.offset;
int n = s.offset + s.count;
for (int i = txtOffset; i < n; i++) {
if (txt[i] == '\t' && e != null) {
nextX = (int) e.nextTabStop(nextX, startOffset + i - txtOffset);
continue;
}
nextX += metrics.charWidth(txt[i]);
}
return nextX - x;
}It works fine in my environment (Windows10 100% 125%), but |
|
Created by: Sardtok I might be able to test your fix on various DPI Windows PCs and Macs later tonight. |
|
Created by: Sardtok Seems to work fine both on Windows 10 at 100%. 150% and 200% scaling, and on MacOS Monterey with the built-in Retina display (pixel density 2 in sketches). No offsetting of the caret in either direction. The only thing that was a bit weird on my Mac was full-width latin characters, which had no metric changes from ordinary latin characters. The glyph looked different, but there was no spacing around it. Could be something with the Osaka font on MacOS, but it's hard to say. This is not related to this patch, as it looks the same without it. @TN8001 you should add a pull request to apply your patch. |
|
Created by: TN8001 Thank you for confirming.
I will be ready by the weekend. |
|
Created by: github-actions[bot] This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs. |
Created by: TN8001
This was translated by a machine.
Sorry for the delay in reporting this, as it stayed in beta1 due to #403 issues.
Description
Japanese characters are usually twice as wide as alphabetic characters. (Even in a monospace font!!!)
The caret position seems to be confused because all characters are determined to be the same width.
Many fonts are twice as wide (two alphabetic characters for one Japanese character), but some are not.
Expected Behavior
There was no problem with beta4.
Processing.4.0b4.mp4
Current Behavior
The video is beta5, but the same applies to beta6 and beta7.
Processing.4.0b5.mp4
Your Environment
The text was updated successfully, but these errors were encountered: