1. Parse the user's input (e.g. "{-b \pm \sqrt{b^2-4ac} \over 2a}") into an internal data structure (math lists, etc -- MathJax apparently uses MathML internally)
2. Classify the symbols and operators into different styles, with associated sizes and spacing, etc.
3. Ultimately, decide the position and size of each glyph (where each separate "blob of ink" should go).
4. Express these positions in the output format, e.g. for MathJax or KaTeX with their native HTML+CSS, you'll get a tag soup of spans with styles like "position: absolute; top: -4.333em; left: 0.566em;" etc. DVI or PDF output formats have their own operators for expressing positions of glyphs.
As far as fonts and rendering are concerned there is not much to this; the glyphs are just picked from a math font that someone has designed (containing glyphs for, say, the integral sign or summation sign or "x" etc).
The interesting work of typesetting that happens in 2 and 3 is described (for TeX, and used by MathJax/KaTeX) in Appendix G of The TeXbook; you may find it useful to supplement it with pictures and explanation from this article: https://www.tug.org/TUGboat/tb27-1/tb86jackowski.pdf
If you'd like to know one of these in further detail I can try to explain or look it up :)
Wow, thanks very much. I have not yet studied Appendix G or the Jackowski article, but let me see if I have this straight:
Suppose we give the string `\int` to the `latex` executable, and it produces a DVI file.
The DVI file that was produced specifies exactly how the integral symbol should be shaped. It does this by specifying (a) the name of a font that is installed on the user's system and (b) the identity of a glyph within that font that should be used to display the integral symbol.
So, if we now run dvipng, what dvipng does is look up the glyph from that font, and create a rectangular array of pixels that approximate that shape.
Similarly, if we were to run dvisvgm, it would look up the glyph in the font, and create an SVG specification of some curves that can be used to approximate that symbol.
(I have no knowledge of how a font specifies a "glyph"; is it conceptually similar to the way SVG specifies curves?)
If you run "tex" or "latex" on this, it will generate a test.dvi. You can look at a human-readable representation of the DVI file with dvitype or dviasm — what it says is to move to a particular position, and set the character at position 82 ('R') from the font "cmex10 at 10pt".
Then you can run either dvipng or dvisvgm (or dvipdfmx, or…) on this, which will take this instruction, read in the font (for example, it may load file /usr/local/texlive/2019/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb) and replace it with the pixels (at a given resolution) or shape from the font. In case of SVG, it may pick the actual description (as a path) from the (vector) font:
You may be interested to know where the description in the font came from. The short answer is "the font designer" (of whatever font is being used). In this case, cmex10 is the "math extension" font from the Computer Modern family designed by Donald Knuth (the author of TeX and METAFONT). He described the shape in METAFONT, etc. All that's another story :)
Thank you, very interesting and helpful. (I ran dvitype on that as you suggested.)
I think I'm just going to describe what I'm doing in case you have any more helpful words of advice or thoughts! Obviously no worries if not.
I'm working on a project that involves generating images from LaTeX math fragments and displaying them in a text editor buffer inline with the text, to create an environment for editing LaTeX math without needing to constantly regenerate the PDF. So similar to what also exists in various places, e.g. preview-latex and org-mode in Emacs.
In one sentence: I am struggling to produce non-fuzzy images when using dvipng or imagemagick to produce a PNG.
I am at the stage where I am trying to identify the best image-generation workflows to support. Users might have conventional screens, or high res ("4k?") screens, or high res Apple Retina screens. For example, Emacs org-mode offers the following 3 flows:
* dvisvgm - LaTeX DVI output is converted to SVG and Emacs displays the SVG.
* imagemagick - LaTeX PDF output is converted to PNG by imagemagick and Emacs displays the PNG.
* dvipng - LaTeX DVI output is converted to PNG and Emacs displays the PNG.
I personally own a Macbook Pro with a Retina screen and what I have observed is:
Iff your text editor is built with special support for Retina screens:
1. Beautiful crisp results can be obtained via dvisvgm.
2. It is also possible to produce a high resolution PNG and then resize it down in the editor so that it retains its crisp appearance at small size.
However, using dvipng (latex -> dvi -> png) or imagemagick (latex -> pdf -> png) I have not yet managed to obtain any crisp images of math fragments when they are at the size of a conventional line of text on the screen. That's on a Retina screen; I'm also planning to test against a conventional monitor via a raspberry pi.
I believe that dvipng does not include a "pHYs" chunk in the PNG data, and that this may be one reason that I am struggling to create small PNGs with high pixel density.
Ah rasterization is another rabbit hole that I don't know much about and can't say anything without trial-and-error experimentation on the specific device :-) But first I'd recommend checking whether the image is being displayed at its natural size, pixel-for-pixel (or conversely that it is being generated to have the number of pixels at which it is going to be displayed -- both imagemagick and dvipng take a dpi option). See also some approaches at https://tex.stackexchange.com/questions/44486/pixel-perfect-...
1. Parse the user's input (e.g. "{-b \pm \sqrt{b^2-4ac} \over 2a}") into an internal data structure (math lists, etc -- MathJax apparently uses MathML internally)
2. Classify the symbols and operators into different styles, with associated sizes and spacing, etc.
3. Ultimately, decide the position and size of each glyph (where each separate "blob of ink" should go).
4. Express these positions in the output format, e.g. for MathJax or KaTeX with their native HTML+CSS, you'll get a tag soup of spans with styles like "position: absolute; top: -4.333em; left: 0.566em;" etc. DVI or PDF output formats have their own operators for expressing positions of glyphs.
As far as fonts and rendering are concerned there is not much to this; the glyphs are just picked from a math font that someone has designed (containing glyphs for, say, the integral sign or summation sign or "x" etc).
The interesting work of typesetting that happens in 2 and 3 is described (for TeX, and used by MathJax/KaTeX) in Appendix G of The TeXbook; you may find it useful to supplement it with pictures and explanation from this article: https://www.tug.org/TUGboat/tb27-1/tb86jackowski.pdf
If you'd like to know one of these in further detail I can try to explain or look it up :)