* Support \hdashline
Support `\hdashline` from package `arydshln`. This PR acts as a complement to PR #1395.
Similarly to #1395, the dashed line is rendered as `border-bottom-style: dashed;`. That does not exactly match the `dashsegment` and `dashgap` lengths in `arydshln`, but it does render black lines with sharp edges.
* Fixed top line position
* Add screenshots
* Fix lint error
* Fix another lint error
* Deleted HLine screenshots
* Pick up comments
* hacked together a dashed vertical bar
* Updated tests and spec.
* tidied up the screenshot template for arrays
* added the vertical lines at the end back
* Updated screenshots for arrays
* Revert frac-lines to borders
This PR reverts the rendering of frac-lines from SVG paths back to span borders. This solves the thick grey bar reported by @mbourne in issue #1173.
The result is a frac-line similar to KaTeX v0.9.0-alpha1. The frac-lines are span borders and the CSS contains a `min-width: 1px;` rule to keep those borders visible.
There is one difference between this PR and v0.9.0-alpha1. The earlier work contained a second CSS rule:
```
@media screen and (-webkit-min-device-pixel-ratio: 2), screen and (min-resolution: 192dpi) {
.katex.mfra.fracline {
min-height:0.5px;
}
}
That second CSS rule did not help much. Instead, it caused some lines to disappear. In the thread to issue 1173, people tested the rendering from the proposed approach and reported that frac-lines disappeared only at sized that were already too small to read.
* Fix lint errors
* Remove superfluous SVG paths.
* Remove superfluous CSS
* Removed `rulespan` from `stretchy.js`
* Support Unicode \ll and \lll
Fixes issue #1271
* Fix indent
* update screenshots for fracLineBorder
* Update Arrays-chrome screenshot for fracLineBorder
* Padding over \sqrt and Paths for frac-line
This replaces two earlier PRs.
* Restore reaction arrows
* regenerate screenshots
* Set line padding in a constant
* Update with latest master
* Fix lint error
* update screenshots
* Fix frac lline
For frac-line, use an SVG line in an extra tall span.
I still need to think of a way to adust `vertical-separator`.
* Fix spaces in katex.less
* regenerate screenshots
* update HorizontalBraces and StrikeThrough screenshots
* Change frac-line from border to full span
Change `frac-line` and `vertical-separator`. Instead of using span borders, fill entire span using a `box-shadow`.
This change will enable more dependable engagement of the `min-height` CSS.
* Fix indentation
* Fix indent again
* Change box shadow to inline SVG
* Fix lint error
* regenerate screenshots after switching to SVG for fraction bars
The combination of jspngopt and pako should eliminate possible causes for
different PNG encodings, although the core reason for #325 remains unknown.
Pako has poorer compression rates than native libz, but optimization can
counter that effect, and actually reduce the size of the screenshots.
The screenshots for LimitControls and UnsupportedCmds on Firefox used to
exhibit subpixel rendering before, for reasons unknown. The regenerated
versions don't exhibit this. See #324 for a discussion.
This adds the ability to add `|` to a column description and have
vertical separators be added. I added types to the column descriptions
and added some logic to handle the separators when building the vertical
lists of the array.
Test plan:
- See the Arrays screenshot looks good.
- `make test`
A fraction is surrounded by a box of width \nulldelimiterspace on either side.
That size is 1.2pt and does not scale with the style or font size.
Furthermore, a \frac creates a brace-enclosed group which results in a
\mathord, not a \mathinner.
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.
