New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 802087 link

Starred by 10 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

hterm: font size incorrectly calculated for loaded web fonts

Project Member Reported by flackr@chromium.org, Jan 15 2018

Issue description

Chrome Version: 63.0.3239.140 (Official Build) (64-bit)
OS: ChromeOS 10032.86.0 (Official Build) stable-channel chell

What steps will reproduce the problem?
(1) Open secure shell
(2) Go to options
(3) Set user-css to https://fonts.googleapis.com/css?family=Inconsolata
(4) Set font-family to Inconsolata, Consolas, monospace
(5) Press Ctrl+Alt+T

What is the expected result?
Expect cursor to be where text is input.

What happens instead?
Instead it is offset. If you adjust the text size (<Ctrl>+ or <Ctrl>-) it will pick up the loaded web fonts text size.

I think it's measuring the text size before the user-css has loaded which in my case is using the Consolas fallback. If it could measure again after loading the user css file I think this would fix the issue.

Please use labels and text to provide additional information.


For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 
Screenshot 2018-01-16 at 9.11.35 AM.png
125 KB View Download

Comment 1 by vapier@chromium.org, Jan 15 2018

Summary: hterm: font size incorrectly calculated for loaded web fonts (was: Secure shell and crosh terminal do not get correct size for loaded web fonts.)

Comment 2 by bcmi...@google.com, Jan 30 2018

I saw size issues when using web fonts via fontlibrary.org (https://fontlibrary.org/face/go-mono), but not via Google Fonts.

I suspect that it might have something to do with the latency of actually loading the fonts: the fontlibrary.org is a truetype font (less compressed), whereas Google Fonts serves smaller woff2 files. (I'm also a bit lower-latency to Google's servers.)

Comment 3 by bcmi...@google.com, Jan 30 2018

See https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for a description of web font loading.

I suspect that hterm is measuring the font after the “block” period, but it should remeasure after the “swap”.

Comment 4 by vapier@chromium.org, Jan 30 2018

Status: Available (was: Untriaged)
it's even simpler than that: hterm doesn't wait for anything in its initialization logic.  it seeds the css settings from the user and font preferences, then calls the measurement funcs.  if the css hasn't loaded yet, it'll measure the non-webfonts, and there are no callbacks to recalculate things later on.

looks like there might be newer APIs in Chrome/Firefox we could use to hook into the load events:
  https://developer.mozilla.org/en-US/docs/Web/API/CSS_Font_Loading_API
 Issue 918801  has been merged into this issue.
Cc: raymes@chromium.org nverne@chromium.org jopra@chromium.org
Adding some crostini team and raymes (who did some work on hterm) to CC
Cc: vapier@chromium.org

Sign in to add a comment