search

KaTeX / KaTeX

Fast math typesetting for the web.
https://katex.org
MIT License
18.42k stars 1.18k forks source link

Zoom levels stopping KaTeX/LaTeX fractions rendering correctly #2491

Open AEadie opened 4 years ago

AEadie commented 4 years ago

Hi, I am new to GitHub and coding generally, so thank you in advance for the assistance.

Describe the bug: I am building a maths education website that uses LaTeX code heavily. For some unknown reason, all sections of the site have suddenly stopped showing the thin horizontal dividing line in fractions at 100% or 110% browser zoom levels on my PC. What's particularly strange is that at 90% zoom or below, or 125% zoom and above, the fraction lines appear as normal. This issue seems to apply to Chrome and Microsoft browsers, but not Opera. On my Mac or on mobile there are no issues at any zoom levels, however my friend's Mac experiences the same issue at 125% zoom on Chrome. We have not updated KaTeX or any other plugin - there appears to be no cause for this to suddenly become an issue today.

(La)TeX code: Not relevant (I believe), just standard fractions.

Screenshots: 90% zoom on PC (renders correctly): image

100% zoom on PC (fraction lines disappear):
image

Environment:

Many thanks!

edemaine commented 4 years ago

I've been noticing this some lately too (on Chrome 85.0.4183.102 for Windows) -- perhaps a recent change to how Chrome implements zoom? 🙁

ylemkimon commented 4 years ago

@AEadie @edemaine Could you let me know the version of Chrome?

Also, could you try the following two versions and compare results? Windows x64 https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Win_x64%2F770054%2Fchrome-win.zip?generation=1589885407916667&alt=media https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Win_x64%2F770069%2Fchrome-win.zip?generation=1589887462069918&alt=media

Linux x64 https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F770063%2Fchrome-linux.zip?generation=1589884575809384&alt=media https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F770066%2Fchrome-linux.zip?generation=1589885298841462&alt=media

Mac https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Mac%2F770054%2Fchrome-mac.zip?generation=1589884445116614&alt=media https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Mac%2F770066%2Fchrome-mac.zip?generation=1589887195180812&alt=media

ylemkimon commented 4 years ago

The culprit seems to be https://chromium.googlesource.com/chromium/src/+/d1b0fc8e45dcbe00e9060a3dba87c398425ae178, which changed rendering of the subpixel border.

/cc @ronkok

ronkok commented 4 years ago

I had the same thing happen to me after a recent chromium update. For my own site, I changed the KaTeX rendering options to include minRuleThickness: 0.06 and then I could once again see fraction lines.

As long as we keep the default rule thickness to match the LaTeX value of 0.04em, I can think no other solution. Now I personally would have no problem increasing that default value, but I suspect others here would like to avoid a default that is contrary to LaTeX.

We have already tried several forlorn hopes with different CSS attributes and all of them had drawbacks. So we created the minRuleThickness option to overcome exactly this problem. That's the only other solution I can think of.

kevinbarabash commented 4 years ago

I did some testing using \sqrt{\frac{1+x}{y}} and noticed that the behavior of the \sqrt's rule was great. It never disappeared and it didn't get super blocky like the fraction bar does when zoomed out really far. What if we use SVG for the fraction bar? We should do the same for \underline and \overline which suffer from the same issue.

Screen Shot 2020-09-10 at 9 23 07 PM Screen Shot 2020-09-10 at 9 23 02 PM Screen Shot 2020-09-10 at 9 22 59 PM Screen Shot 2020-09-10 at 9 22 51 PM Screen Shot 2020-09-10 at 9 22 48 PM Screen Shot 2020-09-10 at 9 22 45 PM Screen Shot 2020-09-10 at 9 22 41 PM Screen Shot 2020-09-10 at 9 22 38 PM Screen Shot 2020-09-10 at 9 22 35 PM Screen Shot 2020-09-10 at 9 22 30 PM Screen Shot 2020-09-10 at 9 22 26 PM Screen Shot 2020-09-10 at 9 22 21 PM
ronkok commented 4 years ago

We tried an SVG once before. It is subject to anti-aliasing and some people reported fuzzy edges or thick grey lines. I'm glad that the radical line worked on your screen, but this problem seems to be very dependent on hardware and we cannot expect that one sample will be representative of what all people see.

I believe that the fewest number of complaints, until this latest Chrome change, has come from lines that are made of span borders, not SVGs. Span borders are not subject to fuzzy edges. But 0.04 em is just too thin.

kevinbarabash commented 4 years ago

