* Line breaks for inline formulas
* Basic support for \allowbreak and \nobreak
* Fix spacing around \nobreak, and add documentation
* Backwards-compatibility _getBuilt to fix tests
* Put operator spacing on same line as operator
* One approach to ~
* Simplify \allowbreak/\nobreak, make ~/\nobreakspace prevent line breaks
* Adapt to #1295
* Prevent wrapping within a .base
* Implement \hspace* properly
* Fix flow error
* Update comment for regularSpace
* Update screenshots
* Move `width: min-content` from .katex into .base
* Fix screenshot
* Add min-width rule to .vlist-s
* Factor out hasClass method
* Cleanup nobreak test
* Pull out buildHTMLUnbreakable
* Fix \hspace* test (no longer the same as \hspace)
* Fix \nobreak handling
* Add screenshot test
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.
The previous code incorrectly implemented TeXbook rules. First off,
the font metrics at issue should be those for the superscript/
subscript style, not the main style. Secondly, the metrics should be
scaled by the font size.
This changes some screenshotter tests (and they look more like TeX
now).
* Internal: Pass full `options` objects to makeSpan/makeSymbol.
Not just the current color. This will facilitate applying options
to built nodes in a standardized way, rather than changing all
callsites.
* Add style switching test: text and scriptstyle in the same group.
* Apply style-specific spacing using different CSS coding.
Specifically, infer style from a class on the *current* element,
rather than the parent element. Use "mtight" class to denote elements
with tight spacing (scriptstyle or scriptscriptstyle). Apply that
class automatically based on options.
* Fix#533, #534, #541.
- #534: Implement getTypeOfGroup for font groups.
- #533, #541: Improve the ways spaces are applied to lists. Since
CSS adjacency implements mathematical spacing, it's incorrect to
introduce "convenience spans" for spaces and display changes into
the generated HTML -- those spans break adjacency. Apply display
changes directly, and shift space spans into adjacent atoms.
Requires updates to two screenshotter tests, LimitControls and
SupSubLeftAlignReset. The new results for these tests are closer
to TeX output than the old results.
Also requires updates to Jasmine tests, since those assumed output
structures that have changed.
* Fix#136: Size commands generate fragments, not spans.
This is so the size commands don't hide the types of their enclosed
atoms. Addresses #136.
This slightly changes the vertical position of the Sizing test. Not
sure the vertical position matters, so change the test.
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.
