Karthik Chikmagalur <[email protected]> writes:
> 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.
-dvilua
or -dviluatex="command" -dvi
> 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.
Yup, then we should use -xdv instead of -dvi
>>> - 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.
I do not say that we should drop preview.sty. I am just thinking whether
it is compatible with multiple invocations of latex.
> 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.
What about `org-latex-preview--generic-callback'?
I am seeing
(pcase processing-type
('dvipng
(plist-put (cddr img-extract-async) :filter
#'org-latex-preview--dvipng-filter))
('dvisvgm
(plist-put (cddr img-extract-async) :filter
#'org-latex-preview--dvisvgm-filter))
(_
(push #'org-latex-preview--generic-callback
(plist-get (cddr img-extract-async) :success))))
so, it should be possible, with less features, to preview using generic
converter.
The problem may be with dvipng/dvisvgm settings being modified by user,
but I think you can solve that plugging
org-latex-preview--generic-callback when more specific filters cannot
find anything.
>> 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
preview.sty is likely not installed by default in many distros. If it is
the case, we need to document this in the manual.
> 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.
What will happen if users specify incorrect arguments?
Can we use generic fallback if there is a problem with dvisvgm/dvipng output?
> 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.
Why? At the end, it is passed to org-async-task anyway. The only
practical problem is `format-spec' call, but that can be adapted.
>>> 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?
We likely need to codify them, yes. And warn users of consequences of
not following the requirements.
As the last resort, we can make dvipng/dvisvg options constant, but I
want to understand the problems first.
> 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.
It is reasonable to expect that whatever command is provided there, it
should generate a dump in the output directory. That's the same on main
for all the commands in this customization - they should generate
artifact in output directory. Is there anything required on top of that
for the preamble?
I see that the dump name is expected to be (concat basepath ".fmt")
But that's a standard name for latex preamble, I think.
We may document it or expose it as a placeholder to be used in the
command strings.
> 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.
That's the same as on main.
> 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.
Please expose output file as a new placeholder.
For -D, are you sure? If not specified, the resolution will be ignored
in the output, but will it actually break anything?
For -T tight, if omitted, it may look ugly, but if user want it, why not?
--depth/--height appears necessary to detect images generated.
May `org-latex-preview--generic-callback' be used as alternative when
nothing is found? Or we can explicitly demand that the converter should
print generated image names to stdout.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
