Karthik Chikmagalur <[email protected]> writes:
>> There is still a related concern though.
>> Currently, in the code, you check for 'dvipng/'dvisvgm symbol as
>> processor and go ahead assuming that very specific command line
>> parameters are passed.
>
> There is too much logic in this library specific to dvipng, dvisvgm and
> imagemagick. org-latex-preview-process-alist cannot be used for any
> other image-converter program without many changes across the file. The
> content of these changes will depend on the specific behavior(s) of the
> new image-converter program.
>
> One example of this specific behavior is the suffix the image-converter
> program expects/uses to number images when generating several images
> from a multi-page DVI. There are many others.
>
> So I don't think it's possible to support any image-converter program
> outside of these three.
Can't `org-latex-preview--generic-callback' handle arbitrary converters?
What do I miss?
>> However, nothing prevents users from, say, putting dvisvgm command
>> into dvipng (exaggerated example).
>
> Users who mess with org-latex-preview-process-alist do so at their own
> peril. Honestly I don't see any reason to modify it at all, except for
> use with other libraries like ob-latex.
I am concerned about users who already modified it. Their config may
stop working after the update.
>>>>> - %O placeholder in org-latex-preview-process-alist
>>>>
>>>> This is yet to be discussed. Pending.
>
> I have now added support for %O to the image-converter commands. The
> reason I was hesitant to add it is that the exact form depends on the
> image output type, and it requires hard-coding the behaviors of dvipng,
> dvisvgm and imagemagick. Your suggestion was this:
>
>> %O is "absolute output file name"
>> There is nothing stopping us from
>> doing spec =
>> (?O . ,(shell-quote-argument
>> (concat (expand-file-name texfile-base temporary-file-directory)
>> "%09d.png"))
>
> But the suffix "%09d.png" is different for the three image converter
> programs (dvipng and imagemagick can use the same format). I've now
> added these special cases to org-latex-preview--create-image-async.
> This means that, as mentioned above, it is not possible to drop in a new
> image-converter program into org-latex-preview-process-alist and expect
> it to work out of the box.
I'd say that we should link the ?O value to the dvipng/dvisvgm program,
not to the output type, but I think that before discussing this we
should settle on possibility to use something other than dvipng/dvisvgm
in the alist (above).
> I've also fixed one of the other remaining issues, of specifying a chain
> of processes to org-async-call in a less awkward way. The new API is as
> follows:
>
> org-async-call accepts as its PROC argument a list where the first item
> is the symbol org-async-chain, and the rest are processes to run in
> sequence until one of them fails. Each process can be a string or list,
> with the meanings specified above.
>
> (org-async-call
> '(org-async-chain "cmd1" "cmd2" "cmd3")
> :success #'success-callback
> :failure #'failure-callback
> :buffer (get-buffer-create "*Output Buffer*"))
>
> This form allows for easy specification of an async linear process
> chain. In this case the SUCCESS and BUFFER arguments apply only to the
> final process in the chain, and the other arguments apply to all
> processes.
I think the way org-compile-file works now is that output of all the
command in the chain are dumped into the same buffer. It is handy when
processes throw warnings/errors - one can see problems from all commands
in the chain.
> As a result the png path of org-babel-execute:latex -- which can call
> latex thrice to generate the dvi file -- now works correctly with
> org-latex-preview.
>
> Notes on this design:
>
> Timothy and I discussed alternatives to this, such as specifying the
> list of tasks simply as a list:
>
> (org-async-call '("cmd1" "cmd2" "cmd3") ...) ;all cmds started with
> ;start-process-shell-command
>
> (org-async-call '(("ls "-la" "/tmp") ;started with start-process
> "cmd2" ;with start-process-shell-command
> "cmd3")
> ...)
>
> But this is ambiguous as org-async-call uses a list of strings to mean
> the process should be run via start-process:
>
> (org-async-call '("ls" "-la" "/tmp") ...)
>
> Another possibility is to change the API so that a start-process
> specification uses a vector:
>
> (org-async-call ["ls" "-la" "/tmp"] ...)
>
> Then a list always implies a process chain, and the ambiguity is
> resolved. We can have a chain of processes where some are called with
> start-process:
>
> (org-async-call '("cmd1" ["cmd2" "cmd2-arg1" "cmd2-arg2"] "cmd3") ...)
>
> But in the end I implemented the more explicit
>
> '(org-async-chain "cmd1" "cmd2" ...)
>
> specification. Let me know if you have any suggestions.
I like that it is explicit. [] vs () will create confusion.
> Since ob-latex now works with org-latex-preview, I want to ask if I can
> change 'png to 'dvipng for uniformity here in ob-latex:
>
> (defcustom org-babel-latex-process-alist
> `((png :programs ("latex" "dvipng") :description "dvi > png"
> :message
> "you need to install the programs: latex and dvipng."
> :image-input-type "dvi" :image-output-type "png"
> :image-size-adjust (1.0 . 1.0) :latex-compiler
> ,(if (executable-find "latexmk")
> '("latexmk -f -pdf -latex -interaction=nonstopmode
> -output-directory=%o %f")
> '("latex -interaction nonstopmode -output-directory %o %f"
> "latex -interaction nonstopmode -output-directory %o %f"
> "latex -interaction nonstopmode -output-directory %o %f"))
> :image-converter ("dvipng -D %D -T tight -o %O %f")
> :transparent-image-converter
> ("dvipng -D %D -T tight -bg Transparent -o %O %f")))
> ...)
>
> To be clear, it works as-is with 'png, but using a fallback path in
> org-latex-preview via org-latex-preview--generic-callback.
I think you can rename it, but we need to make sure that we do not break
backwards-compatibility.
> The only remaining issues before merging are the following:
>
> 1. Removing caption support for LaTeX displaymath from ox-html breaks
> use of fuzzy links in some way that I don't understand. Waiting for
> Timothy to look into it as he made this change.
>
> 2. ox-odt feedback needs to be addressed.
>
> 3. Final cleanup tasks before merging:
> - Rebase branch and clean up/squash some commits
> - if-let -> if-let* etc
> - temporary-file-directory -> (temporary-file-directory)
> - Mark all org-latex-preview defcustom package versions as Org 10.0,
> not Org 9.7/9.8.
> - Remove test-org-latex-preview.el
> - Add page breaks and section headers to org-latex-preview for
> forward-page/outline-mode support
> - Final byte-compile/checkdoc warning checks
>
> Apart from your feedback on the %O and process-chain issues from above,
> that's everything I have in my TODO list. If I missed something please
> let me know.
The new requirement that preview.sty should be installed needs to be
documented. (https://list.orgmode.org/orgmode/875x90ecsm.fsf@localhost/)
Also, inlining images. The current design may interfere with future
global inlining. (https://list.orgmode.org/orgmode/874iogkwcu.fsf@localhost/)
In https://list.orgmode.org/orgmode/87qzrkje80.fsf@localhost/, I wanted
to see a bit more information about 'live cache in the docstrings.
We need to document the caveats with indirect buffers in the manual.
(https://list.orgmode.org/orgmode/87o6moje00.fsf@localhost/)
--
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>
