During COVID I wrote up some math notes in HTML taking advantage of the wide screen format of desktop systems to display large formulae. However now that I am back to commuting by train, it would be nice to display those notes on my mobile phone. The desktop mode of the original HTML does a poor job at displaying on such a device. Therefore I have designed and implemented a script preprocessor which converts TeX-like math code into responsive HTML code.
There are some obvious things that can be done to improve the display of math on small touch screens. From most desirable to least
- Text flow inline math, as has been done by KaTeX and MathJax4.
- Reduce margin and gutter sizes to allow more space for the text.
- Provide user with precise, fine grain control of the font size for the web site, and save it as a permanent setting on the device.
- Add horizontal scrolling to elements which are too wide to fit the viewport. Fine if it only affects one or two equations per page but otherwise tedious for the reader.
- Rewrite the math into a more compact format. For example replace $x_1+x_2+x_3$ with $\sum x_i$. Again ok if it affects only one or two equations but overall not so good.
- Author multiple versions of each formula. For example a narrow and wide form, then switch between them based on device or viewport width. Tedious to author and often not very effective.
While those things are fine for inline math they are not good enough for display equations. It would be nice to have something similar to text-flow but more sophisticated, where it rearranges the equation to fit into the available space something like a human would do on a blackboard. This is where the preprocessor comes in.
Preprocessor
The preprocessor converts TeX code to responsive HTML code. These are the steps in the process:
-
Author manually edits the TeX code to remove flow-unfriendly features that mess things up, in particular
-
remove outer level environment blocks like
\begin{equation}
-
replace paired
\left(
and\right)
brackets, which prevent splitting, with their explicitly sized alternatives, for example\big(
and\big)
-
remove most artificial spacing like
\quad
because it tends to mess up the spacing in the new layout - finally add a line indicating which flow algorithm to use
-
remove outer level environment blocks like
-
Preprocessor breaks the input TeX code into "lines" and "words" based on the flow algorithm.
This step is done with a heuristic algorithm which works well about 90% of the time.
To handle difficult cases, it can be assisted by the author inserting explicit
$
signs to mark word breaks and$$
signs to mark line breaks. - Preprocessor then converts each "word" into a standalone piece of TeX code. This step has some complications because when TeX code is split into pieces and run through a TeX to HTML layout engine the spacing gets messed up. Preprocessor needs to correct that to restore the correct visual appearance.
-
Preprocessor then inserts the pieces of TeX code into standard HTML templates for the specific flow algorithm.
These templates are made up of
flex
box andgrid
HTML elements, suitably styled with CSS rules. This step uses several new baseline responsive CSS features added to WWW Standards between 2019 and 2024. - The final HTML is then rendered using one of the standard TeX to HTML layout engines.
Algorithms
flow
The flow algorithm is very similar to normal text flow and is most suitable for homogenous text like polynomials. The left parameter tells the algorithm to break just before plus and minus signs (normally it breaks just after). The indent parameter tells the algorithm to indent lines after the first to the level of the first equals sign.
#flow,left,indent
\Delta = 256a^3e^3 - 192a^2bde^2 - 128a^2c^2e^2 + 144a^2cd^2e - 27a^2d^4 + 144ab^2ce^2 - 6ab^2d^2e - 80abc^2de
+ 18abcd^3 + 16ac^4e - 4ac^3d^2 - 27b^4e^2 + 18b^3cde - 4b^3d^3 - 4b^2c^3e + b^2c^2d^2
This is the above code rendered with an equation label.
To see the math respond to screen size change on a mobile device, rotate the device to switch between portrait and landscape mode.
fold
The fold algorithm is a text flow algorithm in which the line breaks occur at predetermined positions and in a predetermined order. It is better for inhomogenous text like matrices and integrals. For a large equation which won't fit on one line it usually looks best to do the first break after the top level equals sign. Then if needed, another break around the middle of what's remaining.
#fold
\begin{vmatrix}
1 & x_1 & x_1^3 & x_1^4 \\
1 & x_2 & x_2^3 & x_2^4 \\
1 & x_3 & x_3^3 & x_3^4 \\
1 & x_4 & x_4^3 & x_4^4 \\
\end{vmatrix} = $
\big(x_1x_2 + x_1x_3 + x_1x_4 + x_2x_3 + $
x_2x_4 + x_3x_4\big) \cdot \prod_{i\lt j} (x_j-x_i)
This is the above code rendered with an equation label.
stack
A stack is a set of equations which can be written on one line separated by comma's if there is room. Otherwise they can be stacked and aligned vertically at the equals signs. The width parameter is the container width which trigger's the transition from horizontal to vertical format.
#stack,width=500
x_3 = a \cdot \frac {x_1y_1 + x_2y_2} {x_1x_2 + y_1y_2}
y_3 = a \cdot \frac {x_1y_1 - x_2y_2} {x_1y_2 - x_2y_1}
This is the above code rendered with an equation label.
train
A train is a list of expressions coupled together with equals signs. On a wide screen they look good written on one line, but on a narrow screen they look better written as a vertical stack with the equals signs vertically aligned. The width parameter is the container width which trigger's the transition from horizontal to vertical format.
#train,width=700
g_2
= -4(\epsilon_1\epsilon_2 + \epsilon_2\epsilon_3 + \epsilon_3\epsilon_1)
= \tfrac {1} {24} (A^2 + B^2 + C^2)
= \tfrac {1} {12} (12ae - 3bd + c^2)
This is the above code rendered with an equation label.
Where To Next?
The above set of algorithms are a good starting point for implementing responsive layout features in a TeX to HTML javascript library. Implementing natively would have the following advantages
-
Most issues caused by breaking the TeX code into small pieces should vanish.
-
For example splitting
\left(
and\right)
pairs should be easy. - Inconsistent spacing around breaks should be easily eliminated.
- The DOM object tree will be smaller and cleaner. For example using MathJax3 (1) has 650 elements whereas the ideal MathML implementation (5) has just 166 elements (according to AI).
-
For example splitting
- The algorithm for automatically choosing break points should work better because it would have more context to work with.
- More complex responsive structures could be created by nesting combinations of the basic algorithms.
- Performance should be better. In fact if there is sufficient browser support for MathML then the generation of the MathML code can be performed statically at web page publication time, completely eliminating the conversion overhead from both web client and server programs.
I think it unlikely the developers of MathJax and KaTeX would want to implement these more complex responsive layout features. This is because those packages are primarily focused on reproducing the exact rendering of LaTeX and it does not include such features.
Given the recent 2023 adoption of MathML Core support across all major browsers, I think the best way forward is to create a new software package which does TeX to MathML conversion directly, incorporating responsive layout features. It should be possible to mitigate all the undesirable effects of chopping math formula into small pieces, as is required for responsive layout. While the rendering quality of MathML is not as good as those two libraries, it is strategically superior and, given enough time, moderately simple to implement the conversion process.
Prototype MathML
The following equations are manually crafted MathML examples. They represent the ideal output of a TeX math to MathML converter which generates "responsive" HTML.
#flow
#fold
#stack
#train
These examples demonstrate how to apply responsive styling directly on the MathML <mrow>
elements thereby maintaining the semantic integrity of the <math>
object tree.
MathML Issues
To evaluate the current state of MathML I have added KaTeX MathML and TeXZilla to the list of supported converters. They can be selected from the control panel which is activated by clicking on the web page title. Although there are a few issues, they provide a good yardstick to gauge the current state of MathML support in the mainstream browsers. I have also added Lexer a gamma version of the new converter. Current known issues are:
-
Safari and Firefox are yet to implement display styling on
<mrow>
elements. This feature has already been implemented in Chrome, Edge, Opera and Samsung Internet. Without this feature responsive MathML cannot be sensibly implemented. - On Android a third party math font must be used to achieve satisfactory rendering quality.
-
Bracket stretch size algorithm not well-suited to splitting across
<mrow>
elements.