New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
akalin opened this Issue Aug 27, 2017 · 67 comments

Comments

Projects
None yet
10 participants
@akalin

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

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Aug 27, 2017

Member

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

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

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Aug 27, 2017

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin Aug 27, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin 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.

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.

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Aug 27, 2017

Member

The \sqrt issue is fixed in v0.8.3.

Member

kevinbarabash commented Aug 27, 2017

The \sqrt issue is fixed in v0.8.3.

@akalin

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin commented Aug 27, 2017

Cool, looks like it works: https://rawgit.com/akalin/60e78169d60908f8111652540f427607/raw/d1d9228c76637ffd92b4af1d9fe75075fea15d30/test-0.8.3.html

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

@edemaine

This comment has been minimized.

Show comment
Hide comment
@edemaine

edemaine Aug 28, 2017

Collaborator

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...)

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

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin Aug 28, 2017

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.

screenshot-0 8 3-50

screenshot-0 8 3-67

screenshot-0 8 3-80

screenshot-0 8 3-100

akalin commented Aug 28, 2017

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.

screenshot-0 8 3-50

screenshot-0 8 3-67

screenshot-0 8 3-80

screenshot-0 8 3-100

@akalin

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin 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).

screen shot 2017-08-28 at 12 16 37 pm

screen shot 2017-08-28 at 12 16 41 pm

screen shot 2017-08-28 at 12 16 42 pm

screen shot 2017-08-28 at 12 16 44 pm

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).

screen shot 2017-08-28 at 12 16 37 pm

screen shot 2017-08-28 at 12 16 41 pm

screen shot 2017-08-28 at 12 16 42 pm

screen shot 2017-08-28 at 12 16 44 pm

@akalin

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin 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.

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.

@kevinbarabash kevinbarabash added the bug label Sep 7, 2017

@xsznix

This comment has been minimized.

Show comment
Hide comment
@xsznix

xsznix Sep 7, 2017

Collaborator

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:

screen shot 2017-09-06 at 22 37 04

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

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:

screen shot 2017-09-06 at 22 37 04

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

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Sep 7, 2017

Member

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

Member

kevinbarabash commented Sep 7, 2017

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

@xsznix

This comment has been minimized.

Show comment
Hide comment
@xsznix

xsznix Sep 7, 2017

Collaborator

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:

screen shot 2017-09-07 at 00 10 00

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:

screen shot 2017-09-07 at 00 10 00

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Sep 7, 2017

Member

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?

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?

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Sep 7, 2017

Contributor

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. ;)

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. ;)

@edemaine

This comment has been minimized.

Show comment
Hide comment
@edemaine

edemaine Sep 7, 2017

Collaborator

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

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?

@edemaine

This comment has been minimized.

Show comment
Hide comment
@edemaine

edemaine Sep 7, 2017

Collaborator

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?

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?

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Sep 7, 2017

Contributor

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.

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.

@edemaine

This comment has been minimized.

Show comment
Hide comment
@edemaine

edemaine Sep 7, 2017

Collaborator

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?

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?

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Sep 7, 2017

Contributor

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

image

Contributor

sophiebits commented Sep 7, 2017

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

image

@akalin

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin Sep 7, 2017

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

akalin commented Sep 7, 2017

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

@xsznix

This comment has been minimized.

Show comment
Hide comment
@xsznix

xsznix Sep 7, 2017

Collaborator

@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

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.

@edemaine

This comment has been minimized.

Show comment
Hide comment
@edemaine

edemaine Sep 8, 2017

Collaborator

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)

Collaborator

edemaine commented Sep 8, 2017

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)

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Sep 8, 2017

Contributor

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

Contributor

sophiebits commented Sep 8, 2017

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

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Sep 16, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@mbourne

mbourne 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:

image

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.

image

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.

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:

image

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.

image

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.

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Sep 27, 2017

Member

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
screen shot 2017-09-26 at 11 06 36 pm

pdflatex:
screen shot 2017-09-26 at 11 06 24 pm

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
screen shot 2017-09-26 at 11 06 36 pm

pdflatex:
screen shot 2017-09-26 at 11 06 24 pm

@mbourne

This comment has been minimized.

Show comment
Hide comment
@mbourne

mbourne Nov 12, 2017

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

mbourne commented Nov 12, 2017

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

@kkiningh

This comment has been minimized.

Show comment
Hide comment
@kkiningh

kkiningh 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).

screen shot 2017-11-13 at 12 41 19 pm

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).

screen shot 2017-11-13 at 12 41 19 pm

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Nov 18, 2017

Collaborator

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.

Collaborator

ronkok commented Nov 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin 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?

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?

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Nov 18, 2017

Collaborator

@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.

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.

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Nov 23, 2017

Member

@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.

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

This comment has been minimized.

Show comment
Hide comment
@akalin

akalin 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:
screen shot 2017-11-27 at 11 28 30 pm

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:
screen shot 2017-11-27 at 11 28 30 pm

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Nov 29, 2017

Collaborator

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?

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?

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Nov 29, 2017

