mirror of
https://github.com/rivo/tview.git
synced 2026-04-26 21:35:54 +03:00
[GH-ISSUE #278] ™ leads to rendering bugs #215
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tview#215
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SoMuchForSubtlety on GitHub (Apr 25, 2019).
Original GitHub issue: https://github.com/rivo/tview/issues/278
displaying a string with
™in it can lead to rendering bugs.I recorded two examples with slightly different bahaviour.
https://streamable.com/d6cmq
https://streamable.com/k5vp9
@calzoneman commented on GitHub (May 14, 2019):
I actually ran into this recently.
The root of the problem is in
go-runewidth, whichtviewuses to compute the screen cell width of characters/strings.™is in the Unicode standard Emoji class, andgo-runewidthconsiders all emoji to be of width 2, however, some terminals seem to only treat codepoints in the Emoji_Presentation block to be double-width, and ™ is not one of those (I cannot discern what rhyme or reason was used to decide which codepoints are Emoji_Presentation and which are not; hence, my terminal emulator tends to cut a lot of glyphs that should be double wide in half). As far as I can tell, no standard prescribes monospace character width of Unicode codepoints, which is unfortunate and results in not just emoji rendering glitches but also numerous hacks to attempt to get Asian character sets to render correctly.Personally, I am using this patch to
go-runewidthwhich at least makes the emoji width consistent with my terminal, although as stated above I'm still unsatisfied with the resulting rendering glitches since my symbol font and my terminal emulator seem to disagree on which codepoints should be double width or not:Patch was built by having
go-runewidthonly treat Emoji_Presentation as double-wide, not all Emoji. See: https://unicode.org/Public/emoji/12.0/emoji-data.txt@rivo commented on GitHub (Jun 9, 2019):
@calzoneman Interesting observation. Are you sure this is due to
tviewusinggo-runewidthor rathertcellusing it? These screencasts show misplaced border characters buttviewactually places them into specific screen positions and leaves it up totcellto render them out correctly.The
go-runewidthproject says it's a Golang implementation of the POSIX C functionwcwidth. (This Javascript port provides some background.)I wonder if your patch improves
go-runewidthgenerally or if it breaks on some terminals. I think it makes sense to post this as an issue over at https://github.com/mattn/go-runewidth/. If it's an improvement, maybe as a PR?I'm closing this as it looks like I cannot fix this on my end.
@calzoneman commented on GitHub (Jun 9, 2019):
In my case, I narrowed down the problem to
TextView.draw:In this case,
screenWidthis calculated byiterateString()which internally callsscreenWidth()in util.go, which depends onrunewidthdirectly.The resulting problem in my terminal was that the cell immediately to the right of the
™would "stick" to whatever character was previously there, since the text view draw method thinks it is 2 cells wide and thus doesn't clear that cell. Of course, even if tview did clear that cell, there would still be a rendering glitch in that there would be an extra space in terminals that render™as one cell, so that's why I opted to patch go-runewidth for my use case.I posted it here in case it helps anyone who is searching in this repository -- I agree it might make sense as a runewidth patch but I'm not exactly sure whether it breaks some terminals. As far as I can tell, no one has successfully standardized which characters are double wide, so the whole situation is sort of a mess.
@rivo commented on GitHub (Jun 9, 2019):
I understand what you're getting at and what you're describing is most likely an issue with
tview's dependence ongo-runewidth. But from I can see in @SoMuchForSubtlety's screenshots, the problem is bigger than that. Look at this part:The left border characters of the "Info" box don't line up. In some of the lines that contain the
™symbol, they are shifted to the left by one character. When I draw theBoxborders, I place the characters at specific screen positions, as you do intcell. The fact that they don't end up where they should points to a problem intcellas well (and it could be the same reason).Also, as you can see in the code snippet you quoted, I do clear the second cell. The screen buffer should not contain any previous characters anymore. So I think there's a problem here, too. (I've seen this before but I can't reproduce it reliably.)
As for
go-runewidth, I wonder if the originalwcwidthor any of its descendants (e.g. the Javascript or Python versions) have the same problem as we do. If they don't, maybe it's worth looking at those implementations and making corresponding fixes togo-runewidth.