>> - org-latex-and-related-regexp now consults
>> org-highlight-latex-matchers. If that is nil, it falls back to
>> (plist-get org-latex-preview-appearance-options :matchers)
>
> Good idea to mark those places with FIXME for future removal.
> They will need to go after the obsolete variable is removed, but it may
> be tricky to find this compatibility code as it does not use obsolete
> variable name.
Added FIXME.
>>> How does it work now then?
>>
>> I am not sure.
>
> I found why.
> We have
> "latexmk -f -pdf -latex -interaction=nonstopmode -output-directory=%o %f"
> where
> -latex This sets the generation of dvi files by latex, and turns off
> the generation of pdf and ps files.
> -pdf Generate pdf version of document using pdflatex. (If you
> wish to use lualatex or xelatex, you can use whichever of the options
> -pdflua, -pdfxe, -lualatex or -xelatex ap‐
> plies.) To configure latexmk to have such behavior by default,
> see the section on "Configuration/initialization (rc) files".
>
> In our command -latex overrides the effect of -pdf.
> So, -pdf is redundant there and means nothing.
Okay, I think it will work. There are three command line invocations needed:
1. latexmk uses latex to generate dvi files:
latexmk -f -pdf -latex -interaction=nonstopmode -output-directory=%o %f
I have tested it with the new preview system and it works.
2. latexmk uses lualatex to generate dvi files:
I know this is possible with latexmk, but I haven't figured out how
to do it. If we find the right latexmk options, you or I can test
it.
3. latexmk uses xelatex to generate xdv files:
This is also possible, and it should work with org-latex-preview, but
needs to be tested.
>> My understanding of this issue today is the following:
>>
>> - the default :latex-compiler and :image-converter commands in
>> org-latex-preview-process-alist are very finely tuned for
>> performance/speed to support live previews.
>
> That's fine. We do not expect the users to customize this unless they
> really need to.
Okay.
>> - If you customize :latex-compiler, you will also have to customize
>> :image-converter carefully to be compatible. I think the functions
>> --tex-compile-async and --image-extract-async make some assumptions
>> that make it difficult to customize :latex-compiler and
>> :image-converter at all -- the process is inherently more complex than
>> the previous method of calling org-compile-file synchronously.
>
> I do not see anything obvious in --image-extract-async.
> --tex-compile-async has `org-latex-preview--latex-preview-filter', but
> that one should seemingly be ok when preview.sty is not used.
> When preview.sty is used, I am not sure.
There is no way to NOT use preview.sty in org-latex-preview.
Preview.sty is required and previews will not work at all otherwise. We
use macros from preview.sty and log information from its output for
everything.
Assuming preview.sty is available, everything should work if the
:latex-compile command is (i) only one command, and (ii) generates a dvi
or xdv file. The :image-converter command cannot be modified to use
some program that isn't dvisvgm/dvipng/imagemagick. The various process
filters in org-latex-preview are written explicitly for the log output
produced by these.
If preview.sty is missing an appropriate error message is generated.
>> - I have tested that using latexmk in the :latex-compiler does indeed
>> work (with no changes to :image-converter), but I remember that I had
>> to be careful to choose a very specific set of CLI arguments.
>>
>> I don't know what the way forward should be. I haven't changed the
>> docstring of org-latex-preview-process-alist yet.
>
> I'd like to figure out what exactly are additional assumptions in the
> new code.
Repeating the above points, but:
1. Preview.sty is required
2. The :image-converter should be one of dvisvgm/dvipng/imagemagick.
There is some freedom to change the CLI arguments of these calls, but
not much.
3. The :latex-compiler should be a single command and not a list of
commands (like running LaTeX thrice). I am thinking about how to
support this.
latexmk should be fine once we figure out the right CLI arguments to test.
>>> It is important that we use latexmk/triple latex there as it will allow
>>> resolving references. Let's discuss what can be done.
>>
>> Based on the above, latexmk will work, but only with a specific set of
>> CLI arguments. If they want to customize org-babel-latex-process-alist,
>> it's going to be beyond the ability of most users to figure out what
>> these arguments should be.
>
> Why? I think we ourselves need to figure out first what exactly are the
> requirements.
Do you want to codify the requirements that the latex and dvipng
commands in org-babel-latex-process-alist should obey?
Precompilation:
:latex-precompiler
("%l -output-directory %o -ini -jobname=%b \"&%L\" mylatexformat.ltx %f")
Either precompilation should be turned off
(org-latex-preview-process-precompile), or the above command should be
used to generate the preamble dump. I don't remember what can be
changed in this command.
Compilation:
:latex-compiler
("%l -interaction nonstopmode -output-directory %o %f")
The latex compiler command should accept a tex file and generate a dvi,
I don't think there is any other requirement.
Conversion:
:image-converter
("dvipng --follow -D %D -T tight --depth --height -o %B-%%09d.png %f")
:transparent-image-converter
("dvipng --follow -D %D -T tight -bg Transparent --depth --height -o
%B-%%09d.png %f"))
dvipng should be called with the above flags (-D, -T tight, --depth,
--height) and the specified output file format (%B-%%09d.png). --follow
is optional.
Karthik
