Unicode math issue with LuaLaTeX

17 views
Skip to first unread message

Ulrik Vieth

unread,
Jun 12, 2010, 7:55:51 PM6/12/10
to lua...@tug.org, uni...@googlegroups.com
Hi all,

last week I reported some weird results while testing unicode-math with
xelatex und lualatex.

While the xelatex issue has been confirmed by others and seems to be a
specific problem of 64 bit systems, the luatex issues remained unclear.

I have now done some more testing to investigate what's going on.

My test essentially consists of $\sqrt{x}$ followed by \showlists within
the wrapper of a minimal LuaLaTeX document.

What happens is that the radical rule thickness is caclulated based
on the height of the radical glyph instead (as for TFM fonts) instead of
using the RadicalRuleThicknessParameter (as for OpenType fonts).

(I'm looking at note 2 in section 5.5 of the LuaTeX reference,
which is about the difference between TFM and OpenType fonts.)

Here is the relevant output of \showlist for $\sqrt{x}$:

\mathon
\hbox(15.03995+0.09)x14.78, direction TLT
.\hbox(9.73+2.59)x9.28, shifted -4.90997, direction TLT
..\EU2/XITSMath(0)/m/n/10 √
.\vbox(15.03995+0.09)x5.5, direction TLT
..\kern0.39998 <- should be \kern 0.49997 (RadicalExtraAscender 50)
..\rule(9.73+0.0)x* <- should be \rule 0.66667 (RadicalRuleThickness 66)
..\kern0.49997 <- seems OK \kern 0.49997 (RadicalVerticalGap 50)
..\hbox(4.41+0.09)x5.5, direction TLT
...\EU2/XITSMath(0)/m/n/10 𝑥
\mathoff

Form the log file, it appears that XITSMath is loaded in \fam 4,
but I do not see any \Umathradical... assignments for this font.

Could it be that some of the TFM-based \Umathradical... parameters
from cmsy + cmex in \fam2 + \fam3 are retained instead of applying
the OpenType math parameters from XITSMath in \fam 4?

Traditional \TeX always used to treat \fam2 + \fam3 as the source
of global \fontdimen parameters applicable to all font families.
Does this still hold for LuaTeX? Does it no longer apply for XeTeX?

Could it be that unicode-math.sty is taking an inappropriate approach
by loading the new OpenType math font into a new family, instead of
replacing and overriding the default value in \fam2 + \fam3?

So much for my analysis of the LuaLaTeX problem with unicode-math.
Hopefully, it should be simple now to fix it, once it is understood.

Regards, Ulrik

lua-test-sqrt.zip

Will Robertson

unread,
Jun 13, 2010, 12:34:31 AM6/13/10
to uni...@googlegroups.com
On 13/06/2010, at 9:25 AM, Ulrik Vieth wrote:

[snip excellent analysis]

> Could it be that some of the TFM-based \Umathradical... parameters
> from cmsy + cmex in \fam2 + \fam3 are retained instead of applying
> the OpenType math parameters from XITSMath in \fam 4?

Yes, I think that's exactly what's happening.
This step is automatic in XeTeX, but support hasn't been included yet in LuaLaTeX's luaotfload to pull in the necessary parameters from the font.

I'm going to be pretty busy with TUG2010 and so on so I might not be able to look into this for a little while.

> Traditional \TeX always used to treat \fam2 + \fam3 as the source
> of global \fontdimen parameters applicable to all font families.
> Does this still hold for LuaTeX? Does it no longer apply for XeTeX?
>
> Could it be that unicode-math.sty is taking an inappropriate approach
> by loading the new OpenType math font into a new family, instead of replacing and overriding the default value in \fam2 + \fam3?

It is possible that I'm using the wrong approach here; I naively assumed that this was no longer the case but I may well have been incorrect.

Many thanks for the feedback,
-- Will

Ulrik Vieth

unread,
Jun 13, 2010, 2:35:46 AM6/13/10
to uni...@googlegroups.com
On 06/13/2010 06:34 AM, Will Robertson wrote:
> On 13/06/2010, at 9:25 AM, Ulrik Vieth wrote:
>
> I'm going to be pretty busy with TUG2010 and so on
> so I might not be able to look into this for a little while.

I very well understand about being busy with TUG2010.

Nevertheless, I hope there will be time enough to get a fix for
unicode-math into TeXLive 2010. (Not sure about the schedule.)

Regards, Ulrik

P.S: I also hope that someone might look into the XeTeX issue
with 64bit architectures, but that's another story.

Reply all
Reply to author
Forward
0 new messages