[XeTeX] First experiences with xetex and some bugs
prohaska at zib.de
Sun Jul 4 23:59:00 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Jul 4, 2004, at 6:48 PM, Jonathan Kew wrote:
> On 4 Jul 2004, at 1:07 pm, Steffen Prohaska wrote:
>> A design decision made in xetex is to completely switch to unicode
>> and don't
>> support any old tex encoding. The changes in the encoding of quotes
>> dashes (--), special characters (\"a, \"o) etc. make it really hard
>> to switch.
>> You either have to recode all your input files or you can't use xetex.
> As pointed out in other messages, this is not really true: (a) if you
> continue using the same legacy fonts, then the same legacy files
> should work; and (b) if you want to use Unicode fonts with legacy
> documents, it is possible to redefine the accent macros and other
> "special character" commands. They're just TeX macros that access
> particular characters in the fonts.
> (Quotes and dashes are trickier in that they require "active
> character" coding if you want to simulate the ligatures of the CM
Well. I think, I wrote from a user's point of view. If I wanted to
continue using legacy documents with legacy fonts, why should I use
xetex? As a first shot I expected to use my legacy documents with *new*
fonts. That was the first thrill :)
If I get you right, you're basically saying that someone had to define
all the special character commands to map the input to unicode (utf-8)?
If one provided a complete mapping, this would solve all the problems?
Or at least I could do this for all the special characters I'm using.
But I never heard anything about "active character" coding and have no
idea how to proceed with this. Isn't there some kind of active
"character coding" already going on in xetex to provide ligatures (ff,
>> I'd like to continue using Yandy's mathtimes or Thierry Bouche's
>> 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 agree. This might be true. The packages basically are telling that
they will not work with the present encoding. But I don't have an idea
how to proceed with this problem. Do you have a link were I can find
more details on 'converting to .otf' format? Right now, I would perhaps
decide to stay with CM. If I got all the encoding stuff mentioned above
working, xetex could be useful for me, nonetheless. It's great work and
I think a pretty cool tool for text only (no math) documents right now.
Thanks Jonathan, for your work!
>> ---+ Bug: Including pdf images
>> ---++ Quick Summary
>> Including certain pdf images breaks font rendering starting with the
>> next page.
>> See the attached test document and the output files created using
>> pdflatex and
> This problem seems to occur when using a PDF that was created by
> Quartz, but not with other PDFs such as from Distiller. Any PDF
> experts here who can inspect the test.pdf file and tell us if it is
> somehow invalid? It sounds like there may be a problem with Quartz PDF
> generation; if we can pin down exactly what's wrong, I'll file a bug
> report with Apple.
I think you're right. All the pdf documents I encountered problems with
were created by Apple's Preview. I copied stuff to the clipboard and
used 'File - New From Clipboard', to get a pdf document, which I saved
to disk. I didn't have problems with other pdfs which were created
using, e.g. xfig. But nonetheless there should be a way to deal with
theses documents. At least pdftex is able to do so.
>> ---+ 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?
I'm not quite sure. Relative to gfx/text.tex test.pdf is in the the
current (the same) directory. Shouldn't the same directory be taken
into account anyway, independently of the \graphicspath? At least this
is how I understand the behaviour of pdflatex after moving test.pdf
around in the directory hierarchy.
PGP Public Key: http://www.zib.de/prohaska/prohaska.pgp
Key id: 0xDA749299
Key fingerprint: 8B59 83A8 A43D E0E2 DEDB D479 3157 2FEA DA74 9299
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
-----END PGP SIGNATURE-----
More information about the XeTeX