Cahiers O
m EXPERIENCES TYPESETTING OPENTYPE MATH WITH LUALATEX AND XELATEX P Ulrik Vieth Cahiers GUTenberg, n 56 (2011), p. 116-126.
© Association GUTenberg, 2011, tous droits réservés. L’accès aux articles des Cahiers GUTenberg (http://cahiers.gutenberg.eu.org/), implique l’accord avec les conditions générales d’utilisation (http://cahiers.gutenberg.eu.org/legal.html). Toute utilisation commerciale ou impression systématique est constitutive d’une infraction pénale. Toute copie ou impression de ce fichier doit contenir la présente mention de copyright. Experiences Typesetting OpenType Math with LuaLATEX and XƎLATEX Zkušenosti se sazbou matematiky ve formátu OpenType math v LuaLATEXu a XƎLATEXu Ulrik Vieth
Abstract: When LuaTEX first provided support for OpenType math ty- pesetting in version 0.40, high-level macro support for math typesetting was first developed for ConTEXt MkIV, while support for LuaLATEX was initially limited to a very low-level or non-existent. In the meantime, this gap has been closed by recent developments on macro packages such as luaotfload, fontspec, and unicode-math, so LATEX users are now provided with a unified high-level font selection interface for text and math fonts that can be used equally well with both LuaLATEX and XƎLATEX. While a unified high-level interface greatly improves document interchange and eases transitions between systems, it does not guarantee that identical input will always produce identical output on different engines, as there are significant differences in the underlying implementations of math ty- pesetting algorithms. While LuaTEX provides a full-featured implemen- tation of OpenType math, XƎTEX has taken a more limited approach based on a subset of OpenType parameters to provide the functionality of traditional TEX engines. Given the possibility of running exactly the same test files on both engines, it now becomes feasible to study those differences in detail and to compare the results. Hopefully, this will allow to draw conclusions how the quality of math typesetting is affected and could be improved by taking advantage of a more sophisticated, full-featured OpenType math implementation. Key words: LuaLATEX, XƎLATEX, OpenType math, math typesetting, fontspec package, Cambria, Asana, XITS, Neo Euler.
Abstrakt: Jelikož LuaTEX podporuje Open Type math až od verze 0.40, byla podpora matematické sazby na vyšší úrovni vytvořena nejprve pro ConTEXt MkIV, zatímco podpora pro LuaLATEX byla nízká nebo nebyla žádná. Další vývoj však tuto mezeru zacelil – uživatelé LATEXu mají nyní k dispozici jednotné rozhraní pro připojení fontů pro běžný text i pro matematickou sazbu pomocí balíčků luaotfload, fontspec a unicode-math;
116 doi: 10.5300/2011-2-4/116 Ulrik Vieth CONTEXT MEETING 2010 1
obojí lze celkem stejně dobře využít v LuaLATEXu i v XƎLATEXu. I když toto jednotné rozhraní značně zjednodušuje výměnu dokumentů i přenos mezi různými systémy, nezaručuje, že tentýž vstup vytvoří vždy tentýž výstup na různých počítačích kvůli významným odlišnostem v implemen- Experiencestaci algoritmů pro matematickou typesetting sazbu. Zatímco LuaT OpenTypeEX poskytuje úpl- nou implementaci všech vlastností OpenType math, XƎTEX převzal jen mathčást z nich with s ohledem LuaLaT na tradiční implementaceX and TEXu. XeLaT X Maje možnost překládat stejné testovacíE soubory v obou implemen-E tacích, bylo možné podrobně zkoumat jejich rozdíly a porovnat výslednou Abstractmatematickou sazbu. Doufejme, že toto přispěje k zjištěním, co ovlivňuje Whenkvalitu LuaTEX first matematické provided support sazby for OpenType a jak ji math zlepšit typesetting implementací in version 0.40, výhod high-level komplet- macro support for math typesetting was first developed for ConTEXt MkIV, while support for LuaLaTEX was initially limited to a very low-levelního orformátu non-existent. OpenType In the meantime, math. this gap has been closed by recent developments on macro packages such as luaotfload, fontspec, and unicode-math, so LaT X users are now provided with a unified high-level font A A E selectionKlíčová interface slova for text: and LuaL mathTE fontsX, X thatƎL canTEX, be used formát equally OpenType well with both math, LuaLaTE sazbaX and XeLaT ma- EX. Whiletematiky, a unified high-level balíček interface fontspec, greatly Cambria, improves document Asana, interchange XITS, and Neo eases Euler. transitions between systems, it does not guarantee that identical input will always produce identical output on different engines, as there are significant differences in the underlying implementations of math typesetting algorithms. While LuaTEX provides a full-featured implementation of OpenType math, XeTEX has taken a more limited approach based on a subset of OpenType parameters to provide the functionality of traditional TEX engines. Given the possibility of running exactly the same test files on both engines, it now becomes feasible to study those differences in detail and to compare the results. Hopefully, this will allow to draw conclusions how the quality of math typesetting is affected and could be improved by taking advantage of a more sophisticated, full-featured OpenType math implementation.
LuaTEX math % !TeX program = lualatex \documentclass[fleqn]{article} 1 휕ƨ푬 1 휕풋 Δ푬 − = 훁휆 + 휇 , \usepackage{fontspec,unicode-math} ƨ ƨ Ʀ \setromanfont{Cambria} 푐 휕푡 휀Ʀ 휕푡 \setmathfont{Cambria Math} 1 휕ƨ푩 \begin{document} \input{luatex-fixes} Δ푩 − ƨ ƨ = −휇Ʀ rot 풋 . 푐 휕푡 \input{math-test} \end{document}
XeTEX math % !TeX program = xelatex \documentclass[fleqn]{article} 1 1 휕 푬 1 휕풋 \usepackage{fontspec,unicode-math} Δ푬 − = 훁휆 + 휇 , 푐 휕푡 휀 휕푡 \setromanfont{Cambria} \setmathfont{Cambria Math} \begin{document} 1 휕 푩 Δ푩 − = −휇 rot 풋 . \input{xetex-fixes} 푐 휕푡 \input{math-test} \end{document}
Can you spot the difference? % !TeX program = pdflatex 1 \documentclass{article} 1 휕 ƨ푬 1 휕풋 \usepackage{pdfpages} Δ푬 − ƨ ƨ = 훁휆 + 휇Ʀ , \begin{document} 푐 휕푡 휀Ʀ 휕푡 \includepdfmerge [nup=2x1,noautoscale=true,delta=-21cm 0] ƨ 1 휕 푩 {xelatex-test.pdf,1,lualatex-test.pdf,1} Δ푩 − = −휇 rot 풋 . 푐ƨ 휕푡 ƨ Ʀ \end{document}
1 117 2 CONTEXT MEETING 2010 Ulrik Vieth
Introduction On the other hand, mainstream font formats such as OpenType did not provide any support for the seman- In this paper, we will review the state of recent devel- tics of math typesetting. opments of new T X engines and corresponding macro E Ironically, the lack of a suitable math font technology packages to support math typesetting with Unicode and was only resolved when Microsoft started to develop OpenType math fonts, based on our experiences from support for MS Office 2007. Given their influence as a testing the T X Live 2010 pretest distribution [1]. E vendor controlling the OpenType font specification [6], In the first part, we will summarize the available they simply went ahead and created an extension of the choices of T X engines and macro packages, as well as E OpenType font format containing a MATH table [7] and the available choices of math fonts, which can be used commissioned the design of Cambria Math as a refer- for testing OpenType math typesetting. ence implementation of an OpenType math font [8, 9]. In the second part, we will report our experiences In addition, they also developed a simplified math input testing the various T X engines, macro packages and E language known as ‘linear math’ [10]. fonts, and we will report our findings which kind of While there are sometimes strong reservations about problems were encountered and how these problems accepting a vendor-defined file format, especially an were resolved or circumvented. unreleased one coming from Microsoft, developers of In the third part, we will analyze and compare the re- font tools such as FontForge [11] as well as developers sults of running identical documents through different of T X engines were willing to accept OpenType math T X engines using different implementations of math E E as a de facto standard, because it filled a need and also typesetting algorithms, and we will try to draw conclu- because it turned out to be well-designed. sions how the quality of math typesetting is affected Upon closer analysis, many concepts of OpenType and could be improved. math could be seen as obvious extensions or general- izations of traditional concepts of math typesetting in Reviewing the state of OpenType TEX [12]. Moreover, most OpenType math font parame- math support in T X Live 2010 ters could be identified to have a direct correspondence E to TEX math font parameters [13], which had also been In recent years, many developments related to new TEX carefully analyzed in previous studies [14, 15]. engines and corresponding macro packages and fonts have focused on providing support for Unicode and OpenType math support in TEX engines OpenType, not just for text typesetting, but also for When XeTEX first added OpenType math support in math typesetting (which is still important as one ofthe version 0.997 as of 2007 [16], it kept TEX’s traditional traditional strong-holds of TEX). math typesetting algorithms essentially unchanged and only used a small subset of OpenType font parameters Unicode and OpenType math technology to initialize the required TEX font parameters. While the pre-history of Unicode text support dates When LuaTEX also added OpenType math support back to the mid-1990s, most activities related to Unicode in version 0.40 as of 2009 [17, 18, 19], it introduced math support only became possible during the last few a number of extensions and generalizations to TEX’s years, after a suitable font technology was developed as math typesetting algorithms, aiming to provide a full- an extensions to the OpenType font format. featured implementation of OpenType math. When the efforts to bring math into Unicode were As of TEX Live 2010, both new TEX engines support- started in the late 1990s by a consortium of scientific ing Unicode and OpenType math typesetting have been publishers, the original focus was on identifying math added to the mainstream distributions and have become symbols and getting them accepted into Unicode [2, 3]. widely available for using and testing the new features. Once this was done, the focus shifted to developing a However, their acceptance also depends on providing reference font implementation, the so-called STIX fonts, adequate macro package and font support. to provide the necessary glyph shapes [4]. While the STIX project was spending nearly a decade OpenType math support in macro packages waiting for fonts to be designed, the lack of a suitable When XeTEX was first added to TEX distributions, it was font technology for math typesetting was overlooked easily accessible to LaTEX users with XeLaTEX. A high- for a long time. While traditional TEX font formats sup- level font selection interface for text fonts was devel- ported math typesetting in their own way, they suffered oped with the fontspec package [20, 21], which became from limitations and questionable design decisions [5]. widely used as a standard package for XeLaTEX.
118 Experiences typesetting OpenType math with LuaLaTEX and XeLaTEX CONTEXT MEETING 2010 3
When XeTEX added math support, a corresponding Except for Cambria Math, all of these fonts all are high-level font selection interface for math fonts was freely available, either from CTAN (if already released) also developed with the unicode-math package [22], but or from GitHub (if still under development). unlike fontspec it wasn’t released until recently. As of TEX Live 2010, Asana Math and XITS Math are When LuaTEX added math support, high-level macro both included in the distribution, but Cambria Math support was initially developed for ConTEXt MkIV [23], and Neo Euler have to be obtained separately and need while macro support for LuaLaTEX (or Plain LuaTEX) to be installed manually in your texmf-local tree. was initially limited to the luaotfload package [24], Once installed, each of the fonts can be used in the which provided only a low-level interface. same way, but the range of symbols and math alphabets As of TEX Live 2010, LaTEX macro package support available may differ significantly between fonts. for Unicode and OpenType math typesetting has been much improved, as both the fontspec and unicode- math packages have undergone a complete rewrite, Experiences testing OpenType adding support for LuaLaTEX (based on luaotfload) to math support in TEX Live 2010 the code originally developed for XeLaTEX. Testing the functionality and quality of OpenType math As a result, LaTEX users are now provided with a typesetting implies testing a complex system, consist- unified high-level font selection interface for text and ing of typesetting engines, macro packages and fonts math fonts [25] that can be used equally well with both (with embedded intelligence), which have to interact XeLaTEX and LuaLaTEX. properly to produce the desired results. Given this interface, selecting a different math font Given the inherent complexity, there are a large (such as Cambria Math) can be as easy as this: number of problems which can occur, and most likely \usepackage{fontspec,unicode-math} will occur, so we have to consider the possibilities of \setmainfont[
119 4 CONTEXT MEETING 2010 Ulrik Vieth
⎛ ℏ ⎞ 훼 ∫ 휀 푬 ⋅ d풇 = ∫ 휆 d푉, ∫ 푩 ⋅ d풇 = 0 , 훾 ⎜ ∂훼 − 푞퐴훼⎟ 휓 + 푚k푐 휓 = 0 , ȱ Ʀ Ɂ ȱ ⎝i ⎠
훼 ℏ 훾 ʂ ∂훼 − 푞퐴훼ʅ 휓 + 푚k푐 휓 = 0 . ∫ 휀Ʀ푬 ⋅ d풇 = ∫ 휆 d푉, ∫ 푩 ⋅ d풇 = 0 . i ȱ Ɂ ȱ
Figure 1: Comparison of the size of delimiters in Asana Math Figure 2: Comparison of the size of displaystyle operators in for LuaTEX 0.60.x and LuaTEX 0.61. Due to a bug in the math Cambria Math for LuaTEX with incorrect parameter values of typesetting algorithms, the extensible version of delimiters was DisplayOperatorMinHeight and with a correction applied at the applied too soon. (The example shows the Dirac equation from macro level. (The example shows the integral form of the relativistic quantum mechanics.) Maxwell equations from electrodynamics.)
Engine problems of the more subtle kind were found In ConTEXt, a patch for incorrect font parameters in LuaTEX, when a bug was discovered for some math had been applied in the font loading code at the Lua fonts (such as Asana Math), which resulted in applying level in font-pat.lua, but a similar patch was missing the extensible version of delimiters before exhausting in luaotfload. Until this is fixed, a workaround to the all available sizes of big delimiters. (An example of the same effect can be applied at the macro level by setting incorrect behavior is illustrated in Figure 1.) \Umathoperatorsize\displaystyle=13.6pt. In the meantime, this bug has already been fixed in In any case, such kinds of patches for specific font LuaTEX 0.61, but again it was too late to include the fix parameter values only present a stop-gap solution until in TEX Live 2010 which still uses LuaTEX 0.60.x. the actual fonts can be fixed. Whether or not this will be possible, critically depends on the cooperation of the Problems with OpenType font metrics font developer or distributor and may range between Problems with OpenType fonts can also be of different very quickly (for some open source projects) and next kinds, ranging from fatal ones (such as containing mal- to impossible (for some commercial fonts). formed data structures causing TEX engines to crash) to more subtle ones (such as providing incorrect values of Problems with OpenType font shapes font metric parameters causing TEX engines to produce Font problems of yet another kind can occur when the incorrect results). In addition, font problems can also assignment of glyph shapes to Unicode slots does not include encoding issues or incorrect glyph shapes. match the expectations, or when an incorrect font style Font problems of the fatal kind did not occur while is used for some glyphs. testing OpenType math fonts, but a similar kind of One such problem was discovered for the partial problem was recently reported for some OpenType text differential symbol in Cambria Math and XITS Math. fonts. The problem was quickly addressed with a fixin Since Unicode math provides a separate slot for a math LuaTEX 0.61 to make the font parsing algorithms more italic version (U+1D715), one would expect the default robust about handling unexpected values. slot (U+2202) to be reserved for the upright version, yet Font problems of the more subtle kind were found the Unicode font tables incorrectly happen to show an with incorrect parameter settings in the MATH table of italic version in both slots and no upright version. Cambria Math and Asana Math, which caused LuaTEX Given the confusion in the Unicode font tables, it is to produce incorrect results. not surprising that several OpenType math fonts have The problem is related to the OpenType math pa- inherited the same problem. Unfortunately, such font rameter DisplayOperatorMinHeight, which is used in problems are unlikely to be fixed anytime soon. LuaTEX to determine the minimum size of displaystyle operators. If this parameter is incorrectly set too small ∂ 휕 훛 흏 Cambria Math in the font, displaystyle operators will appear in the ∂ 휕 훛 흏 XITS Math same size as textstyle operators. (An example of the incorrect behavior is illustrated in Figure 2.) ∂ 휕 훛 흏 Asana Math As it turned out, the problem had already been found earlier when OpenType math support in LuaTEX was Figure 3: Comparison of different font shapes of the partial first tested with ConT Xt, and a workaround had been differential symbol (upright, italic, bold upright, bold italic) as E they appear in Cambria Math, XITS Math, and Asana Math. applied, but the same problem now reappeared when Besides the confusion of upright vs. italic there are also some LuaTEX was tested with LuaLaTEX. obvious problems for some of the bold italic versions.
120 Experiences typesetting OpenType math with LuaLaTEX and XeLaTEX CONTEXT MEETING 2010 5
Problems with TEX macro packages Font-loading problems Problems with TEX (or Lua) macro packages are usually Font-loading problems are usually easy to fix or avoid, easy to fix. In the course of the TEX Live 2010 pretest, once the cause of the problem has been understood. a number of such issues were found in luaotfload and Nevertheless, such kinds of problems present a frequent unicode-math, which have already been fixed. source of frustration for unwary users, so it may well Only one issue has remained unresolved, which is be useful to discuss our experiences regarding the font related to the use of the \hbar macro. In a traditional loading problems we encountered in the course of test- LaTEX setting, \hbar is a macro which overlays the ing OpenType math with TEX Live 2010. italic letter ℎ with a bar accent from cmr to produce ℎ¯. What is important here is to understand that differ- By contrast, \hslash is a macro to access a ready-made ent mechanisms are used to locate OpenType fonts in glyph from the AMS fonts to produce ℏ. different TEX engines and macro packages. In a Unicode math setting, only \hslash is assigned In XeTEX, the fontconfig library is used to locate to a slot in an OpenType math font (U+210F), while there OpenType fonts, and this mechanism applies equally is no equivalent assignment for \hbar, which has some- well for system fonts installed in the system font path how retained its original macro definition and still uses as for fonts installed in your TEX Live distribution. a glyph from cmr to create the overlay. For lack of a Depending on your installation, it may be necessary better solution, it would be better to define \hbar as an to adjust the fonts.conf config file to include the font alias for \hslash in unicode-math. directories in your texmf-dist or texmf-local tree, and Quite a different effect occurs inE ConT Xt, where to refresh the font cache with the fc-cache command. \hbar is interpreted as a diacritic text character (ħ) in Once a font directory has been added to the search path, upright shape (U+0127), which may be appropriate in all kinds of font files will be found there, regardless of text typesetting, but not necessarily in a math formula. where the font files are located. As in unicode-math, it would be better to define \hbar In LuaTEX, the kpathsea path searching library is as an alias for \hslash in ConTEXt as well. used to locate fonts, which depends on the assignment of file extensions (such as *.ttf or *.otf) to different Problems caused by interactions between search paths. As a result of this, cambria.ttc will only TEX macro packages and TEX engines be found in the fonts/truetype tree, while euler.otf Yet another kind of problem was discovered recently, will only be found in the fonts/opentype tree. which was caused by an interaction problem between In addition to that, ConTEXt and luaotfload on macro packages and TEX engines, specifically between LuaTEX use yet another font-loading mechanism based the unicode-math package and the XeTEX engine. on a file cache implemented in Lua, which circumvents As it turned out, unicode-math allocated a new math the kpathsea library completely. System fonts outside family for the OpenType math font (such as family 4) the TEXMF tree will be located using the fonts.conf while XeTEX (unlike LuaTEX) somehow still expected config file to look up the font directories, but without certain math font parameters to be taken from families using the the fontconfig library. Once a font directory 2 and 3 (as in traditional TEX engines). has been added to the file cache, all kinds of font files As a result, the preloaded font metric parameters will be found there, regardless of where the fonts are from cmsy and cmex were incorrectly used to determine located, similar to the fontconfig library. the spacing of math instead of the font parameters from the OpenType math font. A fix for this problem is still pending, but most likely Comparing and testing the quality it would involve changing the unicode-math package of OpenType math typesetting to account for different engine-specific behaviors of To proceed with a study the quality of OpenType math LuaT X and XeT X. As a workaround, we can apply E E font support as of TEX Live 2010, we have the follow- a fix by reassigning the fonts in families 2 and 3 after ing choices of typesetting engines and macro packages loading an OpenType math font in family 4: at our disposal (disregarding Plain LuaTEX and XeTEX \ifxetex\everymath{ which only provide low-level support): \textfont3 = \textfont4 \textfont2 = \textfont4 \scriptfont2 = \scriptfont4 LuaTEX with ConTEXt MkIV \scriptscriptfont2 = \scriptscriptfont4 LuaTEX with LuaLaTEX }\fi XeTEX with XeLaTEX
121 6 CONTEXT MEETING 2010 Ulrik Vieth
While both LuaLaTEX and ConTEXt share the same 휕 ƨ휙 휕 ƨ휙 휕 ƨ휙 T X engine and the same implementation of math type- E Δ휙(풓) = ƨ + ƨ + ƨ .. setting algorithms, they differ in their high-level user 휕푥 휕푦 휕푧 interface and also in the intermediate levels of font Figure 4: Comparison of math typesetting from XeLaTEX (red) loading code (such as luaotfload). and LuaLaTEX (blue) using Cambria Math. (The example shows While both LuaLaT X and XeLaT X share the same the definition of the Laplace operator in vector analysis.) E E 1 user interface of unicode-math and fontspec, they are 1 8휋퐺 based on different T X engines, LuaT X and XeT X, ʅʆ ʅʆ ʅʆ ʅʆ E E E 푅 − 푅푔 + 훬푔 = − ƨ 푀 .. which differ significantly in their implementations of 2 푐푐 math typesetting algorithms. Figure 5: Comparison of math typesetting from XeLaT X (red) Comparing the results of LuaLaT X and ConT Xt E E E and LuaLaTEX (blue) using Cambria Math. (The example shows should not be expected to expose any differences in the the Einstein field equation from general relativity.) output from identical math typesetting algorithms, but 1 if there are any differences, a closer analysis should help Analyzing large-scale effects to detect bugs or inconsistencies in the different macro Comparing the different versions for the same font packages and/or in the font loading code. typeset with different engines or macro packages may Comparing the results of LuaLaTEX and XeLaTEX, reveal significant differences at various scales. however, should indeed be expected to expose some If there are any unexpected large-scale effects, such differences in the underlying typesetting algorithms. as using different sizes of delimiters or operators, it is Hopefully, an analysis of these differences should allow usually easy to spot them simply by visual inspection. to draw conclusions how the quality of math is affected In most cases, such obvious differences will turn out to and could be improved by taking advantage of a full- be unintentional and tend to indicate problems or bugs, featured implementation of OpenType math. such as those discussed earlier in this paper.
Testing a sampling of OpenType math Analyzing small-scale effects When we began testing OpenType math support with Once we have applied all the necessary workarounds T X Live 2010, we didn’t have time to do systematic and E and bug fixes to eliminate the unexpected large-scale comprehensive testing, which would have been a very effects, only small-scale effects should remain, affecting time-consuming and tedious task. tiny micro-typographic details, which may be hard to Instead, we wanted to get some quick impressions see without closer inspection. how well OpenType math support worked and if it In order to the study the small-scale effects in more would be ready for practical use, so we concentrated detail, we created another set of more sophisticated test on testing just a sampling of mathematical notations. files using PDF overlays between different versions of Given our personal background in typesetting mathe- the same document using different colors. matical physics, we started by creating a sample test These overlays were generated with PDFLaTEX using document containing a selection of famous equations the pdfpages package as follows: from various fields of physics, sampling various kinds \documentclass[a4paper]{article} of mathematical notations. \usepackage{pdfpages} In addition to testing the available choices of TEX engines and macro packages, we also wanted to test a \begin{document} sampling of the available OpenType math fonts, so we \includepdfmerge[nup=2x1,noautoscale=true, proceeded to typeset identical copies of our test files delta=-21cm 0] % width of A4 paper with different TEX engines and with different choices {xelatex-test.pdf,1,lualatex-test.pdf,1, of math fonts for each of Cambria Math, XITS Math, ... xelatex-test.pdf,n,lualatex-test.pdf,n} Asana Math, and Neo Euler. \end{document} Some examples of typesetting such test pages with different fonts are shown in Figures 8–11, except that This setup will put each page of theE LuaLaT X test file each font sample was usually typeset at least twice with on top of the corresponding page of the XeLaTEX test file. For improved visibility, colors should be chosen in LuaLaTEX and XeLaTEX. In some cases, we also tested an additional version such a way that the darker colors (such as black or blue) will appear on top of the brighter colors (such as red). with ConTEXt MkIV, but unfortunately we had to use a modified version of our test files in such cases. In our example illustrations we have usually used red for XeLaTEX overlaid by blue for LuaLaTEX.
122 Experiences typesetting OpenType math with LuaLaTEX and XeLaTEX CONTEXT MEETING 2010 7
휕 ƨ휙 휕 ƨ휙 휕 ƨ휙 Summary and Conclusions Δ휙(풓) = + + .. In this paper, we have reported our experiences, find- 휕푥 ƨ 휕푦 ƨ 휕푧 ƨ ings and observations from testing OpenType math Figure 6: Comparison of math typesetting from XeLaTEX (red) support in TEX Live 2010 with different TEX engines, and LuaLaTEX (blue) after applying a workaround for XeLaTEX macro packages and fonts. to circumvent inconsistent placement of superscripts. 1 When we set out, we expected to gain some insights how the quality of math typesetting was affected by the 1 8휋퐺 푅ʅʆ − 푅푔 ʅʆ + 훬푔 ʅʆ = − 푀 ʅʆ .. use of additional font parameters in a more sophisti- 2 푐푐 ƨ cated implementation of OpenType math support. In the end, however, it turned out that most of the Figure 7: Comparison of math typesetting from XeLaTEX (red) differences were actually caused by unresolved bugs in and LuaLaTEX (blue) after applying a workaround for XeLaTEX to circumvent inconsistent placement of superscripts. both macro packages and TEX engines, while the use of 1 additional math font parameters appears to be largely irrelevant for our selection of test cases. Analyzing the results of overlays It was only by direct comparison with LuaTEX that Once we have generated overlays of the results from some long-standing bugs or inconsistencies in XeTEX typesetting the same equations with different engines, engine and the unicode-math package could be found. it is easy to detect if any differences occur. However, Without a suitable baseline reference, it is obviously it is far from easy to understand how these differences hard to tell if the spacing of math is exactly right or come about and what their implications might be. just slightly wrong, so it is not surprising that minor In our first series of tests, we originally noticed some inconsistencies went unnoticed for a long time. very significant differences in vertical spacing around Once we applied workarounds or fixes for the prob- fraction bars. Once we detected the problem of XeTEX lems we discovered, the remaining differences between incorrectly using the preloaded set of font parameters different TEX engines turned out to be much smaller and applied a workaround, most differences in vertical than expected and only affected the horizontal spacing, spacing disappeared and only few remained. but no longer the vertical spacing. In our second series of tests, only relatively few Given the scale of the remaining effects, our studies differences remained. Moreover, the remaining effects regarding the quality of math typesetting in different only appeared for some fonts and not for others. While TEX engines remain inconclusive for now. Both engines there were hardly any effects on vertical spacing for can produce very similar results, but XeTEX will do so XITS Math, there were some notable differences in the only after applying a number of fixes and workarounds placement of scripts for Asana Math or Cambria Math, to arrive at what LuaTEX will do by default. as illustrated in Figures 4–5. Upon closer inspection, we eventually found that the Acknowledgements differences only affected some letters within an equa- The author would like to thank the developers involved tion, but not all of them. There were no differences in math-related TEX engines, macro packages and fonts on letters without ascenders or descenders (asin 푥0 for their assistance and feedback during the testing of 2 or 푥 ), while there were differences for superscripts on OpenType math font support in T X Live 2010. 2 E letters with ascenders (as in 휕 ) and also for subscripts In particular, Will Robertson (unicode-math), Khaled on letters with descenders (as in ). The cause of this 휇0 Hosny (luaotfload), Taco Hoekwater (LuaTEX), Hans problem isn’t clear yet, but it most likely indicates an Hagen (ConTEXt), Jonathan Kew (XeTEX), Karl Berry unresolved engine problem in XeT X. E and Peter Breitenlohner (TEX Live 64-bit Linux binaries) In our third series of tests, the remaining effects on contributed to our testing and problem solving efforts vertical spacing could be eliminated completely after in one way or another. we applied a workaround for the placement of scripts, Fortunately, we were able to discover and eliminate and only some effects on horizontal spacing remained, a number of bugs before the deadline of TEX Live 2010 as illustrated in Figures 6–7. pretest. Unfortunately, not all known issues could be The remaining effects on horizontal spacing are most resolved in time, so some problems remain to be fixed likely related to different interpretations of OpenType in future releases. While such fixes for macro packages glyph metrics in different T X engines (such as italic E and fonts can be issued through the TEX Live update corrections and math kerning [18]), which certainly mechanism at any time, fixes for TEX engines may be will have an effect on the quality of math typesetting, delayed until next year’s TEX Live release. but only on a very small scale.
123 8 CONTEXT MEETING 2010 Ulrik Vieth
Cambria Math Example Asana Math Example Vector calculus: Vector calculus: ∂휙 ∂휙 ∂휙 ∂휙 ∂휙 ∂휙 훁휙(풓) = 풆ɝ + 풆ɞ + 풆ɟ , 훁휙(풓) = 풆 + 풆 + 풆 , ∂푥 ∂푦 ∂푧 ∂푥 푥 ∂푦 푦 ∂푧 푧 ƨ ƨ ƨ ∂ 휙 ∂ 휙 ∂ 휙 ∂m휙 ∂m휙 ∂m휙 Δ휙(풓) = + + . Δ휙(풓) = + + . ∂푥ƨ ∂푦ƨ ∂푧ƨ ∂푥m ∂푦m ∂푧m Maxwell equations (differential form): Maxwell equations (differential form):
div 휀Ʀ푬 = 휆 , div 푩 = 0 , div 휀k푬 = 휆 , div 푩 = 0 ,
∂푩 푩 ∂휀Ʀ푬 ∂푩 푩 ∂휀 푬 rot 푬 = − , rot = 풋 + . rot 푬 = − , rot = 풋 + k . ∂푡 휇Ʀ ∂푡 ∂푡 휇k ∂푡 Maxwell equations (integral form): Maxwell equations (integral form):
∫ 휀Ʀ푬 ⋅ d풇 = ∫ 휆 d푉, ∫ 푩 ⋅ d풇 = 0 , ȥ 휀k푬 ⋅ d풇 = ȥ 휆 d푉, ȥ 푩 ⋅ d풇 = 0 , ȱ Ɂ ȱ 퐹 푉 퐹 d d ∮ 푬 ⋅ d풍 = − ∫ 푩 ⋅ d풇 , ǰ 푬 ⋅ d풍 = − ȥ 푩 ⋅ d풇 , Ȯ d푡 ȱ 퐶 d푡 퐹
푩 ∂휀Ʀ푬 푩 ∂휀k푬 ∮ ⋅ d풍 = ∫ (풋 + ) ⋅ d풇 . ǰ ⋅ d풍 = ȥ ʂ 풋 + ʅ ⋅ d풇 . Ȯ 휇Ʀ ȱ ∂푡 퐶 휇k 퐹 ∂푡 Electromagnetic wave equations: Electromagnetic wave equations: ƨ 1 ∂ 푬 1 ∂풋 1 ∂m푬 1 ∂풋 Δ푬 − = 훁휆 + 휇Ʀ , Δ푬 − = 훁휆 + 휇 , 푐ƨ ∂푡ƨ 휀 ∂푡 m m k Ʀ 푐 ∂푡 휀k ∂푡 ƨ 1 ∂ 푩 1 ∂m푩 Δ푩 − ƨ ƨ = −휇Ʀ rot 풋 . Δ푩 − = −휇 rot 풋 . 푐 ∂푡 푐m ∂푡m k Energy-mass equation (special relativity): Energy-mass equation (special relativity):
ƨ m 푚Ʀ푐 푚 푐 퐸 = . 퐸 = k . √1 − 푣ƨ/푐ƨ √1 − 푣m/푐m Einstein ŝield equation (general relativity): Einstein field equation (general relativity): 1 8휋퐺 1 8휋퐺 푅ʅʆ − 푅푔ʅʆ + 훬푔ʅʆ = − 푀ʅʆ . 푅휇휈 − 푅푔휇휈 + 훬푔휇휈 = − 푀휇휈 . 2 푐ƨ 2 푐m Schrödinger equation (quantum mechanics): Schrödinger equation (quantum mechanics): ƨ ∂휓 1 ℏ m Ф ∂휓 1 ℏ iℏ = 퐻 휓 = ( 훁 − 푞푨) 휓 + 푞휙 휓 . iℏ = 퐻ȳ 휓 = ʂ 훁 − 푞푨ʅ 휓 + 푞휙 휓 . ∂푡 2푚 i ∂푡 2푚 i Dirac equation (relativistic quantum mechanics): Dirac equation (relativistic quantum mechanics): ℏ ɺ ℏ 훾 ( ∂ɺ − 푞퐴ɺ) 휓 + 푚Ʀ푐 휓 = 0 . 훼 훾 ʂ ∂훼 − 푞퐴훼ʅ휓 + 푚k푐 휓 = 0 . i i
Figure 8: Sampling of equations typeset with LuaLaTEX using Figure 9: Sampling of equations typeset with LuaLaTEX using Cambria and Cambria Math. TEX Gyre Pagella and Asana Math.
124 Experiences typesetting OpenType math with LuaLaTEX and XeLaTEX CONTEXT MEETING 2010 9
XITS Math Example Neo Euler Example Vector calculus: Vector calculus: ∂휙 ∂휙 ∂휙 ∂ϕ ∂ϕ ∂ϕ 훁휙(풓) = 풆 + 풆 + 풆 , ∇ϕ(퐫) = 퐞x + 퐞y + 퐞z , ∂푥 푥 ∂푦 푦 ∂푧 푧 ∂x ∂y ∂z 2 2 2 ∂2휙 ∂2휙 ∂2휙 ∂ ϕ ∂ ϕ ∂ ϕ Δ휙(풓) = + + . Δϕ(퐫) = 2 + 2 + 2 . ∂푥2 ∂푦2 ∂푧2 ∂x ∂y ∂z Maxwell equations (differential form): Maxwell equations (differential form):
div 휀0푬 = 휆 , div 푩 = 0 , div ε0퐄 = λ , div 퐁 = 0 , ∂퐁 퐁 ∂ε 퐄 ∂푩 푩 ∂휀0푬 rot 퐄 = − , rot = 퐣 + 0 . rot 푬 = − , rot = 풋 + . ∂t μ ∂t ∂푡 휇0 ∂푡 0 Maxwell equations (integral form): Maxwell equations (integral form):
ε 퐄 ⋅ d퐟 = λ dV , 퐁 ⋅ d퐟 = 0 , 휀0푬 ⋅ d풇 = 휆 d푉 , 푩 ⋅ d풇 = 0 , ∫ 0 ∫ ∫ ∫퐹 ∫푉 ∫퐹 F V F d d 퐄 ⋅ d퐥 = − 퐁 ⋅ d퐟 , 푬 ⋅ d풍 = − 푩 ⋅ d풇 , ∮ dt ∫ ∮퐶 d푡 ∫퐹 C F 퐁 ∂ε 퐄 푩 ∂휀0푬 0 ⋅ d풍 = 풋 + ⋅ d풇 . ⋅ d퐥 = 퐣 + ⋅ d퐟 . ∮ μ0 ∫ ( ∂t ) ∮퐶 휇0 ∫퐹 ( ∂푡 ) C F Electromagnetic wave equations: Electromagnetic wave equations: 2 1 ∂2푬 1 ∂풋 1 ∂ 퐄 1 ∂퐣 Δ푬 − = 훁휆 + 휇 , Δ퐄 − = ∇λ + μ0 , 2 2 0 c2 ∂t2 ε ∂t 푐 ∂푡 휀0 ∂푡 0 2 1 ∂2퐁 1 ∂ 푩 Δ퐁 − = −μ rot 퐣 . Δ푩 − = −휇0 rot 풋 . 2 2 0 푐2 ∂푡2 c ∂t Energy-mass equation (special relativity): Energy-mass equation (special relativity): 2 m c2 푚0푐 E = 0 . 퐸 = . 1 − v2/c2 √1 − 푣2/푐2 √ Einstein field equation (general relativity): Einstein field equation (general relativity): 1 8πG 휇휈 1 휇휈 휇휈 8휋퐺 휇휈 µν µν µν µν 푅 − 푅푔 + 훬푔 = − 푀 . R − Rg + Λg = − 2 M . 2 푐2 2 c Schrödinger equation (quantum mechanics): Schrödinger equation (quantum mechanics):
2 2 ∂휓 1 ℏ ∂ψ 1 ¯h iℏ = 퐻̂ 휓 = 훁 − 푞푨 휓 + 푞휙 휓 . i¯h = Ĥ ψ = ∇ − q퐀 ψ + qϕ ψ . ∂푡 2푚( i ) ∂t 2m( i ) Dirac equation (relativistic quantum mechanics): Dirac equation (relativistic quantum mechanics):
훼 ℏ α ¯h 훾 ∂ − 푞퐴 휓 + 푚 푐 휓 = 0 . γ ∂α − qAα ψ + m0c ψ = 0 . ( i 훼 훼) 0 ( i )
Figure 10: Sampling of equations typeset with LuaLaTEX using Figure 11: Sampling of equations typeset with LuaLaTEX using XITS and XITS Math. TEX Gyre Pagella and Neo Euler.
125 10 CONTEXT MEETING 2010 Ulrik Vieth
References [ 17 ] Taco Hoekwater: LuaTEX Reference Manual. http://www.luatex.org/svn/trunk/manual/ [ 1 ] TEX Users Group: Testing TEX Live before release. luatexref-t.pdf http://tug.org/texlive/pretest [ 18 ] Taco Hoekwater: Math in LuaTEX 0.40. [ 2 ] Barbara Beeton, Asmus Freytag, Murray Sargent III: MAPS, 38:22–31, 2009. Unicode Support for Mathematics. http://www.ntg.nl/maps/38/04.pdf Unicode Technical Report UTR#25. 2001. [ 19 ] Hans Hagen: Unicode Math in ConT Xt. http://www.unicode.org/reports/tr25/ E MAPS, 38:32–46, 2009. [ 3 ] Barbara Beeton: Unicode and math, a combination http://www.ntg.nl/maps/38/05.pdf whose time has come. TUGboat, 21(3):174–185, 2000. [ 20 ] Will Robertson: Advanced font features with XeTEX: Proceedings of TUG 2000, Oxford, UK. The fontspec package. TUGboat, 26(3):215–223, 2005. http://www.tug.org/TUGboat/tb21-3/tb68beet.pdf http://www.tug.org/TUGboat/tb26-3/ [ 4 ] Barbara Beeton: The STIX Project – From Unicode tb84robertson.pdf to fonts. TUGboat, 28(3):299–304, 2007. [ 21 ] Will Robertson: The fontspec macro package. Proceedings of TUG 2007, San Diego, CA, USA. http://www.ctan.org/pkg/fontspec http://www.tug.org/TUGboat/tb28-3/tb90beet.pdf http://github.com/wspr/fontspec [ 5 ] Ulrik Vieth: Math Typesetting inE T X: The Good, [ 22 ] Will Robertson: The unicode-math macro package. The Bad, The Ugly. MAPS, 26:207–216, 2001. http://www.ctan.org/pkg/unicode-math Proceedings of EuroTEX 2001, Kerkrade, Netherlands. http://github.com/wspr/unicode-math http://www.ntg.nl/maps/26/27.pdf [ 23 ] Aditya Mahajan: Integrating Unicode and OpenType [ 6 ] OpenType Specification, Version 1.6. math in ConT Xt. TUGboat, 30(2):243–246, 2009. http://www.microsoft.com/typography/otspec/ E Proceedings of TUG 2009, Notre Dame, IN, USA. [ 7 ] Murray Sargent III: Math in Office Blog. https://www.tug.org/members/TUGboat/tb30-2/ http://blogs.msdn.com/murrays/default.aspx tb95mahajan-cmath.pdf [ 8 ] John Hudson, Ross Mills: Mathematical Typesetting: [ 24 ] Khaled Hosny et al.: The luaotfload macro package. Mathematical and scientific typesetting solutions. http://www.ctan.org/pkg/luaotfload Promotional Booklet, Microsoft, 2006. http://github.com/khaledhosny/luaotfload [ 9 ] Daniel Rhatigan: Three typefaces for mathematics. [ 25 ] Will Robertson: Unicode mathematics in LaTEX: Dissertation for the MA in typeface design, 2007. advantages and challenges. http://www.typeculture.com/academic_resource/ To appear in TUGboat, 31(2):⁇?–⁇?, 2010. articles_essays/pdfs/tc_article_47.pdf Proceedings of TUG 2010, San Francisco, CA, USA. [ 10 ] Murray Sargent III: Unicode Nearly Plain Text https://www.tug.org/members/TUGboat/tb31-2/ Encodings of Mathematics. tb98robertson.pdf Unicode Technical Note UTN#28, 2006. [ 26 ] Ulrik Vieth: Experiences typesetting mathematical http://www.unicode.org/notes/tn28/ physics. MAPS, 39:166–178, 2009. [ 11 ] George Williams: FontForge: Math typesetting Proceedings of EuroTEX 2009, Delft, Netherlands. information. https://www.tug.org/members/TUGboat/tb30-3/ http://fontforge.sourceforge.net/math.html tb96vieth.pdf [ 12 ] Ulrik Vieth: Do we need a ‘Cork´ math font [ 27 ] Apostolos Syropoulos: Asana Math Font. encoding? TUGboat, 29(3):426–434, 2008. http://www.ctan.org/pkg/asana-math Proceedings of TUG 2008, Cork, Ireland. [ 28 ] Khaled Hosny: XITS Fonts. http://www.tug.org/TUGboat/tb29-3/tb93vieth.pdf http://www.ctan.org/pkg/xits [ 13 ] Ulrik Vieth: OpenType Math Illuminated. Reprinted http://github.com/khaledhosny/xits-math in TUGboat, 30(1):22–31, 2009. [ 29 ] STIX Consortium: STIX Fonts. Proceedings of BachoTEX 2009, Bachotek, Poland. http://www.stixfonts.org/ http://www.tug.org/TUGboat/tb30-1/tb94vieth.pdf http://www.ctan.org/pkg/stix [ 14 ] Bogusław Jackowski: Appendix G Illuminated. [ 30 ] Khaled Hosny: Neo Euler Font. TUGboat, 27(1):83–90, 2006. http://github.com/khaledhosny/euler-otf Proceedings of EuroTEX 2006, Debrecen, Hungary. [ 31 ] Hans Hagen, Taco Hoekwater, Volker RW Schaa: http://www.tug.org/TUGboat/tb27-1/ Reshaping Euler: A collaboration with Hermann tb86jackowski.pdf Zapf. TUGboat, 29(3):283–287, 2008. [ 15 ] Ulrik Vieth: Understanding the æsthetics of math http://www.tug.org/TUGboat/tb29-2/ typesetting. Biuletyn GUST, 5–12, 2008. tb92hagen-euler.pdf Proceedings of BachoTEX 2008, Bachotek, Poland. http://www.gust.org.pl/projects/e-foundry/ math-support/vieth2008.pdf [ 16 ] Jonathan: Kew: XeTEX Live. TUGboat, 29(1):151–156, Ulrik Vieth 2008. Vaihinger Straße 69 Proceedings of BachoTEX 2007, Bachotek, Poland. 70567 Stuttgart http://www.tug.org/TUGboat/tb29-1/tb91kew.pdf Germany ulrik dot vieth (at) arcor dot de
126