[XeTeX] Various XeTeX issues

[Jonathan Kew]

On 6 Sep 2006, at 12:22 pm, Bruno Voisin wrote:

>> %!TEX TS-program = xelatex
>> \usepackage{xunicode}
>> \DeclareGraphicsExtensions{.tif,.pdf}
>
> 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  
didn't apply.)

> 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:
>
>> #!/bin/tcsh
>>
>> set path= ($path /usr/local/teTeX/bin/powerpc-apple-darwin-current /
>> usr/local/bin)
>> 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  
TIFF support.

(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  
> it.

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.)

JK