| Summary: | Down arrow (and other arrows) characters display wrong width | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | Norman Diamond <n0diamond> |
| Component: | font | Assignee: | Konsole Developer <konsole-devel> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | AndyKluger, sebastian.englbrecht, thomas |
| Priority: | NOR | Keywords: | investigated, triaged |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Screenshot | ||
|
Description
Norman Diamond
2015-06-13 03:59:26 UTC
When the language of installation of openSuse 13.2 is Japanese, the default font of Konsole is Monospace, which maps to IPAGothic, and the problem occurs. When the Konsole font setting is changed to DejaVu, downarrows display properly. The display isn't identical to what it used to be in Suse 11, but it's correct. Konsole knows what locale it's running in (e.g. the menu bar and settings dialogs are Japanese) but I have a feeling that it doesn't really matter. The downarrow character in IPAGothic is rendered as a halfwidth character (one ASCII character cell) but it's really a fullwidth character (two ASCII character cells), so a sequence of five of them look like three. vim counts characters correctly but the user gets confused when rows of text appear not to be aligned correctly, as well as the apparent number of characters not being correct. The downarrow character in DejaVu doesn't suffer from this problem. It's rendered as a fullwidth character and everything is working. Despite the need to inform the Unicode consortium that halfwidth and fullwidth characters are separate characters for arrows too, not just for letters such as Roman, Greek, Cyrillic, and katakana, I have a feeling that this Konsole bug is not their fault. Can you update and let us know if this is still an issue? and perhaps add a screenshor. Created attachment 104106 [details]
Screenshot
Screenshot
The problem was consistent in a different installation of OpenSuse 13.2, but the problem is inconsistent in my present installation of the same OS. The screenshot is from my present installation, showing the inconsistency. As shown in the "vi" session, when the cursor is in the middle of a line containing arrow characters, something is greatly confused and the display is completely scrambled. This still makes editing just about impossible. But for unknown reasons, in my present installation, the output of cat displays the arrow characters properly in full-width. In my earlier installation, arrow characters were all displayed as half-width both in vi and the output of cat. This still made editing impossible. In my earlier installation, a Japanese person recommended changing the Konsole setting for fixed-width font. Some fonts displayed arrow characters as full-width and solved the problem consistently. In my present installation, I think I haven't tried such an experiment yet, but I don't know what produced the inconsistency. Changing status from Needsinfo back to Unconfirmed. If you disagree, please let me know. Might be relevant: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1665140. The down arrow U+2193 is indeed of "ambiguous width" both in Unicode 8.0 and 9.0. "The down arrow U+2193 is indeed of "ambiguous width" both in Unicode 8.0 and 9.0." Then it's not entirely Konsole's fault, but we still need a workaround for the Unicode consortium's bug. The present behaviour sometimes makes Konsole unusable, just like (retired C language lawyer speaks up now) a C compiler that only compiled one single valid C program would be legal but unusable. How did the Unicode consortium figure out that half-width a, full-width ａ, lower-case a, upper-case A, upper-case Ａ, etc., shouldn't all have ambiguous width, ambiguous casing, etc. But just allowing Konsole to be unfriendly doesn't force Konsole to be unfriendly. Konsole uses QPainter::drawText() for the complete line, which handles the pixel advances the fonts provide. The only way I see to fix this is to call QPainter::drawText() for each cell character individually, so that the characters are always aligned to grid, regardless how wide they are in the fallback fonts. I'm observing the same with other characters too, in Konsole 19.12.3 (=default on kubuntu 20.04): ✔ (checkmark) and ✖ (X) Here's a (very fancy ;-) reproduction script: ```bash #!/bin/bash echo '✖'; echo '✖A'; echo '✖ A'; echo '↓'; echo '↓A'; echo '↓ A'; ``` The problem only occurs, if the UTF8-character is *immediately* followed by another (`✖A`); it works if it's followed by a line break or space. Here's a screenshot: https://github.com/Codeception/Codeception/issues/6029#issue-735432274 Can you try a recent version such as Qt6? If you can reproduce any oddities, just revert back to confirmed. Thanks. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! (In reply to Bug Janitor Service from comment #12) > This bug has been in NEEDSINFO status with no change for at least > 15 days. I thought it was closer to 15 years than 15 days, but actually it's only closer to 9 years. The bug caused trouble for me when I edited source files that had been created by others, with downarrows and uparrows in comments. I no longer edit their source files, so I am no longer affected by the bug. This doesn't mean it WORKSFORME, because I don't find out if it works or not. Three years ago Thomas Landauer found similar manifestations of the bug. If he's still active, perhaps you can ask him if it's fixed or not. I don't know how to get Qt 6.
The issue from my above reproduction script seems to be fixed now in Konsole 21.12.3 (Qt 5.15.3).
But there's still something wrong, regarding styling (color):
* The color is never working for those special characters
* The character is only displayed partially, if there's no blank after it
```bash
#!/bin/bash
GREEN='\033[0;32m'
NC='\033[0m' # No Color
printf "${GREEN}Green${NC}\n" # Just to prove that `${GREEN}` is working in principle ;-)
printf "✔\n" # Full checkmark displayed in grey color
printf "${GREEN}✔${NC}\n" # "Half" checkmark displayed in grey color
printf "${GREEN}✔ ${NC}\n" # Full checkmark displayed in grey color
```
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! |