Member

screen shot 2017-11-28 at 9 49 40 pm

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.

Member

kevinbarabash commented Nov 29, 2017

screen shot 2017-11-28 at 9 49 40 pm

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.

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Nov 29, 2017

Collaborator

@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

@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.

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Nov 29, 2017

Collaborator

@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.

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.

@akalin

This comment has been minimized.

Show comment
Hide comment
@akalin

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!

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Jan 15, 2018

Collaborator

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

Collaborator

ronkok commented Jan 15, 2018

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

@kevinbarabash

This comment has been minimized.

Show comment
Hide comment
@kevinbarabash

kevinbarabash Jan 15, 2018

Member

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

Member

kevinbarabash commented Jan 15, 2018

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

@jeffmcmahan

This comment has been minimized.

Show comment
Hide comment
@jeffmcmahan

jeffmcmahan 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.

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.

@edemaine

This comment has been minimized.

Show comment
Hide comment
@edemaine

edemaine Apr 5, 2018

Collaborator

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

Collaborator

edemaine commented Apr 5, 2018

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

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Apr 5, 2018

Collaborator

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

Collaborator

ronkok commented Apr 5, 2018

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

@jeffmcmahan

This comment has been minimized.

Show comment
Hide comment
@jeffmcmahan

jeffmcmahan Apr 5, 2018

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

jeffmcmahan commented Apr 5, 2018

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

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Apr 5, 2018

Collaborator

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.

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

This comment has been minimized.

Show comment
Hide comment
@jeffmcmahan

jeffmcmahan Apr 5, 2018

@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):

Screen Shot 2018 04 05 at 1 46 06 PM

LaTeX: p = 1 - \bigg(\frac{1}{1.8 \times 10^9}\bigg)^{5 \times 10^8}

Here's the HTML that katex.renderToString() produces:

<span class="katex-display"><span class="katex"><span class="katex-mathml"><math><semantics><mrow><mi>p</mi><mo>=</mo><mn>1</mn><mo>−</mo><mo fence="false">(</mo><mfrac><mrow><mn>1</mn></mrow><mrow><mn>1</mn><mi mathvariant="normal">.</mi><mn>8</mn><mo>×</mo><mn>1</mn><msup><mn>0</mn><mn>9</mn></msup></mrow></mfrac><msup><mo fence="false">)</mo><mrow><mn>5</mn><mo>×</mo><mn>1</mn><msup><mn>0</mn><mn>8</mn></msup></mrow></msup></mrow><annotation encoding="application/x-tex">p = 1 - bigg(frac{1}{1.8 times 10^9}bigg)^{5 times 10^8}</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="strut" style="height:1.82682em;"></span><span class="strut bottom" style="height:2.77685em;vertical-align:-0.95003em;"></span><span class="base"><span class="mord mathit">p</span><span class="mord rule" style="margin-right:0.2777777777777778em;"></span><span class="mrel">=</span><span class="mord rule" style="margin-right:0.2777777777777778em;"></span><span class="mord">1</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mbin">−</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mord"><span class="delimsizing size3">(</span></span><span class="mord"><span class="mopen nulldelimiter"></span><span class="mfrac"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:1.32144em;"><span style="top:-2.314em;"><span class="pstrut" style="height:3em;"></span><span class="mord"><span class="mord">1</span><span class="mord">.</span><span class="mord">8</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mbin">×</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mord">1</span><span class="mord"><span class="mord">0</span><span class="msupsub"><span class="vlist-t"><span class="vlist-r"><span class="vlist" style="height:0.740108em;"><span style="top:-2.9890000000000003em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mtight">9</span></span></span></span></span></span></span></span></span></span><span style="top:-3.15em;"><span class="pstrut" style="height:3em;"></span><span class="stretchy" style="height:0.2em;"><svg width="400em" height="0.2em" viewBox="0preserveAspectRatio=" xminyminslice'=""><path d="M0H400000v40H0zM0H400000v40H0z"></path></svg></span></span><span style="top:-3.677em;"><span class="pstrut" style="height:3em;"></span><span class="mord"><span class="mord">1</span></span></span></span><span class="vlist-s">&#8203;</span></span><span class="vlist-r"><span class="vlist" style="height:0.7693300000000001em;"></span></span></span></span><span class="mclose nulldelimiter"></span></span><span class="mord"><span class="mord"><span class="delimsizing size3">)</span></span><span class="msupsub"><span class="vlist-t"><span class="vlist-r"><span class="vlist" style="height:1.82682em;"><span style="top:-3.9029000000000003em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mtight"><span class="mord mtight">5</span><span class="mbin mtight">×</span><span class="mord mtight">1</span><span class="mord mtight"><span class="mord mtight">0</span><span class="msupsub"><span class="vlist-t"><span class="vlist-r"><span class="vlist" style="height:0.8913142857142857em;"><span style="top:-2.931em;margin-right:0.07142857142857144em;"><span class="pstrut" style="height:2.5em;"></span><span class="sizing reset-size3 size1 mtight"><span class="mord mtight">8</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span>

If you need a live page, I can probably put one up this weekend.

jeffmcmahan commented Apr 5, 2018

@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):

