(This is based on my workaround related to my answer to using emoticons with pdflatex — this workaround is discussed in another answer). The gist is: it turns out that in the years after I posted the answer, the behavior of xelatex changed!

Up to TeXLive2018, the PDF files produced by xelatex were “color-neutral”: when \includegraphicsed, they would inherit the current foreground color from the parent document. However, with TeXLive2021 the generated PDF file has color-setting commands. The result: one must binary-edit (unreliable and inconvenient) this PDF file before it may be fully used in other documents. (The details of the change and which postprocessing is needed is discussed in the link above. The core is the following change:)

- q 1 0 0 1 72 -62.967 cm                 BT /F1 9.9626 Tf -72 64.65 Td[<1841>]TJ ET Q
+ q 1 0 0 1 72 -62.967 cm 0 G 0 g 0 g 0 G BT /F1 9.9626 Tf -72 64.65 Td[<1841>]TJ ET Q

Question: is there a way to advice xelatex to not use color-setting commands?

In more detail: with the input file like

\setmainfont{DejaVu Sans}  % https://dejavu-fonts.github.io/

then uncompressing with pdftk file.pdf output uncompress-file.pdf uncompress (every) page’s content looks like what is shown above.

To test color-neutrality, one can include the generated PDF file as in:


(with color-neutral included PDF file the content should be red).

  • 2
    I really don't like it if I have to follow up three links only to understand what a question is about. Please make your question self contained, links should only be references. Feb 24 at 13:04
  • @UlrikeFischer: I wrote it this way because I thought it is self-contained. I thought that the links are needed only to explain the motivations! I still do not understand which parts of the linked questions would help you understand what the question is about. Hints? Feb 25 at 10:57
  • 1
    Your question is missing an example that can be used for a test. Feb 25 at 11:21
  • Yes, thanks! Testing your examples, this became clear — so now I think it is better. Feb 25 at 11:33

1 Answer 1


You can try to compile with

xelatex -output-driver="xdvipdfmx -c" file




it changes the stream from

 q 1 0 0 1 72 769.89 cm 0 G 0 g BT /F1 9.9626 Tf 76.712 -62.765 Td[<001c0023>-28<002b>]TJ 154.421 -567.87 Td[<0052>]TJ ET Q



 q 1 0 0 1 72 769.89 cm BT /F1 9.9626 Tf 76.712 -62.765 Td[<001c0023>-28<002b>]TJ 154.421 -567.87 Td[<0052>]TJ ET Q


As an alternative use lualatex.

  • lualatex works indeed, thanks (with TeXLive2021)! Unfortunately, with xelatex and the driver xdvipdfmx the output (with TeXLive2021) still contains 0 G 0 g. In more detail: the code you gave does not compile; removing the preamble (and uncompressing with pdftk) shows color-setting commands. Feb 25 at 11:13
  • works fine for me in texlive 2021 (it fails in 2020), are you sure that you used the -c option? And there is no need to use pdftk, you can set the compresslevel with the -z option (that is what \pdf_uncompress: is doing). Feb 26 at 11:53
  • Thanks for -z. (Since xelatex and lualatex are useless on my system, I do not know anything about their command-line syntax.) Yes, I’m sure about -c option! Anything else I can do for debugging? Feb 27 at 1:56
  • BTW, while lualatex works (and does not take minute[s] to finish!), it produces wrong PDF. An obsolete version of the requested font is used. Is it a bug, or an expected behavior? Feb 27 at 1:57
  • Same results with -no-pdf and then running xdvipdfmx -c -z 0 emoji-from-list.xdv . The producer is xdvipdfmx (20210318). (Already the first generated object — №6 — contains 0 g 0 G.) Mar 1 at 7:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .