[XeTeX] Lucida Math Opentype
Bruno Voisin
bvoisin at mac.com
Tue Feb 22 17:11:16 CET 2005
Le 22 fvr. 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
XeTeX.
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