# Dividing lines for \frac and overhead lines for \sqrt sometimes disappear #824

Closed
opened this Issue Aug 27, 2017 · 67 comments

Projects
None yet
10 participants

### akalin commented Aug 27, 2017

 When trying to upgrade to 0.8.x, I noticed that it sometimes omitted the dividing lines for \frac and the overhead lines for \sqrt. Here's a test file showing the problem (for dividing lines): https://rawgit.com/akalin/60e78169d60908f8111652540f427607/raw/f53ae1650b12bf6db46b264e8852ded3d82ca7e7/test-0.8.2.html At default zoom, the dividing line for the \fracs in the 2nd expression isn't visible, and if you zoom in and out, you can make one or more of the lines disappear. Here's the same file using 0.7.1: https://rawgit.com/akalin/60e78169d60908f8111652540f427607/raw/f53ae1650b12bf6db46b264e8852ded3d82ca7e7/test-0.7.1.html If you zoom out far enough, the lines do disappear, but it seems somehow more robust then 0.8.x. I suspect that the problem isn't unique to 0.8.x, but the change in rendering the superscripts exposed it. Gist for the test file using other versions: https://gist.github.com/akalin/60e78169d60908f8111652540f427607
Member

### kevinbarabash commented Aug 27, 2017

 Fixed in #810. See #799. I'm going to leave this issue open until we publish a new version with the fix.
Member

### kevinbarabash commented Aug 27, 2017

 I should mention that the #810 does not fix the fraction bar issue. I have not been able to reproduce either issue. @akalin what browser and OS versions are you using?

### akalin commented Aug 27, 2017 • edited

 I'm using Chrome Version 62.0.3192.0 (Official Build) dev (64-bit) on Linux and macOS. Just tried Safari 10.1.2 and Firefox 55.0.3 and it works fine there. So it might be a Chrome-only issue, or even a dev-channel-only issue. Also works fine on Chrome Version 60.0.3112.101 (Official Build) (64-bit) and Version 60.0.3112.113 (Official Build) (64-bit) on Windows. Looks like I forgot to switch to the dev channel on this machine -- let me try beta and then dev...

### akalin commented Aug 27, 2017

 On Windows, works fine for Version 61.0.3163.59 (Official Build) beta (64-bit) but not Version 62.0.3192.0 (Official Build) dev (64-bit). So it looks like a dev-channel-only issue.
Member

### kevinbarabash commented Aug 27, 2017

 The \sqrt issue is fixed in v0.8.3.

### akalin commented Aug 27, 2017

 Now it's just the missing fraction bar that's the problem.
Collaborator

### edemaine commented Aug 28, 2017

 Given our inability to reproduce, can you include a screenshot? Any idea what changes are in Chrome dev-channel that might cause a change here? Perhaps the rounding rules for subpixel resolution are changing? (That would be unfortunate...)

### akalin commented Aug 28, 2017 • edited

 Okay, here are some screenshots at various zoom levels with KaTeX 0.8.3 on macOS Chrome Version 62.0.3192.0 (Official Build) dev (64-bit). 90% and 75% zoom were ok.

### akalin commented Aug 28, 2017

 Here are some more screenshots with KaTeX 0.7.1 on macOS Chrome Version 62.0.3192.0 (Official Build) dev (64-bit).

### akalin commented Aug 28, 2017

 Also, when testing with Firefox 55.0.3 on macOS, I noticed that the sqrt overlines disappear at 30% zoom with 0.8.3, but work fine with 0.7.1, so unfortunately it seems like that isn't fully fixed yet, either.

Collaborator

### xsznix commented Sep 7, 2017

 Ah, I've run into the same issue on the version of KaTeX (0.8.1-ish, IIRC) that's currently on Messenger, even at default zoom: It seems to be slightly evasive, and I'd help except I can't for the life of me figure out how to change the appearance of the sqrt-line…
Member

### kevinbarabash commented Sep 7, 2017

 @xsznix what happens if you put the \sqrt in the denominator or have it outside of the fraction?
Collaborator

