Comparison of XeLaTeX vs. LuaLaTeX - problem with prime

[Ulrik Vieth]

Hi folks,

today I have been testing TL 2010 Pretest on both Linux (64 bit, Ubuntu)
and Windows (32 bit, Windows 7).

On Linux 64, I was unable to test XeTeX because of segmentation faults.
On Windows 32, however, I was finally able to compare the results of
running XeLaTeX vs. LuaLaTeX on identical documents.

One problem I noticed was the size of the prime character, which appears
correct on XeTeX but too small on LuaTeX (see attached PDF).
I very much supect this to be a luaotfload issue.

The test document essentially consists of the following:

\documentclass[a4paper]{article}
\usepackage{fontspec}
\usepackage{unicode-math}

\setmainfont{XITS}
\setmathfont{XITS Math}

\begin{document}
\let\vec=\mathbfit

\tracingall
\begin{displaymath}
\vec{r}'(t) = \vec{r}_{0} + \vec{v} t
\end{displaymath}
\end{document}

For LuaLaTeX I get the following trace output:

...\hbox(8.746+2.598)x57.32278, shifted 143.83861, direction TLT
....\EU2/XITSMath(0)/m/n/10 𝒓
....\hbox(4.746+0.0)x2.433, shifted -4.0, direction TLT
.....\EU2/XITSMath(0)/m/n/7 ′
....\EU2/XITSMath(0)/m/n/10 (
....\EU2/XITSMath(0)/m/n/10 𝑡
....\EU2/XITSMath(0)/m/n/10 )
....\glue(\thickmuskip) 2.77771 plus 2.77771
....\EU2/XITSMath(0)/m/n/10 =
....\glue(\thickmuskip) 2.77771 plus 2.77771
....\EU2/XITSMath(0)/m/n/10 𝒓
....\hbox(4.732+0.098)x3.91, shifted 2.5, direction TLT
.....\EU2/XITSMath(0)/m/n/7 0
....\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
....\EU2/XITSMath(0)/m/n/10 +
....\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
....\EU2/XITSMath(0)/m/n/10 𝒗
....\EU2/XITSMath(0)/m/n/10 𝑡

For XeLaTeX I get the following trace output:

...\hbox(8.08392+1.77)x57.85979, shifted 143.57011, display
....\EU1/XITSMath(0)/m/n/10 glyph#2474
....\hbox(3.955+0.0)x2.88, shifted -4.12892
.....\EU1/XITSMath(0)/m/n/7 glyph#3695
....\EU1/XITSMath(0)/m/n/10 glyph#9
....\EU1/XITSMath(0)/m/n/10 glyph#2424
....\EU1/XITSMath(0)/m/n/10 glyph#10
....\glue(\thickmuskip) 2.77771 plus 2.77771
....\EU1/XITSMath(0)/m/n/10 glyph#30
....\glue(\thickmuskip) 2.77771 plus 2.77771
....\EU1/XITSMath(0)/m/n/10 glyph#2474
....\hbox(4.732+0.098)x4.0, shifted 1.49998
.....\EU1/XITSMath(0)/m/n/7 glyph#17
....\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
....\EU1/XITSMath(0)/m/n/10 glyph#12
....\glue(\medmuskip) 2.22217 plus 1.11108 minus 2.22217
....\EU1/XITSMath(0)/m/n/10 glyph#2478
....\EU1/XITSMath(0)/m/n/10 glyph#2424

In both cases, the prime glyph is taken from the 7pt script font,
shifted upwards by some amount. However, a different version of
the glyphs seems to be used here.

It appears to me that XeLaTeX is using the uni2032.ssty glyph
from the private use area, which is a regular-size prime glyph
to be scaled and shifted upwards, whereas LuaLaTeX is using
the uni2032 glyph, which is a prime glyph designed to be used
at regular size without any scaling and shifting.

Given this observation, I wonder if font loading in luaotfload
correctly applies the +ssty feature to the prime glyph
or whether this is restricted to alphabetic letters only.

Could you investigate this?

Regards, Ulrik

[Khaled Hosny]

I think this related to a bug Will found today, luaotfload didn't
support key=value features prefixed by a plus; i.e. +ssty=1 did not
work, only ssty=1 did, it should be fixed on git.

Another, unrelated, XeTeX vs LuaTeX issues I learned about today:

* The FractionRuleThickness constant seems to be ignored, XeTeX always
uses some default value, the issue doesn't exist with LuaTeX.

