Commit Graph

12 Commits

Author SHA1 Message Date
Erik Demaine
523df299e5 Line breaks for inline formulas (#1287)
* 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
2018-05-11 01:44:26 +02:00
Ron Kok
c2ae9e0da6 Revert frac-lines to borders (#1249)
* 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
2018-05-10 16:05:24 +09:00
Erik Demaine
20b5a58451 Work around negative space bug in Chrome (#1194)
* Work around negative space bug in Chrome

Fix #984

The screenshot test is still somewhat defective, showing a space before
the "post" text (a period).  This seems limited to the screenshotter, however,
as it works fine in the tester via
http://localhost:7936/?text=%5Cfbox%7B%5C%241%2C%5C!000%2C%5C!000%7D%5CKaTeX&display=0&after=.

* Update screenshots

* Switch to inherited `width: min-content`
2018-03-09 16:38:25 +01:00
Ron Kok
95ffb4fad4 Padding over \sqrt and Paths for frac-line (#1143)
* 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
2018-02-17 13:56:13 -05:00
Kevin Barabash
63f541b6e6 Use JS for spacing between atoms instead of CSS (#1070)
* Use JS for spacing between atoms instead of CSS

Summary:
This is the first step towards creating an intermediate representation
that can be used to generate HTML, SVG, and Canvas commands for rendering.
By generating spans that contain the width of the spaces instead of
relying on CSS sibling rules we'll be able to one day replaces the spans
with intermeidate 'Glue' nodes (in a later PR).

An added benefit of this approach is that is enables us to programmatically
change the values for thinspace, mediumspace, and thickspace which will
allow us to implement the \setlength command.

Test Plan:
- npm test
- dockers/Screenshotter/screenshotter.sh --verify

* fixed failures in BinCancellation, BoldSymbol, and OperatorName

* update screenshots

* don't use current size when determining size of spaces, update more screenshots

* fix spacing in SizingBaseline and StyleSwitching

* actually do the right thing for sizing groups

* fix \not for Chrome and Firefox

* do TODOs

* address feedback from the code review

* fix issue in delimsizing.js

* add TODO to think about a better solution in href.js

* fix typos, simplify href, be honest about paddingLeft for \not
2018-01-24 23:03:36 -05:00
Ron Kok
c62f814765 Fix frac-line (#1025)
* 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
2017-12-26 16:17:06 -07:00
Eddie Kohler
2da06d541e Shrinkwrap vlists in table-like CSS. (#768)
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.
2017-07-30 11:13:55 -04:00
Martin von Gagern
4792dec8e5 Update Selenium Docker images from 2.46.0 to 2.48.2 2015-11-12 17:08:16 +01:00
Martin von Gagern
2e002ff37a Use jspngopt and pako to create reproducible PNG files for Chrome as well
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.
2015-08-30 02:12:55 +02:00
Emily Eisenberg
ce99abd1f2 Update Dockerfile for ttfautohint, update metrics
Summary:
Update the MathJaxFonts `Dockerfile` to enable the use of
`ttfautohint` which hints our fonts better. Also, fix the location that
batik is downloaded from, update some formatting in the `Dockerfile`,
and update the fonts and metrics.

Test Plan:
 - Compare a rendered `= - A z 4 \Longrightarrow \Sigma \Biggl(` in
   Chrome on Windows at font sizes 10px to 20px before and after this
   change.
 - See that characters look about the same, or better.
 - See that the screenshot tests didn't change in firefox (maybe firefox
   runs the same autohinting algorithm that we do?), and don't visually
   change in chrome

Reviewers: kevinb, alpert

Reviewed By: kevinb, alpert

Differential Revision: https://phabricator.khanacademy.org/D18977
2015-07-16 12:01:26 -07:00
Martin von Gagern
b7e1581869 Update chrome screenshots
I forgot to re-create these after rebasing.
2015-07-15 15:40:31 +02:00
Martin von Gagern
6f65f685f3 Add screenshots taken from Chrome 2015-07-14 18:09:58 +02:00