### xsznix commented Sep 7, 2017

 Outside a fraction, $$\sqrt{b^2-4ac}$$ renders at first but if I scroll it out of view and then back it disappears. In the denominator it seems fine:
Member

### kevinbarabash commented Sep 7, 2017

 It looks like the 2 is clipped. My guess is that the container that the math is being rendered into is too small. @sophiebits what's a good way to report issues to the Messenger team?
Contributor

### sophiebits commented Sep 7, 2017

 There's no good way for non-employees to reliably report bugs and get a response. CCing me here is fine. If someone wants to suggest a particular CSS change to Messenger that would be even better. ;)
Collaborator

### edemaine commented Sep 7, 2017 • edited

 I don't think this is particular to Messenger. But no one has been able to track down the problem source or solution yet... It doesn't help that most of us can't reproduce the problem. My current suspicion is that this has to do with display DPI or something along those lines, so it's hard to reproduce. @xsznix and anyone else who can reproduce, could you let us know your screen resolution, DPI, browser, OS?
Collaborator

### edemaine commented Sep 7, 2017

 Oops, sorry, reading more thoroughly, it does look like the container issue is particular to Messenger. And I can reproduce it! I just took a quick look, and Messenger CSS has overflow-x: auto; overflow-y: hidden set. Removing both of these fixes the clipping. Is there a security or other concern that causes you to include those?
Contributor

### sophiebits commented Sep 7, 2017

 I blame @xsznix who wrote that code in Messenger this summer. :) It's designed to limit the width of expressions so you can scroll if they get too wide.
Collaborator

### edemaine commented Sep 7, 2017

 The main problem, I guess, is that the bounding box is somehow getting set wrong. Because we don't normally limit overflow, we don't see this. The strange thing is that I can't reproduce it in another KaTeX environment (like make serve), though the relevant CSS seems identical. A simple example is a^2+b^2=c^2. Looking at the inspector, the vlist-t containing the first superscript has a bounding box that is not tall enough. But somehow the containing msupsub extends the top of the box to a good place in make serve, but not in Messenger, despite no apparent CSS to do so... Perhaps someone familiar with vlist can understand this?
Contributor

### sophiebits commented Sep 7, 2017

 On the KaTeX site, I can repro a^{2^2} going outside the bounding box…

### akalin commented Sep 7, 2017

 Are these the same bug or two separate bugs? Perhaps we should split the issues...
Collaborator

### xsznix commented Sep 7, 2017

 @edemaine I'm on Chrome 60, macOS 10.12.6, and the issue occurs at both 1x and 2x DPI scaling. @sophiebits Adding #facebook ._1e4d._3_3l .katex-display {padding: 1px 0} seems to fix clipping on both the sqrt line and the nested superscript. Possibly worth sending over to the Messenger team? It's probably not the optimal solution but it sounds much easier than fiddling with vlists.
Collaborator

