Unicode-math strange results
Ulrik Vieth
I've doing some testing and found a couple of strange issues,
which might be engine-related rather than macro-related.
I have been running my tests using the following versions:
- fontspec, unicode-math, luaotfload from CTAN (today)
- luatex and xetex binaries from context-minimals
luatex --version
This is LuaTeX, Version beta-0.60.1-2010042811
xetex --version
XeTeX 3.1415926-2.2-0.9995.2 (Web2C 7.5.6)
I have found the following problems:
1. Delimiters:
With xelatex, \left and \right delimiters do not grow.
\big, \Big, \bigg, \Bigg produce only the default size.
With lualatex, delimiters are fine (no problem).
2. Radicals:
With xelatex, I only get a radical sign without a bar.
With lualatex, I get a misplaced radical sign with a very thick bar.
(The radical sign should hang below the baseline, but doesn't.)
Enclosed is a zip file with all test sources and log files.
Regards, Ulrik
P.S: Sorry, for cross-posting, but I wasn't sure,
if everyone was following the unimath group.
Khaled Hosny
>
> 2. Radicals:
> With xelatex, I only get a radical sign without a bar.
> With lualatex, I get a misplaced radical sign with a very thick bar.
> (The radical sign should hang below the baseline, but doesn't.)
This usually means the value of RadicalRuleThikness is ignored and the
engine is falling back to the old TeX method (the hight of radical
glyph).
--
Khaled Hosny
Arabic localiser and member of Arabeyes.org team
Free font developer
Khaled Hosny
> On Sun, Jun 06, 2010 at 10:55:13PM +0200, Ulrik Vieth wrote:
> >
> > 2. Radicals:
> > With xelatex, I only get a radical sign without a bar.
> > With lualatex, I get a misplaced radical sign with a very thick bar.
> > (The radical sign should hang below the baseline, but doesn't.)
>
> This usually means the value of RadicalRuleThikness is ignored and the
> engine is falling back to the old TeX method (the hight of radical
> glyph).
I was referring to the lualatex issue.
Ulrik Vieth
>> This usually means the value of RadicalRuleThikness is ignored and the
>> engine is falling back to the old TeX method (the hight of radical
>> glyph).
Yes, but why? It doesn't seem to be font-dependent.
It also happens if I replace Cambria Math by XITS Math.
Could this be an architecture / library-dependent? (Linux, 64 bit)
Regards, Ulrik
Khaled Hosny
I don't think so, it is likely a macro package issue, but we need to do
more bare bone testing (no luaotfload, no fontspec or unicode-math).
Regards,
Khaled
Ulrik Vieth
> Try the attached file with CambriaMath or any OpenType math font but
> please correct the file name!
> A.S.
Hi,
I tried it, and I'm still getting the same problems with plain xetex,
i.e. no big sizes of delimiters, no radical bar, nor fraction bar.
Obviously this is not a macro problem of unicode-math in Xe|LuaLaTeX,
but rather an engine system (at least on my system and possibly others).
I will try to do some more testing on other systems (e.g. windows32),
but I suspect that there is something seriously wrong with xetex or some
of its library dependencies on linux64 architecture.
It looks as if there were problems to extract the proper values of
OpenType MATH parameters from the fonts through the library layer.
Indeed, \showthe\fontdimenNN\1 on font\1=Cambria Math shows values
of 0.0pt throughout for NN between 10 and 65.
Regards, Ulrik
Apostolos Syropoulos
On 06/07/2010 10:08 PM, Apostolos Syropoulos wrote:
Try the attached file with CambriaMath or any OpenType math font but
please correct the file name!
A.S.
I will try to do some more testing on other systems (e.g. windows32), but I suspect that there is something seriously wrong with xetex or some of its library dependencies on linux64 architecture.
I have tested the OpenSolaris 64bit binaries and they exhibit the same problem. On the other
hand the 32bit binary produces correct output. I have used version 3.1415926-2.2-0.9997.1
(TeX Live 2010).
Regards,
A.S.
--
Apostolos Syropoulos
366, 28th October Str.
Xanthi, GREECE