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.
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}."