[XeTeX] Lucida Math Opentype

Bruno Voisin bvoisin at mac.com
Tue Feb 22 17:11:16 CET 2005

Le 22 fŽvr. 05, ˆ 15:32, Will Robertson a Žcrit :

> I think that provided you write the necessary macros to duplicate the  
> \DeclareMathFont etc etc into accepting unicode-range input, then  
> you're okay. It doesn't work out of the box as I discovered long ago  
> (see example appended at end).
> [...]
> \documentclass{article}
> \usepackage{fontspec}
> \setromanfont{Lucida Grande}
> % yes, this is bad. just the first unicode font that came to mind...
> \AtBeginDocument{% required because of fontspec tomfoolery
>   \DeclareSymbolFont{unimath}{U}{\rmdefault}{m}{n}
>   \DeclareMathSymbol{\Gamma}{\mathord}{unimath}{"0393}
> }
> \begin{document}
> This is Lucida Grande.
> Char test: \char "0393
> Maths test: $\Gamma$
> \end{document}

Yes that doesn't work, as I experienced a couple of months ago  
attempting to use the Apple Symbols font in the caption of a graph. I  
ended up considering the Unicode font as a text font, and incorporating  
it into math formulas using the amsmath package and the \text command:

> \DeclareFontFamily{U}{applsym}{}
> \DeclareFontShape{U}{applsym}{m}{n}{<-> "Apple\space Symbols"}{}
> % The following doesn't work, alas
> %\DeclareSymbolFont{applesymbols}{U}{applsym}{m}{n}
> %\DeclareMathSymbol{\applehighplus}    {\mathord}{applesymbols}{"253C}
> %\DeclareMathSymbol{\appleblacksquare} {\mathord}{applesymbols}{"25A0}
> %\DeclareMathSymbol{\applewhitesquare} {\mathord}{applesymbols}{"0040}
> %\DeclareMathSymbol{\appleblackdiamond}{\mathord}{applesymbols}{"25C6}
> %\DeclareMathSymbol{\applewhitediamond}{\mathord}{applesymbols}{"25C7}
> %\DeclareMathSymbol{\applewhitecircle} {\mathord}{applesymbols}{"25CB}
> %\DeclareMathSymbol{\appleblackcircle} {\mathord}{applesymbols}{"25CF}
> % The following does work
> \DeclareTextFontCommand{\applesymbol}
>   {\normalfont\fontencoding{U}\fontfamily{applsym}\selectfont}
> \DeclareRobustCommand{\applehighplus}     
> {\text{\applesymbol{\char"253C}}}
> \DeclareRobustCommand{\appleblacksquare}  
> {\text{\applesymbol{\char"25A0}}}
> \DeclareRobustCommand{\applewhitesquare}  
> {\text{\applesymbol{\char"25A1}}}
> \DeclareRobustCommand{\appleblackdiamond}{\text{\applesymbol{\char"25C6 
> }}}
> \DeclareRobustCommand{\applewhitediamond}{\text{\applesymbol{\char"25C7 
> }}}
> \DeclareRobustCommand{\applewhitecircle}  
> {\text{\applesymbol{\char"25CB}}}
> \DeclareRobustCommand{\appleblackcircle}  
> {\text{\applesymbol{\char"25CF}}}
> \newcommand  {\medcirc}     {\applewhitecircle}
> \newcommand  {\medbullet}   {\appleblackcircle}
> \renewcommand{\Box}         {\applewhitesquare}
> \renewcommand{\Diamond}     {\applewhitediamond}
> \renewcommand{\square}      {\applewhitesquare}
> \renewcommand{\blacksquare} {\appleblacksquare}
> \renewcommand{\lozenge}     {\applewhitediamond}
> \renewcommand{\blacklozenge}{\appleblackdiamond}

The problem is that XeTeX has extended the TeX primitive \char to  
specify Unicode code points (i.e. from 2 hexadecimal digits to 4  
digits), but not the primitive \mathchar. This is because \mathchar  
takes, in TeX, 4 hexadecimal digits as input, considering the first  
digit as specifying the type of math entity (normal character, binary  
operation, relation, etc.) and the second as specifying the font family  
(math italic, math symbol, math extension, math arrows for Lucida,  
etc.). There is no straightforward way to adapt this tricky syntax to  

There was a thread "[XeTeX] Unicode math, was fontspec 1.5 (& Lucida  
Math)" starting on 4 December 2004 on this topic, and an earlier one  
"[XeTeX] Use of Apple Symbols font in XeLaTeX" starting on 15  
September. In particular, Jonathan Kew explained:

> Le 17 sept. 04, ˆ 12:55, Jonathan Kew a Žcrit :
>> Le 17 sept. 04, ˆ 11:34, Bruno Voisin a Žcrit :
>>> Alas this does not work. I suspect the problem is actually more  
>>> serious: in XeTeX, a two-digit text character declaration such as  
>>> "1C becomes a four-digit one "001C (I think);
>> Well, sort of... they're all just numeric constants. So "1C is really  
>> just another way of saying 28, and "001C is the same.
>>>  but what does become a four-digit math character declaration such  
>>> as "321C, where the first digit refers to the class (relation,  
>>> binary operation, opening delimiter, ordinary character, etc.) and  
>>> the second digit to the font family (1 for math italic, 2 for math  
>>> symbol, 3 for math extension, etc.)?
>> This is also just a number; it equals 12828. The interpretation of  
>> the separate hex digits as distinct "fields" is a "magic convention"  
>> wired into TeX. You could define your mathchars using decimal  
>> constants if you like, and TeX would interpret them just the same.

For solving this problem the Omega guys have introduced an extended  
\mathchar, namely \omathchar. Here's what Jonathan said about the issue

> Le 17 sept. 04, ˆ 14:50, Jonathan Kew a Žcrit :
>> On 17 Sep 2004, at 1:27 pm, Bruno Voisin wrote:
>>> Le 17 sept. 04, ˆ 12:55, Jonathan Kew a Žcrit :
>>>> Does Omega include an extended \mathchar, by any chance? That might  
>>>> provide a model for what should be done, but at present I don't  
>>>> think you can encode character codes > 255 in a \mathchar.
>>> I think that Omega does this, though I cannot say more, not being an  
>>> Omega user myself. From  
>>> /usr/local/teTeX/share/texmf.tetex/doc/omega/base/doc-1.12.ps, p. 6:
>>> ½, on the other hand, allows 256 (2^8) font families, each font of  
>>> 65 536 (2^16) characters. So, in addition to the TEX math font  
>>> primitives, which continue to work, there are 16-bit versions:
>>> [...]
>>> ¥ \omathcharmath code;
>>> [...]
>>> where
>>> [...]
>>> ¥	Ð 3 bits for math category,
>>> 	Ð 8 bits for font family,
>>> 	Ð 16 bits for character in font,
>>> called a math code;
>> OK, so there's an \omathchar that is an extended version of  
>> \mathchar, it seems. I haven't incorporated this into XeTeX, but I'll  
>> look into it when I get a chance. I suspect what we'd need is to add  
>> full support for .ofm (extended .tfm) files, etc., in order to get  
>> metrics for such characters; merely allowing 16-bit character codes  
>> without providing all the math-related metrics for them will not  
>> work.

To what extent TeX or eTeX, upon which XeTeX is based, can be adapted  
from its original 7-bit, then 8-bit, design to the 16-bit Unicode  
design, I wonder. TeX seems so firmly rooted in its 7-bit soil,  
especially when math is involved, that turning it into a good Unicode  
citizen seems like discovering a nightmarish landscape of compatibility  
issues. Probably I'm just getting pessimistic these days...

Bruno Voisin

More information about the XeTeX mailing list