Screen Shot 2018 04 05 at 1 46 06 PM

LaTeX: p = 1 - \bigg(\frac{1}{1.8 \times 10^9}\bigg)^{5 \times 10^8}

Here's the HTML that katex.renderToString() produces:

<span class="katex-display"><span class="katex"><span class="katex-mathml"><math><semantics><mrow><mi>p</mi><mo>=</mo><mn>1</mn><mo>−</mo><mo fence="false">(</mo><mfrac><mrow><mn>1</mn></mrow><mrow><mn>1</mn><mi mathvariant="normal">.</mi><mn>8</mn><mo>×</mo><mn>1</mn><msup><mn>0</mn><mn>9</mn></msup></mrow></mfrac><msup><mo fence="false">)</mo><mrow><mn>5</mn><mo>×</mo><mn>1</mn><msup><mn>0</mn><mn>8</mn></msup></mrow></msup></mrow><annotation encoding="application/x-tex">p = 1 - bigg(frac{1}{1.8 times 10^9}bigg)^{5 times 10^8}</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="strut" style="height:1.82682em;"></span><span class="strut bottom" style="height:2.77685em;vertical-align:-0.95003em;"></span><span class="base"><span class="mord mathit">p</span><span class="mord rule" style="margin-right:0.2777777777777778em;"></span><span class="mrel">=</span><span class="mord rule" style="margin-right:0.2777777777777778em;"></span><span class="mord">1</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mbin">−</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mord"><span class="delimsizing size3">(</span></span><span class="mord"><span class="mopen nulldelimiter"></span><span class="mfrac"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:1.32144em;"><span style="top:-2.314em;"><span class="pstrut" style="height:3em;"></span><span class="mord"><span class="mord">1</span><span class="mord">.</span><span class="mord">8</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mbin">×</span><span class="mord rule" style="margin-right:0.2222222222222222em;"></span><span class="mord">1</span><span class="mord"><span class="mord">0</span><span class="msupsub"><span class="vlist-t"><span class="vlist-r"><span class="vlist" style="height:0.740108em;"><span style="top:-2.9890000000000003em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mtight">9</span></span></span></span></span></span></span></span></span></span><span style="top:-3.15em;"><span class="pstrut" style="height:3em;"></span><span class="stretchy" style="height:0.2em;"><svg width="400em" height="0.2em" viewBox="0preserveAspectRatio=" xminyminslice'=""><path d="M0H400000v40H0zM0H400000v40H0z"></path></svg></span></span><span style="top:-3.677em;"><span class="pstrut" style="height:3em;"></span><span class="mord"><span class="mord">1</span></span></span></span><span class="vlist-s">&#8203;</span></span><span class="vlist-r"><span class="vlist" style="height:0.7693300000000001em;"></span></span></span></span><span class="mclose nulldelimiter"></span></span><span class="mord"><span class="mord"><span class="delimsizing size3">)</span></span><span class="msupsub"><span class="vlist-t"><span class="vlist-r"><span class="vlist" style="height:1.82682em;"><span style="top:-3.9029000000000003em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mtight"><span class="mord mtight">5</span><span class="mbin mtight">×</span><span class="mord mtight">1</span><span class="mord mtight"><span class="mord mtight">0</span><span class="msupsub"><span class="vlist-t"><span class="vlist-r"><span class="vlist" style="height:0.8913142857142857em;"><span style="top:-2.931em;margin-right:0.07142857142857144em;"><span class="pstrut" style="height:2.5em;"></span><span class="sizing reset-size3 size1 mtight"><span class="mord mtight">8</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span>

If you need a live page, I can probably put one up this weekend.

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Apr 5, 2018

Collaborator

@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

ronkok commented Apr 5, 2018

@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.

@edemaine

This comment has been minimized.

Show comment
Hide comment
@edemaine

edemaine Apr 5, 2018

Collaborator

Maybe you're sanitizing the HTML and removing <svg> tags (or some of the subtags)? I had this issue when switching to 0.8. This reliance will be removed in #1249, but only for frac lines; you should whjte-list SVG tags for other features like \overrightarrow.

Collaborator

edemaine commented Apr 5, 2018

Maybe you're sanitizing the HTML and removing <svg> tags (or some of the subtags)? I had this issue when switching to 0.8. This reliance will be removed in #1249, but only for frac lines; you should whjte-list SVG tags for other features like \overrightarrow.

@ronkok

This comment has been minimized.

Show comment
Hide comment
@ronkok

ronkok Apr 5, 2018

Collaborator

Right. You should white-list <SVG>, <path>, and <line>.

Collaborator

ronkok commented Apr 5, 2018

Right. You should white-list <SVG>, <path>, and <line>.

@jeffmcmahan

This comment has been minimized.

Show comment
Hide comment
@jeffmcmahan

jeffmcmahan Apr 5, 2018

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

jeffmcmahan commented Apr 5, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment