[XeTeX] Various XeTeX issues
jonathan_kew at sil.org
Wed Sep 6 13:48:03 CEST 2006
On 6 Sep 2006, at 12:22 pm, Bruno Voisin wrote:
>> %!TEX TS-program = xelatex
> All went surprisingly well, without any error (after building the
> latest XeTeX from source yesterday night, to avoid the mathchar bug).
(Thanks for the confirmation that this fix worked.)
> I was expecting that, for such things to work in XeTeX, it was as
> least necessary to call the fonts with ":mapping=tex-text".
> Does the fact that things work "out-of-the-box" come from:
> - The use of CM/AMS fonts only?
> - The presence of CM/AMS fonts in Mac Classic (FFIL/LWFN) format in
> my Classic system folder at /System Folder/Fonts/?
> - Jonathan's very clever design of XeTeX?
> - My misunderstanding of the inner workings of XeTeX?
> - A combination of all of the above?
The last. :)
Well, no.... I think the real answer is the first, actually. You
don't need (and can't use) a font mapping when you're using the
standard TeX approach to loading fonts -- i.e., reading a TFM file.
When you use the CM fonts (or others that you're accessing in the
same way, via TFMs), then XeTeX is supposed to behave just like TeX;
so your existing LaTeX accents, etc., should continue to work just as
they always did. The things that mapping=tex-text deals with when
using Unicode fonts (converting --- to em-dash, `` to open-double-
quote, etc) are handled by the lig/kern program in the TFM file.
Incidentally, the xunicode package was also unnecessary for your
document, I believe. You're not using Unicode-encoded fonts, so you
don't need to remap the LaTeX commands to generate Unicode codes. (It
didn't cause any harm, presumably, because LaTeX knows you're using
fonts with T1 or some such encoding, so xunicode's redefinitions
> On a side note: to have a look at cross-compatibility, I compiled the
> LaTeX input file also with XeLaTeX + xdvipdfmx instead of XeLaTeX +
> xdv2pdf, after creating a new TeXShop engine containing:
>> set path= ($path /usr/local/teTeX/bin/powerpc-apple-darwin-current /
>> xelatex -output-driver="xdvipdfmx -q -E" "$1"
> Given that xdvipdfmx doesn't support the TIFF format, I wasn't
> surprised to see that the TIFF figures are absent from the final PDF
> output. What I didn't expect, though, was that the correct (blank)
> space had been reserved in the PDF output, as if XeTeX had correctly
> been able to read a size specification in the TIFF files but xdvipdfm
> had been unable to include these files. Is this correct assumption?
Yes. XeTeX behaves just the same, regardless of which output driver
you're using (for all it cares, you could be generating an .xdv file
with the -no-pdf option). It calls QuickTime to examine the graphic
file, so it knows how big it is; then if you use xdv2pdf, that also
calls QuickTime and therefore can render the TIFF, whereas xdvipdfmx
uses its own platform-independent code and currently doesn't have
(If you were to run the actual xetex job on Linux or Windows, though,
it would be unable to handle the TIFF file at typesetting time; on
those platforms, only JPEG, PNG, BMP and PDF are supported at
present, to match xdvipdfmx's capabilities. I'd like to support
additional formats, including TIFF, but this isn't a high priority to
me at the moment.)
> Finally: I could see no explanation of the -q option to xdvipdfmx,
> recommended by Jonathan. "xdvipdfmx -h" doesn't tell anything about
Oops, I guess it should!
-q is just "quiet mode".... it suppresses most of the default
progress messages that xdvipdfmx would print to the terminal, so you
get a less cluttered run.
(In case of problems, you can change -q to -v or -vv (verbose, or
more verbose) to get some extra details such as fonts being loaded,
which may help identify where things are going wrong.)
More information about the XeTeX