hterm: unicode: some (non-wide) character glyphs are wider/narrower than 1 character depending on font |
||
Issue descriptiondepending on the font used, some emoji characters might be wider than a single character for example: ☁️ (U+2601) -- DejaVu Sans Mono; single width ⛈ (U+26C8) -- Noto Sans Symbols; double width ☀ (U+2600) -- DejaVu Sans Mono; single width it largely comes down to the fact that some monospace fonts don't have glyphs, so we fallback to non-monospace fonts. considering the holes in the font can be completely random (from our pov), i don't think hardcoding any assumptions here will work :/. we need to keep our notion of "wide chars" in sync with the unicode standard since that's what other projects use. if our cursor tracking gets out of sync of the remote software, then we won't render correctly. i suspect our only real course would be to build a lookup table at runtime every time we see a new character. if the monospace font doesn't have the glyph, we have to manually force a sc-node class (which will force the character to have a single character size). it will mean the glyph will most likely get chopped, but we don't have much of a choice here.
,
Aug 9 2017
> i suspect our only real course would be to build a lookup table at runtime every time we see a new character. if the monospace font doesn't have the glyph, we have to manually force a sc-node class (which will force the character to have a single character size). it will mean the glyph will most likely get chopped, but we don't have much of a choice here. This would work more or less for non-complex script characters. When forcing the width, it may be a good idea to refer to the Unicode East Asian Width ( http://unicode.org/reports/tr11/tr11-6.html ) if not already done that way. For complex scripts (e.g. Devanagari, Arabic) , the notion of monospace does not make much sense (Thai does have some 'tradition' of terminal support). What to do? Perhaps, forcing the width per grapheme cluster (instead of per character)? > under CrOS, we see: ⁝ (U+205D) -- Tinos font; very very narrow width A newer/upcoming version of Noto Sans Mono is going to have a more uniform character coverage and is likely to cover U+205D.
,
Aug 9 2017
hterm already handles wide characters via a wcwidth() implementation, so we don't have to worry about those here. i.e. that should cover all of the cjk scripts. i outlined a plan in issue 654839 for changing the code from splitting on codepoints to splitting on graphemes. we need that to fix handling of combining characters. once that's in place, implementing this is a lot easier. i have a poc locally, and i posted thoughts on the overall algorithm here (Rob & i hashed things out more in the follow ups): https://groups.google.com/a/chromium.org/d/msg/chromium-hterm/YEMRWbiACbI/1a7WT0llBAAJ i agree that for some scripts, monospace isn't a concept, or doesn't work well. my thinking is that the current behavior is already bad/inconsistent ... try editing lines that have text that is too narrow/wide and it becomes a nightmare. we're also limited by most software here ... editors are using wcwidth() to do their cursor tracking, so if hterm tries doing anything else, it all falls apart. making the glyph measuring logic apply to all is a lot easier than having a white/black list, and it'll at least be consistent/reliable across all fonts/scripts. i'm using the pathological cases like 'H̙̙̔̄͜Ṯ̴̷̷̗̼͍̿̿̓̽͐Ḛ̛̙̞̪̗ͥͤͩ̾͑̔͐ͅM̴̡̲̭͍͇̼̟̯̦̉̒͠O̜͎͍͙͚̬̝̣̽ͮ͐͗̀ͤ̍̀͢Cͯ̂͐͏̨̛͔̦̟͈̻ ̵̞̹̻̀̉̓ͬ͑͡ͅEͨ͆͒̆ͮ̃͏̷̮̣̫̤̣H̹̙̦̮͉̩̗̗ͧ̇̏̊̾' and it actually works with my changes :).
,
Dec 12 2017
,
Jan 29 2018
Issue 807007 has been merged into this issue.
,
Jun 13 2018
vim-airline has a nice number of broken characters: " unicode symbols let g:airline_left_sep = '»' let g:airline_left_sep = '▶' let g:airline_right_sep = '«' let g:airline_right_sep = '◀' let g:airline_symbols.crypt = '🔒' let g:airline_symbols.linenr = '☰' let g:airline_symbols.linenr = '␊' let g:airline_symbols.linenr = '' let g:airline_symbols.linenr = '¶' let g:airline_symbols.maxlinenr = '' let g:airline_symbols.maxlinenr = '㏑' let g:airline_symbols.branch = '⎇' let g:airline_symbols.paste = 'ρ' let g:airline_symbols.paste = 'Þ' let g:airline_symbols.paste = '∥' let g:airline_symbols.spell = 'Ꞩ' let g:airline_symbols.notexists = 'Ɇ' let g:airline_symbols.whitespace = 'Ξ' " powerline symbols let g:airline_left_sep = '' let g:airline_left_alt_sep = '' let g:airline_right_sep = '' let g:airline_right_alt_sep = '' let g:airline_symbols.branch = '' let g:airline_symbols.readonly = '' let g:airline_symbols.linenr = '☰' let g:airline_symbols.maxlinenr = '' this one in particular, causes the line to be shorter than it should: ⎇ i believe it's pushing the height of the line up, and then it overflows on the bottom or something weird...
,
Jun 13 2018
please link to the exact font you're testing with. what version of Secure Shell/hterm are you using ? there shouldn't be any more scenarios where lines get shifted up/down by fonts.
,
Jun 13 2018
Here you go: https://node.zeneval.com/powerline-web-fonts/fonts/SourceCodePro.woff2 I have tried various terminal apps, Secure Shell, mosh (with my own powerline fonts hacked in), etc.. Secure Shell: 0.8.43 Mosh: fork of 0.5.4 with powerline fonts added: https://github.com/rpwoodbu/mosh-chrome/compare/master...gordol:master To be fair, this happens with or without the Powerline fonts present. Plain monospace font that comes with Chrome OS causes this to happen too.
,
Jun 13 2018
are those screenshots from Secure Shell or mosh ? i don't see any vertical rendering issues with Secure Shell and your snippet in comment #6. if it's with mosh, you'll want to report it to the mosh guys as i think they're running an older hterm w/out these bugfixes. these glyphs have incorrect width (with default CrOS Noto fonts) which matches this bug report: ☰ ⎇ ∥ all the other glyphs render fine for me. same goes with that SourceCodePro webfont.
,
Jun 13 2018
This happens with, or without the powerline font, for what it's worth... Screenshots attached for both, showing the settings window. You can find the glyphs used here: https://github.com/vim-airline/vim-airline/blob/master/doc/airline.txt#L258
,
Jun 13 2018
Those are mosh... But here's secure shell, with and without powerline font... it looks similar... but the height issues are not present.
,
Jun 13 2018
yes, for the few glyphs that i listed, they render too wide and so the whole line gets shifted slightly. fundamentally it's a bug in the font, but we can workaround it in hterm given enough effort.
,
Jun 13 2018
Issue 852491 has been merged into this issue. |
||
►
Sign in to add a comment |
||
Comment 1 by vapier@chromium.org
, Jul 21 2017