[texhax] Any crazy math formulas for testing a TeX language interpreter

[Douglas McKenna]

All/any -

I'm in the throes of testing, bug-flushing, and beginning to use for real work a new TeX language interpreter, currently called JSBox, that I've implemented.  It is a self-contained (not dependent on any library), system-agnostic, library written in C, that supports full 21-bit Unicode characters internally (plus Unicode and UTF-8 input/output) at the same time as being dynamically configurable to behave compatibly with a classic TeX82 or a (current) eTeX engine.   I gave a talk about JSBox at the summer TUG 2014 meeting, and wrote an article for TUGboat soon thereafter about how it traces its own execution of "trip.tex", albeit differently from what TeX does.

Depending on a ton of factors, JSBox appears to be significantly faster than the current TeX engine, primarily because JSBox can typeset an entire document into memory and then display it to the user (via direct data structure export to a client program), all without requiring any file I/O.

After much work in 2015, as of last week JSBox now appears to pass (functionally, though not literally) not only the "trip.tex" gauntlet test, but now the "etrip.tex" test as well (eTeX added 66 new primitives and/or parameters to classic TeX).  And JSBox passes a real-world test: I can drop my library code into a Cocoa page-viewer program and typeset a 150-page monograph that I originally wrote in LaTeX but with a few macro changes ported over to plain.tex.  The source code for the monograph in turn relies on a lightweight document markup library called "opmac" distributed with TeXLive.  All of this uses only Computer/Latin Modern glyphs (converted to OpenType) and their attendant TFM files.

I'm still working on how the client program deals with some of the common \special{} extensions, "especially" for colored hyperlinks.  Nonetheless, the look of the result exported directly to the screen (no intermediate DVI or PDF, just glyphs positioned and drawn by the Mac toolbox) seems indistinguishable from the output of pdftex as displayed via my Mac's PDFKit.  Which, believe me, is gratifying after all the years of work I've put into this thing since I took the leap (in year MMIX).

There are plenty more bugs to be trounced; passing the trip and etrip tests is necessary, though not sufficient, to validate an interpreter.  Indeed, I can attest that passing these important validation tests is possible at the same time as implementing TeX language conditional expansion "non-compatibly" (bug fixed after trying to execute some real-world code for AMS font stuff).

But the monograph I'm using has only fairly elementary math formulas in it, and the trip and etrip tests don't depend on any real world fonts.  So I'm wondering if there's some TeX-validation test file, using the plain format and not dependent on LaTeX, that has little more in it than a totally gnarly, full-page or multi-page, super-ridiculous, semi- or non-sensical math formula that exercises most/all of a TeX interpreter's math typesetting machinery, using most/all of the math symbol and extension glyphs in the Computer Modern fonts?  Worst-case math, in other words.

If not, I'll try to spend some time creating one.  It's just that testing with code I haven't contrived myself is more robust.

Thanks for any suggestions.  Onward, into the fog ...

- Doug McKenna
Mathemaesthetics, Inc.