The question is pretty simple.

Compiling this code with PDFLaTeX


gives me back

whereas compiling the same code with XeLaTeX gives me back

I'm curious why this happens, but more importantly, I'd like to know:
How can I force XeLaTeX to avoid doing whatever it does that makes its output render differently like this from the PDFLaTeX output?

In case it matters, I'm running this on MiKTeX 2.9 (Windows).

  • I see no difference between the two methods on my system: MikTeX 2.9 x64. pdflatex v3.1415926-2.5-1.40.14 and XeTeX v3.1415926-2.5-0.9999.3 – Paul Gessler Jul 14 '14 at 23:29
  • @PaulGessler: That's actually exactly the same version I have (even the 64-bit-ness is the same.) What PDF viewer are you using? – user541686 Jul 14 '14 at 23:32
  • I use SumatraPDF. But the result is the same in Adobe Reader and Google Chrome. – Paul Gessler Jul 14 '14 at 23:34
  • @PaulGessler: That's bizarre. Which one of my screenshots does your XeLaTeX output look like? – user541686 Jul 14 '14 at 23:35
  • The first (your pdflatex output). – Paul Gessler Jul 14 '14 at 23:37

I have no idea why this happens, but it seems like the mere presence of the file


causes this issue, even if the file is empty.

Removing the file seems to fix the problem.

| improve this answer | |
  • In TeX Live there is a dvipdfmx.cfg file, which is very important. Probably the (empty?) file in dvipdfm/config is something spurious from older versions of the dvipdfm software. – egreg Jul 15 '14 at 7:55
  • @egreg: It's not "left over", it's generated. See my comment thread under the question itself, the file gets generated when I change the paper size, and it only has 1 non-commented line inside it, but deleting the contents changes nothing. – user541686 Jul 15 '14 at 7:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.