15

The following example behaves badly in LuaLatex:

\documentclass{article}
\usepackage{amsmath}
\usepackage[lite]{mtpro2}
\begin{document}
\[ x = \ccases{ x & 1,\\x & 2,\\x & \text{otherwise} } \]
\end{document}

With pdflatex (pdfTeX 3.14159265-2.6-1.40.15 (TeX Live 2014/W32TeX)) I get the following:

enter image description here

And, with lualatex (LuaTeX, Version beta-0.79.1 (TeX Live 2014/W32TeX) (rev 4971)) I get the following:

enter image description here

Why? And, is it fixable?

1
  • I can replicate this problem with MacTeX2014 (LuaTeX 0.79.1, rev 4917). My version of the mtpro2 package is 2.3, dated 2009/4/27.
    – Mico
    Mar 9, 2015 at 6:10

2 Answers 2

19
+50

With the following experiment, I get different results during the run:

\documentclass{article}
\usepackage{amsmath}
\usepackage[lite]{mtpro2}
\usepackage{etoolbox}

\makeatletter
\patchcmd{\PEX@}{\ifdim}{\showthe\dp\Pbox@\ifdim}{}{}
\makeatother

\begin{document}
\[ x = \ccases{ x & 1,\\x & 2,\\x & \text{otherwise} } \]
\end{document}

The \PEX@ macro is used to decide the extension font to be used, either mt2exa (straight braces) or mt2exe (curly braces).

When compiling with pdflatex, the run stops twice with

> 41.53998pt.
\PEX@ ...setbox \z@ \hbox {#1}\showthe \dp \Pbox@ 
                                                  \ifdim \dp \Pbox@ >\dp \z@...
l.11 ...es{ x & 1,\\x & 2,\\x & \text{otherwise} }
                                                   \]
? 
> 42.0pt.
\PEX@ ...setbox \z@ \hbox {#1}\showthe \dp \Pbox@ 
                                                  \ifdim \dp \Pbox@ >\dp \z@...
l.11 ...es{ x & 1,\\x & 2,\\x & \text{otherwise} }
                                                   \]
? 

while with lualatex I get a single stop with

> 0.0pt.
\PEX@ ...setbox \z@ \hbox {#1}\showthe \dp \Pbox@ 
                                                  \ifdim \dp \Pbox@ >\dp \z@...
l.11 ...ases{ x & 1,\\x & 2,\\x & \text{otherwise} }
                                                   \]
? 

This seems to be evidence that something is going wrong.

Actually, the box that's being measured turns out to be very different when pdflatex or lualatex are used: with pdflatex we get

> \box29=
\vbox(0.45999+41.53998)x7.67
.\hbox(0.45999+17.54)x7.67
..\LMP3/mtt/m/n/10 1
.\hbox(0.0+6.0)x7.67
..\LMP3/mtt/m/n/10 C
.\hbox(0.45999+17.54)x7.67
..\LMP3/mtt/m/n/10 A

while lualatex shows

> \box29=
\vbox(41.99997+0.0)x7.67, direction TLT
.\hbox(0.45999+17.54)x7.67, direction TLT
..\LMP3/mtt/m/n/10 1
.\hbox(0.0+6.0)x7.67, direction TLT
..\LMP3/mtt/m/n/10 C
.\hbox(0.45999+17.54)x7.67, direction TLT
..\LMP3/mtt/m/n/10 A

The box that is being examined contains a \right delimiter, but apparently the models used by pdflatex and lualatex are quite different when such a box is appended. When we look at the box before \PEX@ dismantles it we see, with pdflatex,

...\vbox(0.45999+41.53998)x7.67, shifted -23.05998
....\hbox(0.45999+17.54)x7.67
.....\LMP3/mtt/m/n/10 1
....\hbox(0.0+6.0)x7.67
.....\LMP3/mtt/m/n/10 C
....\hbox(0.45999+17.54)x7.67
.....\LMP3/mtt/m/n/10 A

while lualatex has

...\vbox(41.99997+0.0)x7.67, shifted 18.48, direction TLT
....\hbox(0.45999+17.54)x7.67, direction TLT
.....\LMP3/mtt/m/n/10 1
....\hbox(0.0+6.0)x7.67, direction TLT
.....\LMP3/mtt/m/n/10 C
....\hbox(0.45999+17.54)x7.67, direction TLT
.....\LMP3/mtt/m/n/10 A

The problem can be replicated with a simpler document:

\documentclass{article}
\usepackage[lite]{mtpro2}
\begin{document}
\showboxbreadth=1000 \showboxdepth=1000 \tracingonline=1
\setbox0=\hbox{$\left.\vrule height 25pt\right)$}\showbox0

With pdflatex we see

