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

Since my announcement of canvas rendering was met with considerable interest (by KaTeX developers as well as for bokeh/bokeh#647), I decided to share my work early on. At the time I'm opening this request, this branch is in a very early stage of development. But others are welcome to contribute, be it by commenting, by suggesting ideas, or by providing code in the form of pull requests against this branch.

After launching the local development server, see http://localhost:7936/canvas.html for an example of rendering to canvas.

This is a first step towards support for matrices, and it addresses issues raised in

• #206 – support for \begin…\end environments
• #47 – \begin{array} (with argument) in particular
• #43 – various matrix flavours like matrix, bmatrix…

In particular, I've implemented parser support for environments, made environments available for array, matrix, pmatrix, bmatrix, vmatrix, Vmatrix, and added a proof-of-concept renderer for these.

This branch is really just a first step, one day of work put into this. This pull request is not meant as “please pull this now” but rather as a platform where future development can be discussed and coordinated, to result in a pull eventually.

My branch doesn't make much effort to do spacing the same way TeX does, mainly because I don't own a copy of Knuth's TeX Book. It doesn't work well with small font sizes. For really large numbers of rows, the delimiters appear too small in my opinion. But before I continue on these details, I'd like to know whether others have already put in some effort here. Perhaps someone has all the spacing calculations already worked out, and was just waiting for parser support to hook this up? I'd also like to know whether the way I tackled the problem, extending the parser in particular, is going in the right direction.

The way I see it, KaTeX has some knowledge of how high its boxes are, both above and below the baseline, but none about how wide they are. Is this correct? Seeing this, I decided that the most feasible way to implement HTML output for matrices would be column-wise: each column is a vlist, with items positioned according to the overall height and depth of the corresponding matrix row. Perhaps this will even allow matrices to line-wrap in certain environments. I've got some doubts whether the same approach would be reasonable for align* and similar environments. Should we stick to this approach, or should aligned equations and/or matrices be encoded to a <table> instead?

I can't make any guarantees how far I'll be able to follow this up. I'm doing this for a project at TU München, and once it satisfies the requirements we have there, continued development would likely have to be in my spare time, which is a rare commodity. How feature-complete does the thing have to be before it can get merged into the master?

~~This is a proposal more than it is a pull request. Or perhaps it’s a proof of concept. The proposed code allows KaTeX to interact with a proposed mhchem extension. Such a mhchem extension would be installed in a way similar to the auto-render extension or the copy-tex extension. That is, web site administrators would list the mhchem-for-katex.js file in the <head> of their page.~~

~~I invite comments. I expect that @edemaine can write a better helper function to recreate the argument to be passed to the extension. I’m sure that @mhchem can improve on the edits that I will suggest to the mhchem code.~~

~~It’s pretty simple, really. mhchem expands a macro. So I’ve written a suggested wrapper around the mhchem code that exposes a object with a single method: mhchem.expand(str: string, stateMachine: "ce"|"pu") : {expansion: string, errorMsg: string}.~~

~~The code in this PR checks for existence of the object, then calls the function.~~

General revision (Nov 3): This PR adds support for the \ce and \pu functions from the mhchem package. However, this PR makes no revisions to any core KaTeX files. Instead, it exploits the fact that KaTeX exposes the defineMacro function. All the mhchem code is a separate file. So web page administrators will be able to choose whether or not to include mhchem as an extension.

As in the original version of this PR, the code is mostly a copy of the mhchem package for MathJax. I still have made only four modifications, as described just below.

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

Here's an implementation of \verb, following #588. As @gagern suggested, the main parsing happens in the lexer, followed by code in parseSymbol to handle commands starting with \verb.

Playing around with LaTeX, I found (and implemented) the following behavior:

• \verb will treat a following newline character as the start/end character.
• Otherwise, the \verb argument cannot have a newline in it.
• \verb will treat a following space as the start/end character.

I'm pretty new to generating output in MathML and HTML, and struggled to get the mathtt font, so please check that code in particular...

Addresses issue https://github.com/Khan/KaTeX/issues/29. Requires a Huxley test which I will try to add tomorrow. Here's a screenshot:

TODO:

• [x] rebase
• [x] switch the order so the solidus comes first in the span and is shifted over with CSS
• [x] figure out how to make firefox render \not{abc} correctly

This is a proposed fix to #706, as discussed in that thread.

In my opinion, we should accept "absolute distances" (in, cm, etc.) as input, but convert them to how LaTeX would render in 10pt mode. Under this model, we can convert all units to em (via ptPerEm and using \normalsize font size) and render them as em in HTML. Yes, the browser can scale everything, but then all distances ("absolute" and "font-relative") would all scale in exactly the same way, so everything will simply be a scaled version of the 10pt LaTeX rendering.

Rationale: Absolute distances are used all over KaTeX already, such as \arraycolsep being defined to 5pt. But it's not actually 5pt -- it renders as half of the font size. As a math author, this is actually what I want -- I don't care about "real-world distances", I care about how I'd write it in LaTeX to get the relative spacing that I want. I have an intuitive sense of how much space I add when I write \\[0.5in] (although I admittedly usually use em and ex units), and want roughly that much space, independent of what CSS font size or browser scaling they happen to get rendered in.

Issues: One issue I ran into is where to put the table of units. Currently it is in buildHTML, which means the parser can't access it and so can't directly tell whether a unit is valid, so I moved validity testing to buildHTML. (This causes some current tests to fail.) Perhaps it would be better to move this somewhere else. My feeling is that there should be a buildGeom that would be useful for outputting HTML and other "geometric" formats we support in the future (SVG, Canvas) but not MathML (so buildCommon doesn't make sense). Thoughts?

I'm also missing any additional tests. Open to suggestions. I think the obvious thing would be a screenshot test, as it's essentially a visual effect. An example I found useful was

\begin{array}{l}
  \mathrm H\kern 1em\mathrm H\\
  \mathrm H{\scriptstyle \kern 1em}\mathrm H\\
\end{array}

which taught me that the LaTeX em unit really doesn't change when switching style, only when switching font size. Not what I thought!

In v0.9.0, I see some good fraction lines and some overly thick grey ones (Chrome on Windows)

Firefox is a bit better in that it is less obvious (at least on my monitor setup). In the fractions on the first line, it appears to have a darker bottom 1px line and a lighter "shadow" above it, the middle line is good, and the last line is mostly thick grey:

So unfortunately it doesn't appear that using path in the svg has completely fixed it.

I'm sticking with v0.9.0-alpha for my production site for now.

This PR fixes #801.

• Lexer now looks for combining dicritical marks and adds them to the same character
• Parser's parseSymbol now recognizes both combined and uncombined forms of Unicode accents, and builds accent objects just like the accent functions
• ~~Added CJK support to math mode (not just text mode). #895.~~

This PR ~~is not ready to merge, but I'd appreciate feedback on the approach~~ is ready. @ronkok @kevinbarabash

Relevant commit message:

TeX and CSS treat line heights in fundamentally different ways. In TeX, every character is treated as a box of its precise height and depth; the line height (\baselineskip) applies after characters have been assembled into lines. In CSS, in contrast, every character creates a "line box" corresponding to the accompanying font. When characters of different fonts and sizes are placed into the same span, the resulting line box contains the line boxes of all children.

This is unfortunate because, for example, we want \frac{1}{2} to behave in vertical spacing contexts like it is exactly as tall and deep as the visible fraction (which is the TeX behavior). Given CSS constraints, though, in most contexts the fraction has extra vertical space: the line boxes for the numerator and denominator create padding. For small boxes, this isn't so bad. To really see the problem put a tall rule in the denominator of a fraction, or check out the VerticalSpacing screenshotter test, which has way more space than it should.

Solving this problem in CSS is difficult. There is no easy way to get rid of the extra line boxes.

But there is a way, namely tables. A table-cell with vertical-align top, bottom, or middle is ignored for the purposes of line height calculation.

So in this commit, makeVList puts its contents into a vertical-align:bottom table-cell (to clear unwanted line boxes), with an extra row used to represent depth.

Many Chrome screenshotter tests change. This is because Chrome rounds table dimensions to integral numbers of pixels, while it uses sub-pixel positioning for non-table displayed tabs. That makes many vlists a fraction of a pixel wider than they used to be.

Before requesting a feature, please search for existing issues.

Is your feature request related to a problem? Please describe. I want to render

Katex supports overbrace and underprice; but there seems no way to achieve above. Support for \lefteqn will allow this as described below

Describe the solution you'd like: A solution is to use phantom along with lefteqn (described here and below)

 \[
  0+\lefteqn{\overbrace{\phantom{1+2+3}}}1+
  \underbrace{2+3+\overbrace{x+y+z}+
  \lefteqn{\overbrace{\phantom{4+5}}}4}+5
  \]

Link to or name of a (La)TeX package that provides the same feature: Usually\lefteqn{} is used to break long line of equation and is supported natively. Other packages which achieve this is outbraces and underoverlap (see same as above link)

Describe alternatives you've considered: Currently I don't see any way to achieve same through katex.

KaTeX already supports Join function(symbol: ⋈, function: \Join) but not it's branches such as:

• Left Outer Join(⟕ symbol)
• Right Outer Join(⟖)
• Full Outer Join(⟗)

I think they should be easy to add. this symbols are widely used in rational algebra. Thanks for your hard work.

Discussed in https://github.com/KaTeX/KaTeX/discussions/3769

Ideas?

Eliz.

This PR corrects misspellings identified by the check-spelling action.

What is the previous behavior before this PR?

The misspellings have been reported at https://github.com/jsoref/KaTeX/commit/55adbfb034441663fe62209bd9442cd750a7869b

What is the new behavior after this PR?

The action reports that the changes in this PR would make it happy: https://github.com/jsoref/KaTeX/commit/dfc30bb80e04e50d98d0ab4347acebe15bfc227c

Note: this PR does not include the action. If you're interested in running a spell check on every PR and push, that can be offered separately.

Before reporting a bug

• [x] Check common issues.
• [x] Check the bug is reproducible in the demo. If not, check KaTeX is up-to-date and installed correctly.
• [x] Search for existing issues.

Describe the bug: Go to the Katex demo. Insert the following text: \begin{\pmatrix}. Disable "throw on error".

Now notice that this will crash Katex. This is not an error message that is generated by katex that can be rendered. It actually throws an exception. This breaks for example react-katex completely, making the entire page go blank!

Expected behavior: It should not crash. Instead, it should return a nicely formatted error messages etc.

The rest is already explained since it is reproducible on the current and latest Katex Demo!

Before reporting a bug

• [x] Check common issues.
• [x] Check the bug is reproducible in the demo. If not, check KaTeX is up-to-date and installed correctly.
• [x] Search for existing issues.

Describe the bug: When compiling to MathML rather than HTML, the \htmlId, \htmlClass, \htmlStyle and \htmlData commands have no effect.

To Reproduce: Steps to reproduce the behavior:

1. Go to the demo
2. Select output: mathml in the settings
3. Paste the examples of the HTML commands
4. Inspect element

Expected behavior: The commands should cause the MathML elements to have the specified ID/class/style/data.

Environment (please complete the following information):

• KaTeX Version: 0.16.3
• Device: Desktop
• OS: Manjaro GNU+Linux
• Browser: Firefox
• Version: 103.0.2