# [XeTeX] a bug of xltxtra.sty

Ross Moore ross at ics.mq.edu.au
Sun Oct 12 02:50:35 CEST 2008

Hi Ulrike, Vafa, and others,

especially Will Robertson, as this posting relates also to:
"Re: [MacTeX] OS X fonts in LaTeX/alternative figure styles in
Latin Modern"

On 12/10/2008, at 12:26 AM, Ulrike Fischer wrote:

> Am Sat, 11 Oct 2008 23:17:47 +1100 schrieb VAFA KHALIGHI:
>
>> by looking at the log, you have got
>>
>> %%%%%%%%%%%%%
>> Missing character: There is no Ȯ in font
>> [lmroman10-regular]:mapping=tex-text!
>> Missing character: There is no Ǒ in font
>> [lmroman10-regular]:mapping=tex-text!
>> %%%%%%%%%%%%%%%%%%%%

> With xltxtra (or with fontspec+ xunicode) you are using the open type
> fonts of Latin Modern. Without the packages you are using the old cm
> fonts in OT1 encoding.
>
> There is no simple solution to this problem: with xetex it is easy to
> use fonts and -- as it relies on unicode -- you no longer have to
> bother
> with all the encoding stuff but the price is that there aren't good
> fall-backs if glyphs are missing.

Yes, this is correct to some extent: if you use fonts that don't have
the Unicode characters that you want, then you have to do something
But giving up "all the encoding stuff" is quite wrong.

The  xunicode.sty  package provides unicode support in a way that
is completely compatible with all the encoding stuff.
You can use UTF-encoded fonts alongside non-UTF encoded fonts,
provided you correctly declare how each font is encoded, and which
characters it supports...

>
> You will probably have to define "fake" accent commands. In a similar
> case on the xetex list I suggested something like this:

...  LaTeX already provides enough internal commands to work with
accents.
You should *not * need to define any more, and certainly you should
*not* define any new commands to support existing concepts.

>
> "You can try to define other commands to get the accents also with
> fonts
> which don't have the actual chars e.g. (the code isn't perfect, it
> should only show you some possibilities):

Sorry, but going down this path just creates even more
incompatibilities.
You will surely regret this some time in the future, when you try to
reuse older documents that have been prepared this way.

>
> \documentclass{minimal}
> \usepackage{xltxtra}
>
> \makeatletter
> \DeclareTextAccentDefault{\bx}{OT1}
> \DeclareTextCommand{\bx}{OT1}[1]
>    {\hmode at bgroup\o at lign{\relax#1\crcr\hidewidth\ltx at sh@ft{-3ex}%
>      \vbox to.2ex{\hbox{\char22}\vss}\hidewidth}\egroup}
>
> \DeclareTextCommand{\bxx}{EU1}[1]
>    {\hmode at bgroup\o at lign{\relax#1\crcr\hidewidth\ltx at sh@ft{-3ex}%
>      \vbox to.2ex{\hbox{\char"005F}\vss}\hidewidth}\egroup}

One way to remove the warning messages that Vafa reported is
to use the   \UndeclareUTFcomposite  command of  xunicode.sty ;
viz.

%
% ... or use \UndeclareUTFcomposite to cancel a declaration
% when the appropriate code-point is not supported in the
% desired text-font.
%

\UndeclareUTFcomposite[\UTFencname]{x022E}{\.}{O}
\UndeclareUTFcomposite[\UTFencname]{x01D1}{\v}{O}

These will cancel the effect of the following lines in  xunicode.sty

1223: \DeclareUTFcomposite[\UTFencname]{x01D1}{\v}{O}
1345: \DeclareUTFcomposite[\UTFencname]{x022E}{\.}{O}

at least for fonts that are declared with the default encoding.
fontspec.sty   sets the value of  \UTFencname to  'EU'
whereas  xunicode.sty  (without  fontspec ) sets it to be  'U'.

However, with these  \Undeclare....  commands, the reported problem
is not fully solved. What it does is to stop trying to use
the character at  U+0022E  for \.O  but use instead
the "Combining accent" character; i.e.  'O' followed by  U+00307 .

But this combination doesn't seem to work correctly with
the latin-modern fonts.
So instead the fall-back needs to be to use LaTeX's
\set at accent  command to position  U+002D9  over the 'O'.

Here is coding that achieves that, without upsetting anything else,
and don't require any changes in the body of a document.

\makeatletter  %  not needed if within a package

\providecommand\DeclareUTFnoncomposite[4][\UTFencname]{%
\expandafter\expandafter\expandafter\def\expandafter\expandafter
\expandafter\tmp\expandafter\expandafter\expandafter{%
\expandafter\csname\expandafter\string#1\string#3\endcsname}%
\expandafter \expandafter \expandafter\def\expandafter\csname
}%
\makeatother  %  not needed if within a package

\DeclareUTFnoncomposite[\UTFencname]{02D9}{\.}{O}
\DeclareUTFnoncomposite[\UTFencname]{02D9}{\.}{o}
\DeclareUTFnoncomposite[\UTFencname]{02C7}{\v}{O}
\DeclareUTFnoncomposite[\UTFencname]{02C7}{\v}{o}

Now the following should work just fine:

\begin{document}
\. O
\v O
\end{document}

>
>
> \setmainfont{Palatino Linotype}
> \begin{document}
>

We should be a little bit careful about using these
\DeclareUTFnoncomposite   declarations.

Really, for maximum flexibility, these should *not* be used
within a global context, but within the expansion of the command
that sets the font.
In this case, it is the  \rm  command that requests the Latin font.
If this is not going to be the main font for the document (e.g.,
for Vafa's Persian documents, then these \DeclareUTFnoncomposite
commands should be patched into the command that calls the \rm font.
Otherwise they could have an effect on fonts that don't need it.

Alternatively, change the value of the encoding, and use with this
new encoding only those declarations from  xunicode.sty  that setup
the correct actions for characters that are supported in the font.

In a future version of  xunicode.sty  I'll include this new
\DeclareUTFnoncomposite
method, perhaps augmented with some checking to ensure that
valid parameters are supplied whenever it is used.

I may even extend the way accents are handled, to include a check
of whether combining characters are supported in the current font.

> --
> Ulrike Fischer

Hope this helps,

Ross

------------------------------------------------------------------------
Ross Moore                                       ross at maths.mq.edu.au
Mathematics Department                           office: E7A-419
Macquarie University                             tel: +61 (0)2 9850 8955
Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
------------------------------------------------------------------------