intro-to-visidata
intro-to-visidata copied to clipboard
jsvine
Potential issue with rendering on Chrome
Flagged by @reagle in https://github.com/saulpw/visidata/issues/1418, picking it up here.
Figures in the documentation don't look correct in google-chrome/103.0.5060.53 on macOS 12.4 21F79 arm64.
Unfortunately, I can't seem to get this to reproduce on MacOS with the same Chrome version. For me, it looks as intended:
So, a few follow-up questions, based on a hunch that it may have something to do with fonts:
-
Do you happen to have network requests to Google Fonts blocked?
-
Do you happen to have any custom font settings that would override a website's defaults?
-
Anything else font-related that might be specific to your setup?
I launched it as cleanly as I could and changed font settings for serif, sans, fixed, etc. It made no difference.
open /Applications/Google\ Chrome.app --args --disable-extensions --disable-plugins --incognito --no-experiments --disable-remote-fonts https://jsvine.github.io/intro-to-visidata/
Thanks for those details. Running your command on my machine produces a slightly funky (because of disabled fonts) version, but not reproducing the line-wrapping issue in your original screenshot:
On your machine, what happens if you remove the --disable-remote-fonts flag?
In the command above, you can see I passed that flag too. It makes no difference either way.
Hm, then I'm a bit stumped, given that I can't reproduce those results with the given command (or more generally). But I'll leave this issue open for a while in case other folks have the same issue / can help triangulate.
BTW: still present in Version 104.0.5112.79 (Official Build) (arm64), even when launching with Incognito. Oddly, it doesn't show in Brave, which uses the same renderer for the most part.
I'm getting this in Firefox 104.0.1 on Windows 11.
Changing min-width on .ansihtml from 696px to 790px it fixes it. (sort of...)
But then it protrudes out the right hand side of the body text.
I also don't see any fonts loading in the Network tab of the inspector.
Thanks for letting me know! Could you (and @reagle, if possible) follow these instructions to determine which font the browser is actually using for the terminal-imitation?: https://stackoverflow.com/a/20830300
For instance, I get this:
On my mac it works, and looks the same as above. On my work Windows 11, I get the following:
My comment above about not seeing fonts load was a red herring, as they do load if I disable the browser cache:
Actually... I think I figured it out. I've set my minimum font size in Firefox to 13. If I change it back to 12, it fixes the issue. (after a page reload)
Perhaps setting the min-width property in terms of relative units such as em or ch might help it scale with font size?
@daviewales, similarly, if I set my minimum font size to 11, it looks good. The degree to which it is larger than that corresponds with how mangled the table looks. (I keep mine at 14.)
Thank you @daviewales and @reagle! I think we've nailed down the source of the issue, those minimum font sizes. I'll try to come up with a fix.
I think I may have fixed this! (c07fdb3) ch did the trick. Take a look when you have a chance and let me know.
Hi @jsvine, thanks for having a go. I do believe this change is live. And, if so, it does look different. I suppose in Chrome it look better (but still not right) but it also looks not right in Firefox. It does look good in Safari.
Thanks; looks like I didn't test quite enough different pages in quite enough browsers. Have now pushed a tiny tweak that might(?) resolve this.
Great! FF now looks like Safari. And Chrome overflows the text area a bit, but it's perfectly legible.
Great. I'm content to let the "terminal" overflow the text areas if the user has made the decision to set a minimum font size. Open to fixes down the road, but seems like a decent situation for now. Thanks again for flagging.