* Make types in defineFunction stricter and prep for porting functions.js to flow.
* Add more explicit types to functions/delimsizing.js.
* Port functions.js to @flow.
* Rough support for \raisebox
* Fix bounding box thanks to @kevinbarash and @ronkok
* Use calculateSize to support all currently supported units (ex, em, mu).
* Shift height and depth in all cases.
* Add screenshot test
* Rename transform -> raisebox
* Switch to normalsize in raisebox
* Attempt at using makeVList
* Significant rewrite, now working well
* rename textFunctionStyles to textFunctionFonts
* Add \smash, laps, spaces, and phantoms
1. Support `\smash`, including the optional argument from AMS.
2. Change `\llap` and `\rlap` so that they render in text style. Repeat: This *changes* KaTeX behavior.
3. Add `\mathllap` and `\mathrlap`. These will act as they do in `mathtools` and as in previous KaTeX versions of `\llap` and `\rlap`.
4. Add `\mathclap` and `\clap`.
5. Add `\hphantom` and \vphantom`.
6. Add `\thinspace`, `\medspace`, `\thickspace`
7. Add `\hspace`.
This work will resolve issue #270 and parts of #50 and #164.
A. Perlis has written a [concise description](https://www.math.lsu.edu/~aperlis/publications/mathclap/perlis_mathclap_24Jun2003.pdf) of items 1 thru 5. Except for `\smash`'s optional argument. It's described in the [AMS User's Guide](http://texdoc.net/texmf-dist/doc/latex/amsmath/amsldoc.pdf).
Item 6 also comes from the AMS User's Guide.
* Fix test spec
* Exploit makeVList for smash
* update smash and phantom screenshots for chrome
* Pick up review comments
* Change test from \llap to \mathlap
\llap is fundamentally a text-mode function. We should not expect it to work correctly when given math-mode arguments. So test \mathllap instead.
* Correct \llap macro
A correction. The previous macro returned an error if given an argument with math-mode content, such as x^2.
The corrected macro will not return an error. It will instead return well rendered math, but letters are in `\mathrm` font.
* update \llap, \rlap, \clap macros to use \textrm
* update Lap screenshots
src/functions.js was returning two properties referring to the base; since buildHTML runs `JSON.parse(JSON.stringify(tree))` to get an immutable copy, that meant we'd traverse and serialize and parse an exponentially-sized tree.
Test Plan: `\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{\breve{A}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}` renders instantly; previously, it reliably timed out with even half that depth.
* Support for \' \` \^ \~ \= \u \. \" \r \H \v text-mode accents
* bug fix
* Possible Safari fix
* Forbid text accents in math mode
* Switch to noncombining characters for most accents. Revert Safari change.
* Add tests
* Found non-combining diaresis accent too
* Add babel transform-class-properties to have static class properties
* Upgrade Lexer and Parser files to use ES6 classes
* Update eslint max line length to 90 character (more indent because of using ES6 classes)
* Upgrade eslint and jasmin to support ES stage-2 features
* Use static properties to place constants near their functions
* Migrate all remaining sources to ES6 syntax
* Increase eslint max line length to 84
* Remove non-babelified endpoint in dev server.js
* Clean up server.js functions after removing browserified
* Make screenshotter not to use babel endpoint as we babelify everything now
This reverts commit 4d2e46e7f6.
Having trailing commans makes diffs easier to read as it avoids modifying a
line just to add a trailing comma if there is another item to add at the end
of a list. There are plans to switch to ES6 notation and to translate that
to ES5 as part of the build process. Since that translation would remove
trailing commas, the IE9 problems that originally motivated the commit
should vanish soon.
Summary: IE 9 doesn't like trailing commas. When we introduced eslint, we added
a bunch of trailing commas, which makes IE 9 sad.
Test Plan:
- `make lint`
- Visit http://localhost:7936/ using IE 9 on browserstack.
- See that the math loads, and there are no errors in the F12 developer tools.
@kevinb
These commands set their arguments in a given TeX math class. Use
the existing "op" type for \mathop (to support \limits); introduce
a new "mclass" type for the other classes.
Fixes#482. Tests borrowed from #485 (cbreeden).
It's important to get spacing right that the domTree classes reflect
math atom types. So use those types exclusively, rather than
repeating the type mapping twice (once when building spans, once in
getTypeOfGroup).
* Remove getTypeOfGroup.
* Add getTypeOfDomTree (simpler).
* Adjust supsub type calculation.
* Adjust delimsizing internals.
* Introduce MacroExpander
The job of the MacroExpander is turning a stream of possibly expandable
tokens, as obtained from the Lexer, into a stream of non-expandable tokens
(in KaTeX, even though they may well be expandable in TeX) which can be
processed by the Parser. The challenge here is that we don't have
mode-specific lexer implementations any more, so we need to do everything on
the token level, including reassembly of sizes and colors.
* Make macros available in development server
Now one can specify macro definitions like \foo=bar as part of the query
string and use these macros in the formula being typeset.
* Add tests for macro expansions
* Handle end of input in special groups
This avoids an infinite loop if input ends prematurely.
* Simplify parseSpecialGroup
The parseSpecialGroup methos now returns a single token spanning the whole
special group, and leaves matching that string against a suitable regular
expression to whoever is calling the method. Suggested by @cbreeden.
* Incorporate review suggestions
Add improvements suggested by Kevin Barabash during review.
* Input range sanity checks
Ensure that both tokens of a token range come from the same lexer,
and that the range has a non-negative length.
* Improved wording of two comments
Summary:
This only supports em and ex units and doesn't handle vertical layouts.
Negative kerning works.
Test Plan:
- make test
- make screenshots (verify that d is slightly overlapping c in the screenshots)
Reviewers: emily
Summary
We'd like contributors to use the same linter and lint rules that we use
internally. This diff swaps out eslint for jshint and fixes all lint failures
except for the max-len failures in the test suites.
Test Plan:
- ka-lint src
- make lint
- make test
Reviewers: emily
Fixes issue #255.
Mixing the variable number of arguments a function receives from TeX code
with the fixed arguments which the parser provides can cause some confusion.
After this change, a handler will receive exactly two arguments: one is a
context object from which things provided by the parser can be accessed by
name, which allows for simple extensions in the future. The other is the
list of TeX arguments, passed as an array.
If we ever switch to EcmaScript 2015, we might want to use its destructuring
features to name the elements of the args array in the function head. Until
then, destructuring that array manually immediately at the beginning of the
function seems like a useful convention to easily find the meaning of these
arguments.
Since the previous commit deliberately avoided reindenting, this one here
does just that: reindenting the existing code. There are no other changes.
Notice how the new indentation leaves more room to function handlers.
Having one long array literal to contain the code of all function
implementations is problematic. It makes it difficult to add auxiliary
functions or data close to the function inside the list where it is needed.
Now the functions are no longer defined using such a literal, but instead
using calls to a "declareFunction" function which receives all the relevant
data. Since each function call is independent from the others, anything can
go in between.
This commit deliberately avoided reindenting existing code to match the new
surroundings. That way it is easier to see where actual changes happen,
even when not performing a whitespace-ignoring diff.
This adds \lgroup, \rgroup, \lmoustache and \rmoustache,
provides \lVert and \rVert with the correct type for each,
and makes \lvert, \rvert, \lVert and \rVert available
through \left...\right.
This commit introduces environments, and implements the parser
infrastructure to handle them, even including arguments after the
“\begin{name}” construct. It also offers a way to turn array-like data
structures, i.e. delimited by “&” and “\\”, into nested arrays of groups.
Environments are essentially functions which call back to the parser to
parse their body. It is their responsibility to stop at the next “\end”,
while the parser takes care of verifing that the names match between
“\begin” and “\end”. The environment has to return a ParseResult, to
provide the position that goes with the resulting node.
One application of this is the “array” environment. So far, it supports
column alignment, but no column separators, and no multi-column shorthands
using “*{…}”. Building on the same infrastructure, there are “matrix”,
“pmatrix”, “bmatrix”, “vmatrix” and “Vmatrix” environments. Internally
these are just “\left..\right” wrapped around an array with no margins at
its ends. Spacing for arrays and matrices was derived from the LaTeX
sources, and comments indicate the appropriate references.
Now we have hard-wired breaks in parseExpression, to always break on “}”,
“\end”, “\right”, “&”, “\\” and “\cr”. This means that these symbols are
never PART of an expression, at least not without some nesting. They may
follow AFTER an expression, and the caller of parseExpression should be
expecting them. The implicit groups for sizing or styling don't care what
ended the expression, which is all right for them. We still have support
for breakOnToken, but now it is only used for “]” since that MAY be used to
terminate an optional argument, but otherwise it's an ordinary symbol.
Summary:
On https://app.asana.com/0/34646644303310/33935538887378, @eater requested we add some new colors to KaTeX, which lives in the spin-off Khan/KaTeX open source project. (See screenshot for colors.) I added these colors to KaTeX so math typesetting tools in exercises have access to them.
I used "blueA", "blueB", etc. because dashes and numbers aren't supported in KaTeX/LaTeX functions.
The actual mapping of color name => hex value is in "Options", and the listing of colors available for typesetting is in "functions".
See also https://phabricator.khanacademy.org/D18158 for the related additions to utils/math.js and KAthJax.
Test Plan:
- Set up the KaTeX dev environment (instructions taken from https://github.com/Khan/KaTeX/blob/master/CONTRIBUTING.md):
```
cd KaTeX
make setup
make serve
```
- Now that the server is up and running, visit http://localhost:7936/ to try live typesetting. Enter the following LaTeX code to try the new colors:
```
\blueE{e=mc^2}
```
- Try other new colors including \redD, \mintC, \grayH, \kaBlue, etc.
- Old colors like \orange should still work.
- Run the Jasmine test suite at http://localhost:7936/test/test.html.
Reviewers: emily
Reviewed By: emily
Subscribers: nataliefitzgerald, eater, cameron, david
Differential Revision: https://phabricator.khanacademy.org/D18152
Summary:
Use the TeX definitions of `\root` to get the optional `\sqrt`
argument in the right place. Also add the MathML version.
Fixes#48
Test Plan:
- `make test`
- See that the images look good
Reviewers: kevinb, alpert
Reviewed By: alpert
Differential Revision: https://phabricator.khanacademy.org/D17236
Summary:
The greediness of the `\color` function wasn't set correctly,
leading to expressions like `\color{red}\text{a}` parsing correctly,
when they shouldn't. (This is based on how MathJax parses, since TeX
doesn't have a `\color` function, so MathJax is the standard).
Test Plan:
- Make test
- See that `\color{red}\text{a}` doesn't parse (like MathJax)
- See that `\color{red}{\text{a}}` does parse (like MathJax)
- See that `\color{red}\frac12` doesn't parse (like MathJax)
- See that `\color{red}{\frac12}` does parse (like MathJax)
- See that `\red\text{a}` doesn't parse (like MathJax)
- See that `\red{\text{a}}` does parse (like MathJax)
- See that `\red\frac12` doesn't parse (like MathJax)
- See that `\red{\frac12}` does parse (like MathJax)
Reviewers: alpert
Reviewed By: alpert
Differential Revision: https://phabricator.khanacademy.org/D17130
Summary:
Using \phantom with non-phantom math in Perseus doesn't render to be the
same size because \phantom uses MathJax and the non-phantom math uses KaTeX.
Implementing \phantom in KaTeX should solve this alignment issue.
Test Plan:
[x] write (and run) unit tests
[x] create (and run) screenshotter tests
Reviewers: emily
Reviewed By: emily
Differential Revision: https://phabricator.khanacademy.org/D16720
Summary:
This adds support for rendering KaTeX to both HTML and MathML
with the intent of improving accessibility. To accomplish this, both
MathML and HTML are rendered, but with the MathML visually hidden and
the HTML spans aria-hidden. Hopefully, this should produce much better
accessibility for KaTeX.
Should fix/improve #38Closes#189
Test Plan:
- Ensure all the tests, and the new tests, still pass.
- Ensure that for each of the group types in `buildHTML.js`, there is a
corresponding one in `buildMathML.js`.
- Ensure that the huxley screenshots didn't change (except for
BinomTest, which changed because I fixed a bug in `buildHTML` where
`genfrac` didn't have a `groupToType` mapping).
- Run ChromeVox on the test page, render some math. (for example,
`\sqrt{x^2}`)
- Ensure that a mathy-sounding expression is read. (I hear "group
square root of x squared math").
- Ensure that nothing else is read (like no "x" or "2").
- Ensure that MathML markup is generated correctly and is interpreted
by the browser correctly by running
`document.getElementById("math").innerHTML =
katex.renderToString("\\sqrt{x^2}");` and seeing that the same speech
is read.
Reviewers: john, alpert
Reviewed By: john, alpert
Subscribers: alpert, john
Differential Revision: https://phabricator.khanacademy.org/D16373
Summary:
Add the ability to pass in options to the render calls which contain information about the parse. This information is passed around to the parser and builder, which parse and render differently depending on the options. Currently, this includes an option to render the math in display mode (i.e. centered, block level, and in displaystyle).
Also added some changes to make it easier to add new data to functions (now that new data doesn't need to be copied into the ParseFuncOrArg data structure, it is looked up when it is needed) and has more sane support for the `'original'` argType (as suggested by pull request #93).
Test Plan:
- Make sure tests and lint pass
- Make sure huxley screenshots didn't change, and new screenshot looks correct
Reviewers: alpert
Reviewed By: alpert
Differential Revision: https://phabricator.khanacademy.org/D13810