* The italic correction is not applied in $P(1+2)$ (with XITS Math), no
problem with LuaTeX.

(see this typophile thread for details http://www.typophile.com/node/71171)

Regards,
Khaled

--
Khaled Hosny
Arabic localiser and member of Arabeyes.org team
Free font developer

[Ulrik Vieth]

On 07/12/2010 12:12 AM, Khaled Hosny wrote:
>
> Another, unrelated, XeTeX vs LuaTeX issues I learned about today:
>
> * The FractionRuleThickness constant seems to be ignored, XeTeX always
> uses some default value, the issue doesn't exist with LuaTeX.

I'm not surprised by this one. XeTeX essentially maps OpenType math
parameters to traditonal TeX fontdimens, so there is only one default
rule thickness (xi_8) which is used for many different things, e.g.
fraction rule, radical rule, spacing based on 3 * rule_thickness, etc.

While LuaTeX tries to cover almost everything in OpenType math,
XeTeX keeps it simply, so this is not really bug: it's a feature.

> * The italic correction is not applied in $P(1+2)$ (with XITS Math),
> no problem with LuaTeX.

That's indeed a problem that probably needs fixing eventually (besides
fixing those nasty segfaults/malfunctions on 64 bit archtictures).

> (see this typophile thread for details http://www.typophile.com/node/71171)

Thanks for the info anyway.

Regards, Ulrik

[Ulrik Vieth]

On 07/12/2010 12:12 AM, Khaled Hosny wrote:

> On Sun, Jul 11, 2010 at 11:57:35PM +0200, Ulrik Vieth wrote:
>>
>> It appears to me that XeLaTeX is using the uni2032.ssty glyph
>> from the private use area, which is a regular-size prime glyph
>> to be scaled and shifted upwards, whereas LuaLaTeX is using
>> the uni2032 glyph, which is a prime glyph designed to be used
>> at regular size without any scaling and shifting.
>>
>> Given this observation, I wonder if font loading in luaotfload
>> correctly applies the +ssty feature to the prime glyph
>> or whether this is restricted to alphabetic letters only.
>
> I think this related to a bug Will found today, luaotfload didn't
> support key=value features prefixed by a plus; i.e. +ssty=1 did not
> work, only ssty=1 did, it should be fixed on git.

I updated the latest luaotfload, fontspec, unicode-math from GitHub
and tried again, but I get same results as before.

It appears that the problem with ssty in LuaLaTeX is not yet fixed.

Regards, Ulrik

[Khaled Hosny]

Well, it turned out to be a two fold problem, first unicode-math should
set mode=base otherwise no glyph substitution feature will work (base as
the default mode few loatfload releases ago, but now it isn't). The
second problem is that luaotfload starts counting from 1 not 0, so the
first alternate should be selected with ssty=1 not ssty=0, I'm not sure
if this can be easily fixed, if not then fontspec and unicode-math need
to adapt.

\documentclass{minimal}

\usepackage{unicode-math}
\setmathfont[
Renderer=Basic,
script-features={RawFeature={+ssty=1}},
]{xits-math.otf}

\begin{document}
$A'''$
\end{document}

[Khaled Hosny]

I was able to fix the alternate selection for base mode to start
counting from zero, but node mode looks much harder, so to avoid self
inconsistency I'll leave this as is, and fontspec/unicode-math have to
live with it.

[Will Robertson]

On 13/07/2010, at 10:38 PM, Khaled Hosny wrote:

> I was able to fix the alternate selection for base mode to start
> counting from zero, but node mode looks much harder, so to avoid self
> inconsistency I'll leave this as is, and fontspec/unicode-math have to
> live with it.

That should be fine; I've updated the code (for both fontspec and u.-m.) and hope users don't get confused. It's documented that the counting starts at zero for features like 'salt', so it shouldn't cause much problem if any.

-- Will

[Ulrik Vieth]

On 07/14/2010 09:25 AM, Will Robertson wrote:
> On 13/07/2010, at 10:38 PM, Khaled Hosny wrote:
>
>> I was able to fix the alternate selection for base mode to start
>> counting from zero, but node mode looks much harder, so to avoid self
>> inconsistency I'll leave this as is, and fontspec/unicode-math have to
>> live with it.
>
> That should be fine; I've updated the code (for both fontspec and u.-m.)

I have tested the updated versions of fontspec/unicode-math/luaotfload.
The problem with prime is prime.ssty in LuaTeX is fixed now.

Regards, Ulrik.