Unicode box drawing characters missing in hterm

[Suraj Kurapati]

Hello,

Hello,

I'm using Secure Shell 0.8.27 on my Acer C720 chromebook:

Google Chrome 34.0.1847.134 (Official Build 266018) 

Platform 5500.130.0 (Official Build) stable-channel peppy

I have Secure Shell pinned to my shelf and configured to "open as window" and to use "monospace" as its font-family.

The problem is that it's unable to draw some Unicode box drawing characters whereas the Chrome browser has no trouble doing so using the same "monospace" font.

For example, please compare the attached screenshots that show a Unicode test file (available at https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt) in the Chrome browser on the left, and the same test file in a Crosh Window on the right:

chronos@localhost / $ reset; curl -s 'https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt'

This discrepancy affects me because I use tmux inside Secure Shell and its pane borders are not rendered properly and shifted over due to the missing Unicode box drawing characters in Secure Shell, as shown in the attached screenshot.

Thanks for your consideration.

[Robert Ginda]

It looks like you're using crosh?  There is a known issue with crosh (https://code.google.com/p/chromium/issues/detail?id=278340) where unicode characters get corrupted if sent too quickly.  The end of UTF-8-demo.txt looks like this to me, over ssh:

Is there a reason you're using crosh rather than ssh via Secure Shell?

Rob.

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/547749e9-77ca-4443-bb04-d44e3576071a%40chromium.org.

[Suraj Kurapati]

Hi Rob,

Thanks for that existing bug report link; that is indeed the exact issue I am facing! :)

I'm using crosh (instead of ssh) because it's the most efficient (local tty, no ssh overhead) way to access my local Crouton chroot Debian GNU/Linux installation (wherein I don't want to run an ssh daemon just for local terminal access).

However, I have seen this issue in Secure Shell as well when connected to Linux servers at my workplace (target hosts are on the same LAN, so I guess it's fast enough to trigger this issue).

Thanks for your consideration.

[Robert Ginda]

Can you send a screenshot of this happening over ssh?  I've been under the assumption that the bug was in the transport layer that crosh uses, which is completely separate from ssh.  Notice that a definitive skidmark left by this issue is the "<?>" glyphs.

If this end up not being transport related then it's an entirely different bug than I thought.

[Suraj Kurapati]

Hi Rob,

You were right. I seem to have confused two different issues in my mind.

The Unicode box drawing characters do render correctly in Secure Shell
but not in crosh. However, the alignment of tmux pane borders is
messed up sometimes (as shown in the attached screenshot) in both
Secure Shell and crosh. Since this occurs in both tools, I think this
is the next issue that needs to be fixed after
https://code.google.com/p/chromium/issues/detail?id=278340 is fixed.

Thanks for your consideration.

On Tue, Apr 29, 2014 at 9:04 PM, Robert Ginda <rgi...@chromium.org> wrote:
> Can you send a screenshot of this happening over ssh? I've been under the
> assumption that the bug was in the transport layer that crosh uses, which is
> completely separate from ssh. Notice that a definitive skidmark left by
> this issue is the "<?>" glyphs.
>
> If this end up not being transport related then it's an entirely different
> bug than I thought.
>
>
> On Tue, Apr 29, 2014 at 8:55 PM, Suraj Kurapati <sun...@gmail.com> wrote:
>>
>> Hi Rob,
>>
>> Thanks for that existing bug report link; that is indeed the exact issue I
>> am facing! :)
>>
>> I'm using crosh (instead of ssh) because it's the most efficient (local
>> tty, no ssh overhead) way to access my local Crouton chroot Debian GNU/Linux
>> installation (wherein I don't want to run an ssh daemon just for local
>> terminal access).
>>
>> However, I have seen this issue in Secure Shell as well when connected to
>> Linux servers at my workplace (target hosts are on the same LAN, so I guess
>> it's fast enough to trigger this issue).
>>
>> Thanks for your consideration.
>>
>>
>> On Tue, Apr 29, 2014 at 8:06 PM, Robert Ginda <rgi...@chromium.org> wrote:
>>>
>>> It looks like you're using crosh? There is a known issue with crosh
>>> (https://code.google.com/p/chromium/issues/detail?id=278340) where unicode
>>> characters get corrupted if sent too quickly. The end of UTF-8-demo.txt
>>> looks like this to me, over ssh:
>>>
>>>
>>>
>>>

[Robert Ginda]

Those alignment errors happen when hterm is asked to display glyph that is wider or narrower than the width of your typical monospace glyph.  hterm depends on a consistent character width for things to line up properly.

It's a tradeoff for speed's sake  The alternative is to place every character in its own DOM  fixed-size node.  (With this approach, extra-wide characters would overlap their neighbors.)  Some day I may have time (or an intern) to try out the every-character-gets-a-node approach, but it won't be too soon.

Rob.

[Suraj Kurapati]

Hi Rob,

That seems like a reasonable trade-off. One character per DOM node
seems overkill.

Could the alignment be improved by using a different monospace font?
I just use the system "monospace" font on my chromebook. What do you
recommend?

Thanks.

[Robert Ginda]

My font-family preference is still the hterm default of: "DejaVu Sans Mono", "Everson Mono", FreeMono, "Menlo", "Terminal", monospace.  But I mostly use Secure Shell on my Linux desktop (where I assume "DejaVu Sans Mono" wins the font-family race), I'm not a tmux-with-split-panes user, and I don't typically display the unicode characters that seem to be causing your troubles.

I don't know if you'll find a decent looking monospace font that has a properly sized version of every glyph that pops out of UTF-8-demo.txt, but I hope you can find something that at least includes the characters you'll need from day-to-day.

If you can't find a suitable font in stock Chrome OS, you can try a web-font.  This thread explains how to set them up in Secure Shell: https://groups.google.com/a/chromium.org/d/msg/chromium-hterm/dFVAhCvaI4Q/G675nendpFAJ

Rob.

[Suraj Kurapati]

Hi Rob,

On Wed, Apr 30, 2014 at 12:35 PM, Robert Ginda wrote:
> My font-family preference is still the hterm default of: "DejaVu
> Sans Mono", "Everson Mono", FreeMono, "Menlo", "Terminal",
> monospace. But I mostly use Secure Shell on my Linux desktop
> (where I assume "DejaVu Sans Mono" wins the font-family race),

Thanks, "DejaVu Sans Mono" seems to help with the alignment. :)

> I'm not a tmux-with-split-panes user, and I don't typically
> display the unicode characters that seem to be causing your
> troubles.

Indeed, since Unicode box drawing characters are the culprit, I'm
now working around the problem by using the _same_ foreground and
background color to paint my tmux pane borders. This effectively
makes them solid colored lines and seems to have eliminated the
broken box drawing characters issue while reducing misalignment.

Thanks again for all your help!