I forgot about that. The \sqrt must have the same issue then. I guess isn't used as much though. Also, the screenshots I took were on a high-res display and so the fuzziness isn't as much of an issue there.

edemaine commented 4 years ago

I'd personally prefer a fuzzy / grey / antialiased line over a nonexistent line... so SVG seems superior than Chrome's current behavior.

kevinbarabash commented 4 years ago

Maybe we could provide that as an option and then people could choose between using SVG or setting minRuleThickness.

ylemkimon commented 4 years ago

I think we can use CSS max, max(0.04em, 1px) ~I'll prepare a PR.~ What do you think?

edemaine commented 4 years ago

Reading through https://www.w3.org/Style/Examples/007/units.en.html it does seem like 1px is a safe choice, so maybe the max is a good idea (though I imagine 1px will usually be larger). The same site points out some media queries about display resolution that might let us choose more accurate values when on a high-dpi display.

ronkok commented 4 years ago

KaTeX CSS already includes

// Prevent Chrome from disappearing frac-lines, rules, etc.
.mfrac .frac-line,
.overline .overline-line,
.underline .underline-line,
.hline,
.hdashline,
.rule {
    min-height: 1px;
}

It will be interesting to see if a CSS max performs any better.

edemaine commented 4 years ago

I don't think min-height would affect the border-bottom-width attribute, which is currently 0.04em. This would work if we were using SVG .frac-lines though?

AEadie commented 4 years ago

Do we think any of this explains why the situation has changed from one day to the next though? I've always been on 100% zoom up till now and fractions have rendered perfectly. Must be some background update that's gone on with chrome?

AEadie commented 4 years ago

Thank you all so much for your input by the way

edemaine commented 4 years ago

Yes, see https://github.com/KaTeX/KaTeX/issues/2491#issuecomment-690758903

pcbouman-eur commented 4 years ago

Not sure if this helps, but my colleagues also observed this issue while using software that uses KaTeX. After some experimeting, it seems that not only Chrome's zoom level affects this, but that it also depends on the high-DPI scaling and font-scaling settings of Windows, together with the zoom level of Chrome. For example, I had a colleague with 125% high-DPI scaling on his laptop who could not see fraction lines at 100% zoom in Chrome. For myself, with 100% high-DPI scaling and default font-scaling, I was not able to reproduce the issue, but after increasing font-scaling I was also able to make the fraction lines disappear at some zoom levels in Chrome (although not at 100%). Repeating the font-scaling experiment on Firefox, everything worked fine at different zoom levels. Indeed it seems these are caused by some complex rendering/rounding issues in Chrome. The weird thing is that in the rendered DOM, the fraction line had a min-height: 1px attribute, so it seemed pretty weird that Chrome did not show it.

kevinbarabash commented 4 years ago

I filed a Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1131046.

mrego commented 4 years ago

https://chromium-review.googlesource.com/c/chromium/src/+/2426423

Yes this is a Chrome bug. It happens with certain zoom levels, or scaling factors. It has been fixed in Chromium 87.

As a workaround you might try to change border-bottom-width to 1px instead of 0.04em.

ylemkimon commented 4 years ago

This will be fixed in Chrome 86. Thank you to the Chromium team for merging the fix into M-86. The question is whether we should release a temporary fix for Chrome 85 users?

ibrahima commented 4 years ago

Hmm, it looks like the issue was mostly fixed in Chrome 86, but I am still seeing issues with some thin lines (e.g. overlines) in Chrome 87 at particular zoom levels - 50% and 80%, for example. Can anyone else confirm? Thanks!

kevinbarabash commented 3 years ago

@ibrahima I wasn't able to repro the issue with \overline{123} in Version 87.0.4280.88 (Official Build) (x86_64).

BrandiATMuhkuh commented 3 years ago

We still see this issue on Version 87.0.4280.88 (Official Build) (x86_64). So far only on the following resoltion: 1920 x 1080 with Windows Scaling set to 125%

When I try it on 4k it works on all zoom levels.

kevinbarabash commented 3 years ago

I tried to reproduce the issue using BrowserStack, but the free account I have only provides access to Chrome 86. 😞

FischLu commented 3 years ago

Is there any planning for solving the issue? It is really annoying. At least till now, I still have this problem on Windows..

MarcoBuster commented 3 years ago

Any updates on this? I use Joplin and I'm affected (Linux)

ylemkimon commented 3 years ago

@BrandiATMuhkuh @FischLu @MarcoBuster try setting minRuleThickness: 0.06 or bigger.