mirror of https://github.com/Smaug123/KaTeX synced 2025-10-11 05:58:40 +00:00

Files

Emily Eisenberg d93a958379 Make KaTeX work in Quirks mode (#608 )

* Make KaTeX work in Quirks mode

Summary: In issue #601, it was noticed that the KaTeX bug with the fraction
bars overlapping the text was occuring with an XHTML doctype. This indicated
that the bug we were seeing was caused by both quirks mode and limited-quirks
mode (which is a version of quirks mode with fewer quirks and is enabled for
various doctypes including some XHTML ones).

Based on the [quirks spec](https://quirks.spec.whatwg.org/), it appears that
there are only two quirks in limited-quirks mode, both having to do with a
line-height calculation. @gagern figured out that if we added some zero-width
spaces in our elements, we would stop triggering the quirk, which would make
our fractions render correctly in limited-quirks mode.

I implemented that change, and ran the screenshotter in limited-quirks mode.
There were several other places that suffered from the same quirk, but were
also easily fixed via adding zero-width spaces. I then ran the screenshotter in
quirks mode, and discovered that (once an appropriate meta charset was added),
everything looked correct still.

So, this diff fixes all of the places that the limited-quirks mode quirks
affect our rendering, and removes the warning about rendering in quirks mode.

I also added support to our screenshotter to render things in both no-quirks
and quirks mode, to ensure that things don't break in the future. I copied the
non-quirks images to the quirks images, and ran the screenshotter with
`--verify` to make sure that they look the same.

I have some thoughts that I'd like to hear opinions about:
 - I'm not super happy with how the screenshot tests work. Ideally we'd test
   both quirks mode and non-quirks mode against the same images, since we'd
   like them to be the same. I'm not sure how to make that work well, though,
   since then people wouldn't be able to tell if it's a quirks-mode problem or
   not.
 - I removed the doctype in the testing page file, so all testing would now be
   done in quirks-mode. Not sure if we really want that.
 - I need to test this in IE, but it looks like the trailing commas change we
   made with eslinting is causing problems (cause IE doesn't like trailing
   commas).

Test Plan:
 - `./dockers/Screenshotter/screenshotter.sh --verify`

* Compare quirks mode against same screenshot files

Now the screenshotter itself can run more than one mode.  It does serve the
HTML file from its own JavaScript code now, so that it can include different
doctype headers without needing distinct files for each.  There is a
provision to mark specific tests as quirky in case they produce different
results depending on the mode.

* Some cleaning up and comments

* Restore access to the babelified version of the HTML page for screenshots

* Reference unicode fonts using absolute path names

This avoids issues caused by the fact that the dynamically generated
ss-render.html is mounted to a different location than the test.html from
which it is derived.

* do chrome screenshots first

* remove commented out code, simplify hadle_search_string call

2017-07-30 22:41:37 -04:00

2.5 KiB

Raw Blame History

How to generate screenshotter images

Automatic generation of screen shots

Now you too can generate screenshots from your own computer, and (hopefully) have them look mostly the same as the current ones! Make sure you have docker installed and running. If all you want is (re)create all the snapshots for all the browsers, then you can do so by running the screenshotter.sh script:

dockers/Screenshotter/screenshotter.sh

It will fetch all required selenium docker images, and use them to take screenshots.

Manual generation

If you are creating screenshots on a regular basis, you can keep the docker containers with the selenium setups running. Essentially you are encouraged to reproduce the steps from screenshotter.sh manually. Example run for Firefox:

container=$(docker run -d -P selenium/standalone-firefox:2.48.2)
node dockers/Screenshotter/screenshotter.js -b firefox -c ${container}
# possibly repeat the above command as often as you need, then eventually
docker stop ${container}
docker rm ${container}

For Chrome, simply replace both occurrences of firefox with chrome.

Use without docker

It is possible to run screenshotter.js without the use of Docker:

npm install selenium-webdriver
node dockers/Screenshotter/screenshotter.js

This will generate screenshots using the Firefox installed on your system. Browsers other than Firefox can be targeted using the --browser option. For a complete list of options pass --help as an argument to screenshotter.js. Using these it should be possible to have the script connect to almost any Selenium web driver you might have access to.

Note that screenshots taken without Docker are very likely to disagree from the ones stored in the repository, due to different versions of various software components being used. The screenshots taken in this fashion are well suited for visual inspection, but for exact binary comparisons it would be neccessary to carefully set up the environment to match the one used by the Docker approach.

Choosing the list of test cases

Both screenshotter.js and screenshotter.sh will accept an --include option (short -i) which can be used to specify a list of test cases to be processed, as a comma separated list. Conversely, the --exclude option (short -x) can be used to specify a list of cases which are not being processed.

Examples:

node dockers/Screenshotter/screenshotter.js -i Sqrt,SqrtRoot
dockers/Screenshotter/screenshotter.sh --exclude=GreekLetters

2.5 KiB Raw Blame History