[XeTeX] First experiences with xetex and some bugs

[Bruno Voisin]

Le 4 juil. 04, à 18:48, Jonathan Kew a écrit :

> On 4 Jul 2004, at 1:07 pm, Steffen Prohaska wrote:
>
>> I'd like to continue using Yandy's mathtimes or Thierry Bouche's 
>> mathfont.sty,
>> http://www.ntg.nl/maps/pdf/21_18.pdf . But neither work with xetex. I 
>> read on
>> the mailinglist that xetex is focused on typesetting text only. If 
>> this will
>> be the only focus in the future I think this would be a major problem 
>> for most
>> of the TeX users. I still use TeX especially because of the 
>> simplicity of using
>> math. But the math fonts have to follow the other fonts at least to 
>> some extent.
>> If xetex doesn't provide a way this will be a show stopper for me.
>
> I don't have these fonts/packages, so cannot try them. I suspect that 
> if the fonts were converted to .otf format, similarly to the CM and 
> other fonts bundled with XeTeX, it would be possible to use them just 
> like the CM fonts.

I suspect this might not work, as the problem seems to be not only with 
the MathTime fonts, but also with the Times fonts that it relies on. 
Trying right now to compile a LaTeX file of mine, using the MathTime 
1.1 fonts, with XeTeX:

- If I use T1 encoding, then no warning pops up, but the Times fonts 
(used for text and for Roman letters in maths) are not visible in the 
PDF file. This means, for maths, the MTMI part of the MathTime fonts 
(i.e., the MathTime equivalent of CMMI), which uses the virtual font 
mechanism to extract characters from the Times Italic font and add to 
it some characters from RMTMI (an italic "v" visually more different 
from the Greek letter nu, dotless i and j, an \ell, etc.). The MTSY and 
MTEX fonts, by contrast, which are the MathTime substitutes for CMSY 
and CMEX and do not use virtual fonts, are displayed correctly in the 
PDF file. This behaviour is probably linked with the fact that I have 
the fonts RMTMI, MTSY and MTEX in Classic format in /System 
Folder/Fonts/.

- If I use LY1 encoding, the same as above arises, but in addition I 
get the warnings:

*** font ptmr8y (NimbusRomNo9L-Regu: file 'utmr8a') not found
*** font ptmb8y (NimbusRomNo9L-Medi: file 'utmb8a') not found
*** font ptmri8y (NimbusRomNo9L-ReguItal: file 'utmri8a') not found

There may be an additional difficulty that I have noticed recently, and 
for which TeX is to blame rather than XeTeX: a peculiarity of TeX, 
inherited from the epoch of 7-bit fonts, is the fact that accents in 
maths mode (\hat \tilde etc.) are taken from the text font, as may be 
verified in the Appendix on fonts in the TeXBook. Accordingly, if in 
XeTeX you replace the default text font (CMR) by an AAT font, the math 
accents will no longer be available.

In plain TeX it's relatively easy to find a cure, by defining a new 
font family based on CMR, and refining the math accents to be taken 
from this family. In LaTeX this is probably also possible; however, 
given the intricacy and rigidity of LaTeX2e's font selection scheme, I 
couldn't figure out in any reasonable amount of time how this could be 
done, and gave up.

>> ---+ Problem: \graphicspath
>> ---++ Quick Summary
>>
>> \graphicspath works different in xetex and pdftex. See the attached 
>> test document.
>>
>
> In XeTeX, the \XeTeXpdffile command looks for the given file relative 
> to the location of the current TeX input file. So the second test, 
> which \input's the file "gfx/test.tex", then looks relative to that 
> file; but I assume \graphicspath prefixes "gfx/" to the name given, so 
> it ends up looking for "gfx/gfx/test.pdf", relative to the top-level 
> file, and of course that path doesn't exist.
>
> I'm guessing based on this example that pdfTeX always looks for 
> graphics files relative to the top-level input file instead. Can 
> others confirm this, and tell me whether I should change the behavior 
> in XeTeX?

There seems to be two problems involved:

- The one you describe, linked with XeTeX, and which is cured in this 
particular case by adding in test.tex the line:

	\graphicspath{{./}}

The doc file grfguide.pdf for the graphics package says on p. 13 "Note 
that LATEX will find the graphics file by searching along TEXINPUTS 
(and possibly other places, as specified with \graphicspath)" and on p. 
12 "The default setting of this path [i.e. \graphicspath] is 
\input at path that is: graphics files will be found wherever TEX files 
are found"; is this linked with your explanation?

- Another, linked with (I guess) xetex.def, and which is cured by 
replacing in test.tex the line:

	\includegraphics[width=0.8\textwidth]{test}

by

	\includegraphics[width=0.8\textwidth]{test.pdf}

namely by adding the extension .pdf explicitly. I had also remarked 
this need for adding the .pdf extension explicitly in my own input 
files when using XeTeX (which is logical in some way since XeTeX has no 
preferred graphic format). My interpretation was that xetex.def did not 
define a default extension, while pdftex.def did; however, looking more 
closely, I cannot find anything about a default extension in either the 
doc for the graphics package, or in the source code of xetex.def and 
pdftex.def, or in 
/usr/local/teTeX/share/texmf.tetex/tex/latex/config/graphics.cfg.

Also, why test (without the .pdf extension) can be used in the main 
input file while test.pdf is required in the secondary file test.texs 
is beyond my comprehension. Possibly this is linked with p. 12 of 
grfguide.pdf which says: "Note that if the extension is not specified 
in the \includegraphics command, the graphics file must exist at the 
time LATEX is run, as the existence of the file is used to determine 
which extension from the list to choose. However if a file extension is 
specified, e.g. \includegraphics{a.ps} instead of \includegraphics{a}, 
then the graphics file need not exist at the time LATEX is used."

Hope this helps,

Bruno Voisin