Support stretchy wide elements. #670

ronkok · 2017-03-28T20:30:13Z

This will fix issue #629 and possibly #529. Currently, Chrome will fail to render the arrow in \vec when CSS contains text-rendering: optimizeLegibility;.

khanbot · 2017-03-28T20:30:21Z

CLA signature looks good 👍

ronkok · 2017-04-04T21:14:02Z

I have resolved all the lint errors. The error messages I'm getting now are, to me, cryptic. Any help would be appreciated.

sthoch · 2017-04-05T16:01:54Z

Cool. I feel like the arrows should be a tad thicker, but other than my gut, I have no reference atm.

The errors from here: https://travis-ci.org/Khan/KaTeX/builds/218513949 don't seem cryptic to me. What errors are you refering to?

ronkok · 2017-04-05T16:17:30Z

Yes, I've looked the link you have provided. Yesterday, I cleaned up all the lint errors. The errors that remain start at line 858 of https://travis-ci.org/Khan/KaTeX/builds/218513949#L858. The typical remaining error says something such as:

npm ERR! Linux 4.4.0-51-generic

And though some may find that statement to be very informative, I confess that I find it cryptic.

edemaine · 2017-04-05T16:24:07Z

Can you push your fixes to the lint errors, which will trigger a rerun of travis? Those npm ERR messages are just a summary saying that lint failed, and should disappear once the lint errors are gone.

ronkok · 2017-04-05T16:46:44Z

Well, @edemaine, I've made another commit, titled "Fix lint errors". I hope that qualifies as the "push" that you alluded to. If not, let me know. And I appreciate the help.

ronkok · 2017-04-05T17:19:11Z

Well, that's progress. The lint corrections have passed. Travis now fails on Sreenshotter.

I have had no success running Screenshotter locally. If anyone else would like to try, that would be fine with me.

edemaine · 2017-04-06T13:35:44Z

Hmm. I can run screenshotter, but I couldn't reproduce the error that Travis is getting on your branch. My experience is that screenshotter occasionally fails randomly (on my second try, the Colors test failed), so perhaps if Travis tried again, it would work. (But I don't know how to get Travis to try again, other than another random commit.) Anyway, probably don't need to worry about this automatic check, and instead an actual maintainer should review this PR.

glebm · 2017-04-07T10:26:33Z

src/stretchy.js

