12

I understand that XeTeX was written to handle UTF-8 input better than pdfTeX. However, it seems to process documents in a slightly different way. That is, documents that don't use special fonts or need UTF-8 encoding still compile differently from the two engines.

This site contains many questions along the lines of "How do I get XeTeX to do xyz ?", where xyz is something that works fine with pdfTeX. I understand that XeTeX and pdfTeX do handle internals differently; my question is "Do they have to?" Is it possible to have XeTeX handle fonts/input differently, but once this is accomplished, it handles everything else exactly the same way as pdfTeX? Or is the issues of input encoding and fonts so fundamental that things necessarily have to be different, and workarounds must constantly be made to match outputs from the different engines?

GregH
  • 3,499
  • if you want a unicode aware tex that is closer to pdftex you should probably look at luatex. luatex extends the pdftex base but xetex extends the classic (dvi) tex base and then uses a dvi driver to generate pdf. – David Carlisle Feb 08 '13 at 14:38
  • 1
    Can you give a minimal example of a document that compiles differently? – egreg Feb 08 '13 at 15:04
  • In terms of "plain text," no (although I seem to recall reading somewhere that the line-breaking algorithm between the two is slightly different.) Graphics seem to be handled differently. The crop command of \includegraphics in graphicx package doesn't seem to work; the spy library of tikz doesn't work. These are two that I've run into recently and part of what spawned the question. – GregH Feb 08 '13 at 15:20
  • @GregH The crop issue is solved, and an updated xetex.def should be emerging soon to solve it :-) – Joseph Wright Feb 08 '13 at 15:32
  • This strikes at the heart of my question, which perhaps was too broad (and/or reveals my ignorance of the subject). Why does the issue need to be solved, as in, why is it even there in the first place? Why doesn't xetex just handle pdf internals in the same way as pdftex? (BTW, I am thankful to all who have fixed the crop issue.) – GregH Feb 08 '13 at 15:39
  • @GregH: Clipping is different. It is not done by TeX itself, but is part of the output format, e.g. is done using PDF instructions which are interpreted by the PDF viewer. These instructions need to placed by the TeX driver to the output file. Because XeTeX uses a DVI driver to produce PDF and and pdfTeX produces PDF directly a different clipping driver is required. The things was just that no one did wrote a suitable driver for XeTeX for a while. – Martin Scharrer Feb 08 '13 at 17:46
  • 3
    The answer is simple, your first sentence is wrong, XeTeX was not written to do anything better than PDFTeX; XeTeX is a desendant of TeXGX which was first released in 1996 and was never based on PDFTeX. – خالد حسني Feb 08 '13 at 17:52
  • 1996 seems to be about the same time TeX2PDF (the ancestor of PDFTeX) was created, so I think it is safe to say they were parallelly developed each on its own path. – خالد حسني Feb 08 '13 at 18:00
  • I think Martin's comment answers what I was looking for: inherently, XeTeX uses a DVI->PDF workflow, whereas pdfTeX goes to PDF directly. Hence the workarounds for things like clipping. Thanks to all. – GregH Feb 08 '13 at 19:09

1 Answers1

11

To round up the comments and not leave this unanswered, xetex is based on (dvi) TeX and generates (extended) dvi which is then converted to pdf via the dvipdfmx driver. luatex in contrast is based on pdftex sources. Thus inclusion of graphics and other features requiring driver support differ, just as in classic tex the support for different file formats, clipping and colour varies between different dvi drivers.

Moreover, in order to circumvent some problems related to the OpenType font support, XeTeX has a different hyphenation algorithm, which might lead to different line breaks. The algorithm is actually essentially the same, but it's performed at a different stage.

egreg
  • 1,121,712
David Carlisle
  • 757,742