> \box0=
\hbox(25.0+18.48)x9.26999
.\mathon
.\hbox(25.0+18.48)x9.26999
..\hbox(0.0+0.0)x1.2, shifted -2.51999
..\rule(25.0+*)x0.4
..\vbox(0.45999+41.53998)x7.67, shifted -23.05998
...\hbox(0.45999+17.54)x7.67
....\LMP3/mtt/m/n/10 1
...\hbox(0.0+6.0)x7.67
....\LMP3/mtt/m/n/10 C
...\hbox(0.45999+17.54)x7.67
....\LMP3/mtt/m/n/10 A
.\mathoff

while lualatex shows

> \box0=
\hbox(25.0+18.48)x9.26999, direction TLT
.\mathon
.\hbox(25.0+18.48)x9.26999, direction TLT
..\hbox(0.0+0.0)x1.2, shifted -2.51999, direction TLT
..\rule(25.0+*)x0.4
..\vbox(41.99997+0.0)x7.67, shifted 18.48, direction TLT
...\hbox(0.45999+17.54)x7.67, direction TLT
....\LMP3/mtt/m/n/10 1
...\hbox(0.0+6.0)x7.67, direction TLT
....\LMP3/mtt/m/n/10 C
...\hbox(0.45999+17.54)x7.67, direction TLT
....\LMP3/mtt/m/n/10 A
.\mathoff

If we remove the call to mtpro2, we get, with pdflatex,

> \box0=
\hbox(25.0+18.5002)x10.35
.\mathon
.\hbox(25.0+18.5002)x10.35
..\hbox(0.0+0.0)x1.2, shifted -2.5
..\rule(25.0+*)x0.4
..\vbox(0.39998+41.60042)x8.75002, shifted -23.10022
...\hbox(0.39998+17.60019)x8.75002
....\OMX/cmex/m/n/5 1
...\hbox(0.0+6.00006)x8.75002
....\OMX/cmex/m/n/5 C
...\hbox(0.39998+17.60019)x8.75002
....\OMX/cmex/m/n/5 A
.\mathoff

and, with lualatex,

> \box0=
\hbox(25.0+18.5002)x10.35, direction TLT
.\mathon
.\hbox(25.0+18.5002)x10.35, direction TLT
..\hbox(0.0+0.0)x1.2, shifted -2.5, direction TLT
..\rule(25.0+*)x0.4
..\vbox(42.0004+0.0)x8.75002, shifted 18.5002, direction TLT
...\hbox(0.39998+17.60019)x8.75002, direction TLT
....\OMX/cmex/m/n/10 1
...\hbox(0.0+6.00006)x8.75002, direction TLT
....\OMX/cmex/m/n/10 C
...\hbox(0.39998+17.60019)x8.75002, direction TLT
....\OMX/cmex/m/n/10 A
.\mathoff

so it's not a problem with the fonts, but a problem inherent to how LuaTeX transforms a math list into a horizontal list.

Solution?

Just a hack that's not guaranteed to give exact size of the brace:

\documentclass{article}
\usepackage{amsmath}
\usepackage[lite]{mtpro2}
\usepackage{etoolbox}

\makeatletter
\patchcmd{\PEX@}{\ifdim\dp\Pbox@>\dp\z@}{\ifdim\ht\Pbox@>\dp\z@}{}{}
\makeatother

\begin{document}
\[ x = \ccases{ x & 1,\\x & 2,\\x & \text{otherwise} } \]
\end{document}

enter image description here

2
  • I don't understand the reason of this different behaviour of luatex. Is it a bug of luatex or a feature? If is is a feature, what is its reason? Why did the luatex developers decide to change how a math list is transformed into a horizontal list?
    – User
    Jun 2, 2020 at 9:30
  • @User The LuaTeX manual is very clear in stating that there is no guarantee that it works in the same way as pdftex in all situations.
    – egreg
    Jun 2, 2020 at 9:34
3

Based on egreg's solution, I was able to patch the \SQRT command for slanted root symbol.

Before the patch, the code

$ \epsilon $ is a small positive quantity.

\[ \lim_{n\to +\infty} \SQRT{
    \frac{\displaystyle \int_{-\epsilon}^\epsilon \cos^n x \,\diff x}
    {\displaystyle \int_{-\pi/2}^{\pi/2} \cos^n x \,\diff x}}
  = 1 \]

\[ \PARENS{ \begin{matrix}
    a & b \\
    c & d \\
    e & f \\
    g & h
    \end{matrix} } \]

compiles into the following incorrect result.

Result before the patch

After the patch

\usepackage{etoolbox,ifluatex}
\ifluatex
\makeatletter
\patchcmd{\PEX@}{\dp\Pbox@>\dp\z@}{\ht\Pbox@>\dp\z@}{}{}
\patchcmd{\SQEX@}{\dp\Sbox@>\dp0}{\ht\Sbox@>\dp0}{}{}
\makeatother
\fi

the code compiles into the intended result, as shown below.

Result after the patch

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.