+        }
+    } else {
+        // Add color. Use CSS mask, if possible
+        if (maskIsSupported()) {


Currently this will not emit the mask when rendering server-side. It'd be nice to emit the mask, or both, perhaps using @supports somehow.

When I run server.js and view it in http://localhost:7936/, I get the mask when I view it in Chrome, the background-image when I view it in Firefox, and the inline background-image when I view it in Edge. That's the same behavior I get when I view the web page.

I completely agree that we want a server side rendering to emit the mask, but my experience is that we already get that. Am I doing something wrong?

The examples you describe both involve a web browser, a.k.a. a client. The point is that, if you run KaTeX from Node, it won't "support" mask, and so won't be omitted. You simply can't detect support for anything in a server-only environment. Can't you emit the mask in all cases, and it will just work when it's supported?

To always emit the mask for SSR, you could do something like:

function maskIsSupported() { // If rendering server-side, assume the client supports CSS masks, // as most clients do: if (typeof document === "undefined") return true; ... }

@edemaine , I can omit the mask in all cases, but the non-mask solution relies on a XMLHttpRequest, which is slow.

@glebm, I would agree with your suggestion. If I interpret caniuse correctly, the upcoming version of Firefox will change from partial mask support to full support. That would leave behind only IE and Edge. However, I'm not sure that the KaTeX owners would agree with you and me. If Edge does look at the output from such a server-side installation, it will render a span-wide blob of color instead of the subject matter.

So I thank both of you for the education on server-side behavior. This affects not just \color but also \cancel, another case where I have different code for IE and Edge.

Regarding \cancel, I'm going to use background-image SVGs for server-side rendering, just as I use it now for IE and Edge. The only drawback of the SVGs in most browsers is that the line does not get thicker when giant fonts sizes are employed. A 1 px line looks good in most common font sizes, so that is a good fall-back.

On the subject of \color, I need some guidance from the KaTeX owners as to what they will accept. The options are:

Do not support \color.

Support \color by a (slow) XMLHttpRequest in all cases.

Use mask when it is supported. Use mask for server-side installations even
though Edge will not render it properly.

Use mask when I can use feature detection to verify that it is supported. Use a XMLHttpRequest for all server-side installations.

If there isn't a good one-size-fits-all solution, it seems like the best thing to do would be to add an option that lets you decide between "work on Edge" vs. "work fast", when you can't autodetect it.

I'm a little confused why you need an XMLHttpRequest, though. Is it not worth just inlining the SVG into the JavaScript code (const mySVG = "...") and using that as needed? I remember we discussed this before, but why use external files at all, when you can embed it all in the JavaScript source?

That's a very good point. Since our conversation, I've added some SVG files. The tactic of making composite images via CSS was giving some poor rendering issues. So the SVG code is now 32 KB. Say about 40 KB once I add the URL escape codes. By inlining that into the JavaScript, we could eliminate all XMLHttpRequest's. So now we can add option:

Add 40 KB of SVG code inline in the JavaScript. No XMLHttpRequest, ever.

I still need some guidance from KaTeX owners. Which option would you prefer?

@ronkok

If Edge does look at the output from such a server-side installation, it will render a span-wide blob of color instead of the subject matter.

If we go with option 3, it is possible to always render a black arrow for browsers that do not support it:

@supports not (mask-image: #000) { .stretchy { background-color: transparent !important; } .x-arrow { background-image: url(...) !important; } ... }

For IE, @supports is not supported but the \9 hack can be used instead.

glebm · 2017-04-07T19:04:28Z

static/images/doubleleftarrow.svg

@@ -0,0 +1,43 @@
+<svg xmlns="http://www.w3.org/2000/svg">


These SVGs should be minified, ideally at build time. I recommend svgo for this, can easily shave off 30%.

ronkok · 2017-04-08T16:39:09Z

Here's a thought: If I inline the SVG code in the JavaScript (to enable server-side \color), that opens up another possibility. I could then write all the SVGs inline, always. That would eliminate the entire /images/ folder and all its SVG files. And KaTeX would never make a HttpRequest for an image file. So it would be faster. The downside is a lot more bloat in the HTML.

Comments?

glebm · 2017-04-11T10:45:02Z

So it would be faster.

Not necessarily, as the browser would need to parse and render a separate SVG image for every arrow from scratch. The giant HTML payload would also make server-side rendered downloads much slower.

I'd much prefer to always use CSS masks and render black arrows for browsers that do not support them (via @supports not + IE hacks). The SVGs can be inlined into the CSS at build time to avoid XHR requests.

ronkok · 2017-04-11T15:43:46Z

@edemaine, I've created a local version with all the SVG code inline. It increases the JavaScript size by 20K, which is less than I expected. I took a pretty extreme approach to eliminating code duplication. For instance, I wrote the typical opening SVG tag only once and I wrote the path for a rightarrow only once. Then, for any specific image, I append these strings together on the fly to create the final complete SVG code. It's pretty compact code, but I suspect it would be hard to maintain and extend.

@glebm, If were to summarize your thoughts in my own words, it would go like this:

Move feature detection and/or browser detection from the JavaScript to the CSS. That enables detection in server-side rendering.
Use CSS mask when supported and render black images when mask is not supported. That makes inline SVG code unnecessary.

That would complicate the CSS pretty substantially, but it is in every other way very attractive. I'll work up a prototype. I'm leaning towards this approach myself.

ronkok · 2017-04-11T22:46:58Z

@glebm, I now have @supports partly working. It properly controls the background-image and the mask-image in Chrome, Edge, and Firefox. Now I need to write an inline style to set the background-color. The JS is node.style.backgroundColor = options.color; It has to be inline because I don't know at build time what color the user will want.

How does one use @supports to control whether or not an inline style gets rendered?

glebm · 2017-04-11T22:48:10Z

@ronkok I believe the !important qualifier in the property values inside the @supports not should take priority over the inline styles (so the background-color can be set back to transparent if the browser does not support masks).

kevinbarabash · 2017-04-16T01:18:33Z

static/images/doubleleftarrow.svg

@@ -0,0 +1,43 @@
+<svg xmlns="http://www.w3.org/2000/svg">
+<svg viewBox="0 0 400000 549" preserveAspectRatio="xMinYMin slice">


Why the extra <svg>? Couldn't viewBox and preserveAspectRatio be set on the outer <svg>?

@kevinbarabash, Some of the SVGs are nested, so that the inner SVG can keep an undisturbed aspect ratio. For instance, we want an arrow head to be un-distorted when the arrow gets longer or shorter. In these files, each arrow SVG contains an arrow that is 400 ems long in the inner SVG. The outer SVG is set to match the dimensions defined for it by the CSS. The outer SVG clips the inner SVG; it does not stretch the inner SVG. That's the purpose of the preserveAspectRatio="xMinYMin slice" notation.

Of course, we do want some of the SVGs, like \cancel, to vary their aspect ratio. Those files do not get the nested SVG treatment.

kevinbarabash · 2017-04-16T01:20:35Z

@ronkok awesome PR. I haven't done a close reading of the changes yet, but we'll definitely want some screenshot tests for the new functionality.

ronkok · 2017-04-16T03:19:58Z

@kevinbarabash, Regarding screenshots, I agree. I also have some work underway that improves the sever-side rendering, as suggested by @glebm. I'm busy on other things for a couple of days, but sometime next week I'll get you some screenshots and a squashed PR.

ronkok · 2017-05-02T00:54:28Z

@kevinbarabash, I've updated PR #670 with my latest work, improving server-side rendering and minfying the SVG files. I've also squashed the PR. It's ready for your review whenever you find it convenient. You'll find that the JavaScript and the HTML are simpler, but the CSS is more complex.

I've also added some Jasmine tests. I tried to add Screenshotter tests, but failed. I don't plan to try again. On the other hand, there is more than one way to contribute. If you want to assign some Screenshotter work to someone at KA, I would be happy to make a financial contribution that leaves KA whole. The Screenshotter code that I tried to add is:

Boxed: \boxed{F=ma} \quad \boxed{ac}\color{magenta}{\boxed{F}}\boxed{F=mg}

ExtensibleArrows: |
    \begin{array}{l}
        \xrightarrow[ab]{ABC} + \xRightarrow{ABC} + \xrightleftharpoons[ab]{ABC} + \xhookrightarrow[ab]{ABC} \\
        \xtwoheadrightarrow{ABC} + \frac{\xrightarrow[ab]{ABC}}{\xrightarrow[ab]{ABC}} + \left\lvert\xrightarrow[ab]{ABC}\right\rvert
    \end{array}

HorizontalBraces: \overbrace{\displaystyle{\oint_S{\vec E\cdot\hat n\,\mathrm d a}}}^\text{emf} = \underbrace{\frac{q_{\text{enc}}}{\varepsilon_0}}_{\text{charge}}
HorizontalBrackets: |
    \begin{array}{l}
        \overbracket{(2x+3)}^\text{factor 1}\,\underbracket{(4x+5)}_\text{factor 2} \\
        \overbracket[0.15em][1.2em]{10\rightarrow 9}^{\text{high}} \rightarrow \overbracket[0.05em]{2\rightarrow 1}^{\text{low}}
    \end{array}

LowerAccent: |
    \begin{matrix}
        \underleftarrow{AB} \quad \underrightarrow{AB} \quad \underleftrightarrow{AB} \quad \undergroup{AB} \\
        \underlinesegment{AB} \quad \undertilde{AB}  \quad \color{green}{\underrightarrow{AB}} \\
        \underrightarrow{F} + \underrightarrow{AB} + \underrightarrow{AB}^2 + \underrightarrow{AB}_2 \\
        \frac{\underrightarrow{AB}}{\underrightarrow{AB}} + \sqrt{\underrightarrow{AB}} + \left\lvert\underrightarrow{AB}\right\rvert
    \end{matrix}

StretchyAccent: |
    \begin{array}{l}
        \overrightarrow{AB} \quad \overleftarrow{AB} \quad \Overrightarrow{AB} \quad \overleftrightarrow{AB} \\
        \overgroup{AB} \quad \overlinesegment{AB} \quad \overleftharpoon{AB} \quad \overrightharpoon{AB} \quad \color{red}{\overrightarrow{AB}} \\
        \widehat{\theta} \quad \widehat{AB} \quad \widehat{ABC} \quad \widetilde{A} \quad \widetilde{AB} \quad \widetilde{ABC} \\
        \overrightarrow{F} + \overrightarrow{AB} + \overrightarrow{F}^2 + \overrightarrow{F}_2 + \overrightarrow{F}_1^2 \\
        \overrightarrow{AB}^2+\frac{\overrightarrow{AB}}{\overrightarrow{AB}} + \sqrt{\overrightarrow{AB}} + \left\lvert\overrightarrow{AB}\right\rvert + \left(\overrightarrow{AB}\right)
    \end{array}
StrikeThrough: |
    \begin{array}{l}
        \cancel x \quad \cancel{2B} + \bcancel 5 +\bcancel{5ay} \\
        \sout{5ab} + \sout{5ABC} + \xcancel{\oint_S{\vec E\cdot\hat n\,\mathrm d a}} \\
        \frac{x+\cancel B}{x+\cancel x} + \frac{x+\cancel y}{x} + \cancel{B}_1^2 + \cancel{B^2} + \left\lvert\cancel{ac}\right\rvert
    \end{array}

kevinbarabash · 2017-05-02T01:35:08Z

@ronkok I'm sorry that make screenshots didn't work for you. I'll check out your branch later this week when I have some time. Thanks for posting the test input you were using.

ronkok · 2017-05-02T14:31:29Z

As before, I have a web page up that describes the results of PR #670. I’ve spent some time with BrowserStack, and the page now includes accurate browser support data.

edemaine · 2017-05-10T16:05:49Z

@ronkok It looks like you did a merge with master? There's now a lot of irrelevant commits in this PR. You might try git rebase -i b9e7b6898fd68a575d953000f4741ce2a24012f0 (or some other way to specify the master commit) and follow the instructions (carefully) for interactive rebasing.

ronkok · 2017-05-10T16:33:33Z

Yes, I needed to fix a bug -- extensible arrows should be REL, not ORD. So my attempt was to make the change, then squash all the work so that KaTeX maintainers could review it. As a new GitHub user, I have two comments:

GitHub’s ability to merge, diff, etc., is impressive.
It’s user interface is vile.

Obviously, things went wrong. I’ll try to follow your suggestion.

Apply CSS trickery to support functions that stretch in the horizontal direction

ronkok · 2017-05-10T17:19:32Z

I believe that the latest commit has fixed my earlier error. @edemaine, thank you for the help.

kevinbarabash · 2017-06-16T02:51:51Z

Not sure what happened with a couple of those screenshots. I've pulled the most recent changes to ronkok/master and am running make screenshots again.

update screenshots one more time

ronkok · 2017-06-16T03:08:25Z

I've already done the merge. I can do more. No worries.

Sometimes the only virtue that matters is persistence.

update Boxed-chrome.png with fully rendered image

kevinbarabash · 2017-06-16T03:52:25Z

@ronkok thank you for this awesome PR. I know there's lots of people waiting for all of these new commands, including Khan Academy. We'll have to do publish soon.

ronkok · 2017-06-16T03:57:05Z

@kevinbarabash , I realize that this PR has been more trouble for you than most. I appreciate your help and your patience. I'm glad that the value added from the PR is worth the trouble. If you need any adjustments to stretchy wide elements, I'll be glad to help.

@edemaine , @glebm, thank you as well. Between the three of you, you pulled across the finish line someone who started this work knowing very little about JavaScript or SVG and nothing at all about Git.

edemaine · 2017-06-16T13:13:52Z

Congrats @ronkok and @kevinbarabash on this 1600-line commit! Excited to try out the new features.

* Change \undeertilde to \utilde In PR #670, I made an error. The function that should have been `\utilde` I named instead `\undertilde`. There is an `\undertilde` from the `wsuipa` package, but it is a text-mode non-stretchy function. The proper command name is `\utilde`, a math-mode, stretchy function from packge `undertilde`. This PR fixes my error. * Fix screenshotter test

Fix a spelling mistake from PR #670.

ronkok changed the title ~~Fix \vec rendering bug.~~ Support stretchy wide elements. Apr 4, 2017

glebm suggested changes Apr 7, 2017

View reviewed changes

glebm reviewed Apr 7, 2017

View reviewed changes

kevinbarabash reviewed Apr 16, 2017

View reviewed changes

edemaine mentioned this pull request Apr 22, 2017

Added MathJax compatibility script #680

Merged

glebm approved these changes May 2, 2017

View reviewed changes

kevinbarabash added the GH Review: needs-revision label May 10, 2017

Support Stretchy Wide Elements

5256da0

Apply CSS trickery to support functions that stretch in the horizontal direction

kevinbarabash added the GH Review: review-needed label May 10, 2017

Delete Screen Resolution conflict

664d4f3

kevinbarabash and others added 2 commits June 15, 2017 23:02

update screenshots one more time

d07c7f3

Merge pull request #4 from Khan/stretchy_wide_4

f69304a

update screenshots one more time

kevinbarabash and others added 2 commits June 15, 2017 23:29

update Boxed-chrome.png with fully rendered image

072ee86

Merge pull request #5 from Khan/stretchy_wide_5

e085298

update Boxed-chrome.png with fully rendered image

kevinbarabash approved these changes Jun 16, 2017

View reviewed changes

kevinbarabash merged commit eff7653 into KaTeX:master Jun 16, 2017

This was referenced Jun 29, 2017

Set maxFontSize on rules. #744

Merged

Enable tall items in makeVList #746

Closed

Fix \boxed #754

Closed

Square root line position is inconsistent (depending on its contents) #60

Closed

ronkok mentioned this pull request Jul 11, 2017

Discussion: horizontal metrics #587

Open

ronkok mentioned this pull request Jul 19, 2017

Shrinkwrap vlists in table-like CSS. #768

Merged

ronkok mentioned this pull request Aug 10, 2017

Improve \sqrt #781

Closed

ronkok mentioned this pull request Aug 20, 2017

\vec problem in Chrome #629

Closed

edemaine mentioned this pull request Aug 20, 2017

Arrow on vector doesn't display #529

Closed

ronkok mentioned this pull request Sep 15, 2017

\sqrt doesn't scale properly when browser is zoomed in or out on Safari #883

Closed

ronkok mentioned this pull request Oct 24, 2017

Change \undertilde to \utilde #948

Merged

ronkok mentioned this pull request Nov 28, 2017

Change \xLongequal to \xlongequal #997

Merged

kevinbarabash pushed a commit that referenced this pull request Nov 28, 2017

Change \xLongequal to \xlongequal (#997)

28c55eb

Fix a spelling mistake from PR #670.

This was referenced Nov 29, 2017

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

Closed

Fix frac-line with wide span #1004

Closed

ronkok mentioned this pull request Aug 5, 2018

Fix \fbox to render argument as text #1550

Merged

ronkok mentioned this pull request Feb 21, 2019

Support \xymatrix (was Katex commutative diagram) #1834

Open

		@@ -0,0 +1,43 @@
		<svg xmlns="http://www.w3.org/2000/svg">
		<svg viewBox="0 0 400000 549" preserveAspectRatio="xMinYMin slice">

Support stretchy wide elements. #670

Support stretchy wide elements. #670

Conversation

ronkok commented Mar 28, 2017

khanbot commented Mar 28, 2017

ronkok commented Apr 4, 2017

sthoch commented Apr 5, 2017

ronkok commented Apr 5, 2017

edemaine commented Apr 5, 2017

ronkok commented Apr 5, 2017

ronkok commented Apr 5, 2017

edemaine commented Apr 6, 2017

glebm Apr 7, 2017 • edited Loading

Choose a reason for hiding this comment

ronkok Apr 7, 2017

Choose a reason for hiding this comment

edemaine Apr 7, 2017

Choose a reason for hiding this comment

glebm Apr 7, 2017 • edited Loading

Choose a reason for hiding this comment

ronkok Apr 7, 2017

Choose a reason for hiding this comment

edemaine Apr 7, 2017 • edited Loading

Choose a reason for hiding this comment

ronkok Apr 7, 2017

Choose a reason for hiding this comment

glebm Apr 11, 2017 • edited Loading

Choose a reason for hiding this comment

glebm Apr 7, 2017

Choose a reason for hiding this comment

ronkok Apr 7, 2017

Choose a reason for hiding this comment

ronkok commented Apr 8, 2017

glebm commented Apr 11, 2017 • edited Loading

ronkok commented Apr 11, 2017

ronkok commented Apr 11, 2017

glebm commented Apr 11, 2017 • edited Loading

kevinbarabash Apr 16, 2017

Choose a reason for hiding this comment

ronkok Apr 16, 2017 • edited Loading

Choose a reason for hiding this comment

kevinbarabash commented Apr 16, 2017

ronkok commented Apr 16, 2017

ronkok commented May 2, 2017

kevinbarabash commented May 2, 2017 • edited Loading

ronkok commented May 2, 2017

edemaine commented May 10, 2017

ronkok commented May 10, 2017

ronkok commented May 10, 2017

kevinbarabash commented Jun 16, 2017

ronkok commented Jun 16, 2017

kevinbarabash commented Jun 16, 2017

ronkok commented Jun 16, 2017

edemaine commented Jun 16, 2017

glebm Apr 7, 2017 •

edited

Loading

glebm Apr 7, 2017 •

edited

Loading

edemaine Apr 7, 2017 •

edited

Loading

glebm Apr 11, 2017 •

edited

Loading

glebm commented Apr 11, 2017 •

edited

Loading

glebm commented Apr 11, 2017 •

edited

Loading

ronkok Apr 16, 2017 •

edited

Loading

kevinbarabash commented May 2, 2017 •

edited

Loading