# Baseline issues with Computer Modern Math Extension

Context: in the Computer Modern Math Extension font (cmex), the baseline seems to be going through the top of every character. I have become aware of this by displaying various characters from the Computer Modern collection in a Windows application that I am developing: the symptom is that cmex characters are placed below the baseline. One can also download the file cmex10.pfb from CTAN and open it with FontForge, to see that all the glyphs are aligned with respect to their top.

Is there a way (such as font-metric information) to correct for this alignment?

TeX is able to perform this alignment, but so far I have not been able to find out how.

• The symbols in this font are meant to be shifted around -- appendix G of the texbook contains the details. You could probably change the tfm-file, but I don't see what you would gain in an application which doesn't use the tex typesetting machine. Wouldn't a unicode math font be better? – Ulrike Fischer Nov 3 '15 at 9:02
• Thank you for your comment. Is there a unicode version of Computer Modern that has all the functionalities of the math extension font? – C-M Nov 3 '15 at 15:34
• @C-M There is Latin Modern Math. – egreg Nov 3 '15 at 15:37

TeX math extension fonts are indeed very peculiar. Knuth tried to pack as much information as possible within the scarce computing resources available when TeX was developed.

So, instead of defining a parameter for the thickness of the vinculum in radicals, Knuth decided to grab the information from the math extension font metric file, precisely from the height of the radical symbol. Therefore all radical symbols appear to hang below the baseline:

\noindent\rlap{\vrule height 0.1pt depth 0.1pt width \hsize} % the baseline
{\tenex\char"70}
{\tenex\char"71}
{\tenex\char"72}
{\tenex\char"73}
{\tenex\char"74}
{\tenex\char"75}
{\tenex\char"76}

\bye


The rightmost three glyphs are the ones used for building larger radicals: the main part, the repeating bar and the top.

The rules of TeX specify to use the height of the chosen glyph (based on the size of the material to be under the radical) for drawing a rule as the vinculum. Afterwards, all the material, including the radical, is shifted up so that it is placed symmetrically with respect to the formula axis (the height of which is also a parameter in the symbol font metric file, which is loaded for math family 2).

Other “optimizations” are done with respect to essentially all characters in the math extension font, for packing information necessary to build up larger symbols; the fact that essentially all glyphs sit below the baseline is unimportant, because when the math extension font is involved the piece of formula will be shifted anyway.

Appendix G of the TeXbook describes the process in details. Unfortunately, this makes these fonts unusable in other applications. Newer engines such as XeTeX and LuaTeX introduce several new parameters that make these “optimizations” irrelevant, so the Unicode math fonts can have the symbols placed where they should for usage in any text processing application.

• Thank you very much for your answer. I have tried to read Appendix G (specifically, item 13), but it is still not completely clear to me how to perform the alignment. The formula (h(x) - d(x))/2 - a does not seem to apply since a = sigma_22 is not defined for the cmex font. – C-M Nov 3 '15 at 15:31
• @C-M You're right, it's in the symbol font (family 2). – egreg Nov 3 '15 at 15:33
• Does this mean that all the cmex 10pt TFM glyphs have a height that is the height (or height plus depth) of a horizontal rule, which if I recall is 4pts default? In the pictorial example above, the rule's thickness is much less (.1 + .1)pt, so the tops of the radicals are sticking up above the rule. Is the horizontal rule width (scaled according to the current font size in some way) the number to use to translate the baseline of a Latin Modern extension math glyph so as to make it function the same way as a Computer Modern equivalent? – jsbox Nov 20 '15 at 17:33
• Clarification: default horizontal rule thickness (height, or height+depth), not "horizontal rule width", is what I meant above. – jsbox Nov 20 '15 at 17:44
• @jsbox No, it's not necessarily the case that the height is the rule width. Most have, some have zero height, some different heights. – egreg Nov 20 '15 at 18:14