### edemaine commented Sep 8, 2017 • edited

 The fact that 1px of padding is enough suggests this has something to do with rounding? Perhaps related to this issue... I'd be curious to know if it's possible to get more than 1px error. Maybe we should have a general rule of .katex { padding: 1px 0px}? The issue might be Chrome's unique lack of subpixel behavior within tables, because vlists use table formatting (since #768 which briefly discussed this issue). While I don't see why yet, perhaps the two "different" issues are stemming from the same problem... (though I still haven't seen disappearing fraction lines at any scale)
Contributor

### sophiebits commented Sep 8, 2017

 We opted to add the 1px padding to Messenger for now. Reload and you should see it.

Member

### kevinbarabash commented Sep 16, 2017

 In #312, @xymostech pointed out that we make our fonts thicker and so our font metrics should be adjusted. Fixing this may address the core of the problem. The downside of fixing the metrics is that it will probably make our output deviate more for LaTeX's output.

### mbourne commented Sep 27, 2017

 I'm also facing the disappearing fraction lines issue, inconsistent across browser versions and even within a document. Browser: Chrome Version 61.0.3163.100 (Official Build) (64-bit) OS: Win7 KaTEX version: 0.8.3 Example page: https://www.intmath.com/forum/applications-integration-30/a-simple-integration:140#pid845 One of the fractions in the last forum entry of that page looks like this: However, a bit higher up the page, the fraction line is fine but the generated code is identical, and there are no differences in the style for any of the surrounding divs. I can't find any reason why they render differently (it's not because of the equal sign). My default font size for class .katex is 1.15 em, which gives me a resulting 18.4px font (which does show the problem). If I set .katex at exactly 18px, it's fine, but at 18.1px, the line doesn't show, nor at exactly 18.4px. At other nearby values, the result is: 17.8px: fails 17.9px: fails 18.01px, 18.02px, 18.03px: shows 18.04px: fails 18.2px: shows 18.3px: shows 18.5px: shows On the other hand: Browser: Chrome: Version 60.0.3112.113 (Official Build) (64-bit) OS: Win 10 The fraction lines are all fine in this combination.
Member

### kevinbarabash commented Sep 27, 2017

 Both of the screenshots below were taken on a retina screen. Even though the sizes of the images are different the relative width of the fraction bar compared to the width of the lines in the equal sign should be the same. It looks like the KaTeX rendering of the fraction bar is not as thick as it should be. khan.github.io/KaTeX pdflatex:

### mbourne commented Nov 12, 2017

 @kevinbarabash No I hadn't, and indeed it does!

### kkiningh commented Nov 13, 2017

 I'm using 0.9.0-alpha1 and I think I'm still seeing this issue. See the attached screenshot (100% zoom in Chrome on 15" Macbook Pro).
Collaborator

### ronkok commented Nov 18, 2017 • edited

 Okay, I think I have a plan. We need to change frac-line so that it no longer consists of a bottom-border but instead consists of an entire span, the way \rule works. Then the min-height from PR #931 should act more dependably. There is no such thing as a CSS border-min-thickness. @kevinbarabash If you are planning a bug-fix release, give me a day or two. I'm booked up today, but I think I can turn in a PR by tomorrow evening.

### akalin commented Nov 18, 2017

 I've noticed that sometimes vertical lines can also disappear, e.g. the vertical divider in an array environment with [c|c]. I'll file a separate bug with a repro case, but do you think that could also be from the same root cause?
Collaborator

### ronkok commented Nov 18, 2017

 @akalin Well, the CSS for arraycolsep also works via a span border. I suppose that the same problem could be occurring and that the same adjustment methods could apply. I'd like to take one thing at a time. If we can get frac-line working dependably, then I'll look at arraycolsep.

Closed

Merged

Member

### kevinbarabash commented Nov 23, 2017

 @ronkok sounds good. I was looking to do an v0.9.0-alpha2 release sometime this weekend. Also, switching from bottom-border to span height and using min-height sounds like a good plan.

### akalin commented Nov 28, 2017

 I hate to say it, but it looks like 0.9.0-alpha2 regresses. :( See https://rawgit.com/akalin/60e78169d60908f8111652540f427607/raw/fd7f91f08774a70185c003b8b29f144fb4b65d52/test-0.9.0-alpha2.html , which looks like this to me:
Collaborator

### ronkok commented Nov 29, 2017

 Well, that's discouraging. We've had a couple other reports that 0.9.0-alpha2 provided some benefit. I myself have not had any lines disappear on my screen, but I have seen two that are narrower than they were before 0.9.0-alpha2. So returns are mixed. @kevinbarabash I think it is time for a belt-and-suspenders approach. Both a border and a full-height span colored by an SVG. They can coexist if I set CSS box-sizing: border-box; for frac-line. What do you think?
Member

### kevinbarabash commented Nov 29, 2017

 The above rendering is from Safari. The height for each of the fraction lines is the same, the problem (I think), is that we're control the height the fraction line using the enclosing span. My guess is that the browser tries to quantize the span to some grid and ends up rounding up/down depending on where it lands. @ronkok maybe we could render a SVG line of the correct thickness within the SVG and then make the enclosing span a bit taller than it needs to be. Also, the line shouldn't be right near the edge of the SVG. That should avoid the quantization/clipping the we're seeing currently.
Collaborator

### ronkok commented Nov 29, 2017 • edited

 @kevinbarabash Your proposal makes a lot of sense. When I was working on PR #670, I found that I had much finer control over SVG geometry than I did over span geometry. Of course, this means that we'll have to write SVG path geometry on the fly instead of just using overflow: hidden; to control line thickness. There might be a tiny performance hit. Correction: we just need to make a \mathchoice between three pre-written paths. That's quicker. I'll write up a PR. This may take a few days. I'm semi-retired these days and I often have some free time but at present I'm spending a lot of time at the office.
Collaborator

### ronkok commented Nov 29, 2017

 @akalin If we follow through on @kevinbarabash's proposal, we'll have frac-lines that act like the top lines in square root radicals (as of release 0.8.3). If you see any of those disappear, please let me know.

Closed

### akalin commented Jan 15, 2018

 0.9.0-beta seems to have completely fixed the problem for me: https://rawgit.com/akalin/60e78169d60908f8111652540f427607/raw/dddea153264adabe863e3a4f6c24c4cd220996dd/test-0.9.0-beta.html Thanks everyone!
Collaborator

### ronkok commented Jan 15, 2018

 @akalin, You're very welcome. I hope that everyone has results this positive.

Member

### kevinbarabash commented Jan 15, 2018

 @akalin thanks for verifying that the bug is no longer in the new release.

Closed

### jeffmcmahan commented Apr 5, 2018

 When using katex.renderToString(), fraction lines are not appearing. I'm using the following LaTeX expression: p = \frac{1}{1.8} (properly escaped). In Chrome 65: npm install katex@0.7 -> lines appear npm install katex@0.8 -> no lines npm install katex@0.9 -> no lines In FireFox 59: npm install katex@0.7 -> lines appear npm install katex@0.8 -> lines appear npm install katex@0.9 -> no lines ... Using the correct CSS file in each case. Same results whether in display mode or not.
Collaborator

### edemaine commented Apr 5, 2018

 @jeffmcmahan #1249 will hopefully fix this. There's a test page on #1173 that you can check out.
Collaborator

### ronkok commented Apr 5, 2018

 Query about npm: When one writes npm install katex@0.9, which KaTeX version will that install?

### jeffmcmahan commented Apr 5, 2018 • edited

 @edemaine - Thanks! @ronkok - 0.9.0 until a newer patch version is published to npm. (@0.7 installs 0.7.1.)
Collaborator

### ronkok commented Apr 5, 2018

 If the version is 0.9.0, then something quite odd is happening. In that version, we've gotten reports of frac-lines appearing grey, as in issue #1173, but it should not have an altogether missing line. @jeffmcmahan If you can point me to a page, I can take a look.

### jeffmcmahan commented Apr 5, 2018 • edited

 @ronkok - is a live page essential? I don't have a node server up that I can easily use to post a demo page. Here is a screenshot generated with 0.9.0 installed (using the provided 0.9.0 stylesheet as well): LaTeX: p = 1 - \bigg(\frac{1}{1.8 \times 10^9}\bigg)^{5 \times 10^8} Here's the HTML that katex.renderToString() produces: $p=1(11.8×109)5×108p = 1 - bigg(frac{1}{1.8 times 10^9}bigg)^{5 times 10^8}$ If you need a live page, I can probably put one up this weekend.
Collaborator

### ronkok commented Apr 5, 2018 • edited

 @jeffmcmahan Thank you for for providing the HTML. It contains an inline SVG for that frac-line, so it's not clear to me why no frac-line is rendered. If a page were available, I could root around a little for the underlying problem. At the moment, I'm baffled. Does \sqrt render properly? \overrightarrow? They also depend on SVGs.
Collaborator

### edemaine commented Apr 5, 2018

 Maybe you're sanitizing the HTML and removing
Collaborator

### ronkok commented Apr 5, 2018 • edited

 Right. You should white-list

### jeffmcmahan commented Apr 5, 2018

 Yes, you're right. This was all on me. My HTML parser made a booboo. Sorry!

Closed