Re: File generation from LaTeX src fails due to temporary PDF in wrong directory

[Christian Moe]

chris writes:

> On Wednesday, 29 March 2023 23:15:03 CEST Christian Moe wrote:
>>
>> Hi,
>>
>> Pardon the noise: It turned out to be a pretty obvious problem with my
>> setup that has now been resolved.
>>
>> I had modified org-latex-pdf-process to use xelatex, and for some reason
>> my setup lacked the =-output-directory %o= switch. I should probably
>> have thought of that first, but the omission has had no ill effects on
>> ordinary PDF export, so I didn't run into any problem before trying to
>> use Babel with LaTeX.
>>
>> Ihor and Pedro, thanks for checking.
>>
>> Chris, I don't know why your attempts fail, but I'll be trying similar
>> things over the next days, so maybe I'll come back to you.
>>
>
> For one thing I don't understand 90% of the options, that can explain a lot.
> Another point, the gibberish output I was speaking about are "similar" those
> of
> [[https://emacs.stackexchange.com/questions/68823/minimal-working-example-of-tikz-to-svg-in-orgmode]]
> Actually the svg image they get is an image containing the `tikz` instructions
> transformed as image. What I get is the svg instructions that should generate
> the image: an image showing a `svg` listing.

I am seeing the same problem, and think I have a solution below, but
it's confusing and I'm wondering if other people have this working out
of the box somehow.

The difference between what you are seeing, and what they are seeing in
the stackexchange thread, comes down to whether =:headers
'("\\usepackage{tikz}")= is specified. Without it, all they get is an
SVG of the glyphs in the arguments to the tikz commands. With it, we get
an SVG of the glyphs in the SVG for the image. So when the extension is
.svg, the intermediate PDF that is converted into SVG does not contain
the image, but a listing of the SVG, which has *already* been generated!

The reason, I think, is that org-babel-latex-preamble includes this
definition:

: \def\pgfsysdriver{pgfsys-tex4ht.def}

So what happens, I think, is that tex4ht already generates SVG from the
TikZ code. When Org then uses org-babel-latex-pdf-svg-process to call an
external utility, by default inkscape, to convert the PDF to SVG, we are
converting not an image but a code listing already in SVG.

It is not at all clear to me why tex4ht is invoked in the default
preamble. I wonder if it still serves a purpose. If it makes better SVG
from LaTeX than the other utilities, it would be nice to use it directly
somehow. But perhaps it is just a leftover from a stage in development
when htlatex was used to produce the SVG, before the two-part-process
->PDF->SVG with org-babel-latex-pdf-svg-process was defined. If so it
should probably be changed. Here's the relevant thread, I think, for
people wanting to look into that:

  https://list.orgmode.org/873608ajfn.fsf@bzg.fr/t/


Solution:

Redefine org-babel-latex-preamble to remove
the offending line.

  (setq org-babel-latex-preamble
    '(lambda (_)
      "\\documentclass[preview]{standalone}"))

With this setup, my example

  #+header: :fit yes :headers '("\\usepackage{tikz}")
  #+begin_src latex :exports results :results raw file :file 
test-tikz-triangle.svg
    \begin{tikzpicture}
      \draw[draw=black, fill=blue!10] (0,4) -- (3,0) -- (-3,0) -- cycle;
    \end{tikzpicture}
  #+end_src

exports correctly to an .svg file.

Yours,
Christian