[XeTeX] More info on segfaults in unicode-math on linux 64 bit

[ulrik.vieth at arcor.de]

 ---- Original Nachricht ----
Von:     wodzicki at math.berkeley.edu
An:      Unicode-based TeX for Mac OS X and other platforms <xetex at tug.org>
Datum:   17.06.2010 15:44
Betreff: Re: [XeTeX] More info on segfaults in unicode-math on linux 64 bit

> I did myself some testing today with TeXLive 2010 installed on 64-bit
> Fedora 13 using the experimental TeXLive 2010 repository for Fedora 13
> which is maintained by Jind?ich Nový
> 
>   http://jnovy.fedorapeople.org/texlive/
> 
> In my case, I report *no* segmentation faults when compiling XeLaTeX
> sources with lots of mathematics and unicode-math loaded with \setmathfont
> and \setmainfont directives in the preamble (I use \setmathfont with no
> potions and \setmainfont with options: 'Numbers=OldStyle,Mapping=tex-text'
> ; I did the testing with XITS fonts).

I wonder if it might depend on which font is used:

The orignal poster used "STIXGeneral" which is essentially a glyph container,
i.e. an OpenType font without a MATH table containing the positioning information.
Maybe the segmentation fault was caused when XeTeX was trying to extract
the information from the MATH table and didn't find any such table.

In your case, you used "XITSMath" which does a have a MATH table added, 
so XeTeX did not run into problems retrieving the MATH information, 
at least no fatal problems that would cause a segementation fault.

> However, I see another problem, probably closely related to the problem
> reported on June 6 by Ulrik Vieth (thread: 'Unicode-math strange results')
> 
>   \bar <any letter symbol>
> 
> places the horizontal bar quite a bit to the left of the actual symbol,
> and, additionally,
> 
>  \left ... \right
> 
> *do not* have any effect, i.e., they do not resize delimiters -- exactly
> as reported by Ulrik.

This problem was confirmed by others as well, but only on 64 bit architectures
(Linux or Solaris). It appears that XeTeX receives a set of 0pt values when
retrieving the MATH info from the font instead of getting the proper values.
Given the set of 0pt values, the incorrect positioning is understandable.

However, the mystery remains why it does get the incorrect values on
64 bit architectures, while everything seems to work OK on 32 bit.
I would suspect that the problem is deeply buried in the library layer.

Regards,
Ulrik Vieth