# org-mode tikz drawing behavior abnormal

In below example, the text should be show on the right side if compile the latex code with pdflatex command. but in org-mode, the right side text missed:

#+HEADER: :fit yes :imagemagick yes :iminoptions -density 300
#+BEGIN_SRC latex :file sidebyside_20190530.png :results raw file :exports both
\newtcblisting{mybox}{%
text side listing,
lefthand width=1.5cm,
}
\begin{mybox}
\begin{tikzpicture}
\draw[thick, blue] (1,0) -- (0,0) -- (0,1) -- cycle;
\end{tikzpicture}
\end{mybox}
#+END_SRC


Current output image is:

But the actually output should be (if compile from console by pdflatex):

Code almost the same but org-mode latex will lost the right side text!

• Believe it or not, this appears to be a pdflatex and/or tcolorbox issue, not an Emacs one! From inspecting the Emacs code, org-babel is running the following shell command pdflatex -interaction nonstopmode -output-directory /tmp/babel-QnyHjn/ /tmp/babel-QnyHjn/latex-LFrgkY.tex (with different random letters each time). When I run this exact command locally in the shell (i.e. in the directory of this file), it compiles fine. When I run this command from a different directory in the shell, I get the same output as you. The log gives a missing number error for "l.39 \end{mybox}." – D. Gillis Jun 1 '19 at 6:35

Solution

The problem here is caused by the listingsutf8 library (as well as a few other things, described below). The listingsutf8 library is automatically loaded by the most option when importing tcolorbox with usepackage. Removing the most option here will prevent listingsutf8 from being loaded which will allow the source text to show up in the output image.

If you need to use some of the other libraries loaded by most, it's worth noting that tcolorbox has a many option that loads most of the libraries loaded by most. You can import in any additional libraries you need with \tcbuselibrary, as you did with the listings library.

Explanation

The listings package requires that the source text it reads is encoded using a single-byte encoding. The listingsutf8 package was designed to add support for UTF-8 encoded text by parsing the source text into a single-byte encoding. To do this, it first must read the .listing file from disk in order to parse it (see the manual for listingsutf8 for more information). This .listing file is expected to be in the current working directory. This package is set up to automatically perform this encoding once it is loaded.

TeX is unaware of what directory the input file is located in or if there is an output-directory option that was passed into it. It only knows the name of the file it is compiling, minus its extension. Org Babel calls LaTeX code by making a .tex file in a temporary directory, and then calls pdflatex to compile it with the option output-directory set to this temporary directory, which causes all output files (including the .listing file) to be generated in the temporary directory. Since the working directory of the org-mode buffer is not this temporary directory and since the .listing file is not in the working directory, listingsutf8 is not able to find the .listing file to parse. This is why nothing appears in the right hand side of the output box when compiling your code through Org Babel.

The listings package without listingsutf8 does not need to read the .listing file that it generates, which is why not loading listingutf8 allows this TeX code to compile as expected no matter what the current working directory is.

If the exact same compilation command is run from the temporary directory then the code will compile correctly since listingsutf8 will be able to find the .listing file. Similarly, if the .listing file is present in the working directory (e.g. if you moved it there), then the listingsutf8 will pass that into listings. This latter option is a bad idea, however, since this .listing file is not generated by the compilation process and is thus not guaranteed to be in sync with the source code.