Karthik Chikmagalur <[email protected]> writes: >> Can't `org-latex-preview--generic-callback' handle arbitrary converters? >> What do I miss? > > It's tricky, let me explain. > > In the old system previews were generated one at a time, so there was no > issue matching tex file names to image file names, and %O worked by > - taking the tex file basename > - appending ".png" or ".svg" to it as appropriate. > > This does not work in the new system, because one tex file can generate > many image files. So we need some way of > 1. collecting all these image files in the image-converter callback, > 2. and matching latex fragments to the right image files. > > How this collection and matching works depends on whether we are using a > process filter or the sentinel to process the output images, and whether > the process reports the file names of images it has generated. > ... > Under the slow fallback path (--generic-callback), this is a somewhat > easier problem to solve, with some unresolved edge cases. Here is the > logic we are using in --generic-callback: > > (let ((images (file-expand-wildcards > (concat texfile-basename "*." > (plist-get extended-info :image-output-type)) > 'full))) > ;; `images' is sorted by string< > ;; just assign tex fragments to images and cache them: > (cl-loop > for tex-fragment in (plist-get extended-info :fragments) > for image-file in images > do (cache image-file tex-fragment))) > > so the generic callback will work correctly so long as the following > conditions are met: > > 1. The image-converter generates one image per dvi/pdf page, > corresponding to one tex fragment. This means it should generate many > images for a typical run over the Org buffer/section.
I think that typical path is one image per tex fragment per process. > 2. When sorted by string<, the image file names are in the same order as > the pdf/dvi pages. As long as %O is correctly assigned, I think it should not be a problem. > 3. There are as many image files as pdf/dvi pages -- no missing image > files. Can't you assign the fragment numbers to TEX-FRAGMENT plist, so that missing image files can be correctly handled? > If condition 1 is not met, previews will simply not be generated for > fragments 2-# in a run. (Please see my above comment, but I feel that I do not clearly understand condition 1) > This is actually how the imagemagick path works right now. The reason > we can't improve on it is that imagemagick does not provide image file > names that it has finished processing in its stdout. (There may be a > way to do this with CLI flags but we didn't find it when we looked a few > years ago.) > > If the user wants to use some other program, say "plumber", as their > image-converter, it will work with the --generic-callback if it > satisfies the above constraints. But even if plumber does more, like > report image file names in its stdout, it is not sufficient to modify > org-latex-preview-process-alist. The user will also have to write a new > callback or process filter specifically for plumber that handles its > stdout format. Do I understand correctly that you need the converter to process multiple fragments in a single invocation? If yes, can that be approximated by something like (org-async-chain "convert fragment1.tex fragment1.png" "echo fragment1.png" "convert fragment2.tex fragment2.png" "echo fragment2.png" ...) ? > I thought we disabled the aliasing of org-preview-latex-process-alist > to org-latex-preview-process-alist for this reason. Users have to > manually edit the latter to break things now. That's true. But look at the docstring of org-latex-preview-process-alist. If the customizationas are much more limited, we will need to adjust that docstring accordingly. We may even have to completely re-design it, as the old design seemingly does not reflect the new preview system. But the decision about this depends on the discussion about whether we can handle arbitrary processors or not. >> 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. > > This will break all our process filters, whose logic depend on text > parsing of the incomplete process stdout. Maybe, but keep in mind that org-compile-file is a part of org-macs and is not intended to be used only by the latex preview. If you need split output for latex preview, we should make org-compile-file optionally do it, but only optionally. >> Also, inlining images. The current design may interfere with future >> global inlining. (https://list.orgmode.org/orgmode/874iogkwcu.fsf@localhost/) > > This does not seem actionable to me. There is no planned design for > future global inlining that I'm aware of, so I don't know what change to > make here. > > Doesn't it make sense to change the code for inlining LaTeX previews > instead when global inlining is designed in ox-html in the future? My main concern is the fact that `org-html-latex-image-options' is changed in the patch, introducing a brand new feature. In the future, if we implement inlining for all the images, not just for latex fragments, we will need a new global option for that, and the change herein will create compatibility headaches. Also, :inline clashes with `org-html-inline-image-rules' where "inline" has entirely different meaning. > Marking remaining issues in every email now, since it is getting > difficult to keep the email info in sync with my Org tasks > > 1. "%O" handling to minimize breakage. > 2. process output handling when executing an org-async-chain. (Retain > all process stdout in one buffer?) > 3. caption support/fuzzy links to captions for LaTeX fragments in > ox-html > 4. ox-odt feedback > 5. Final cleanup tasks before merging > 6. Global image inlining in ox-html (non-actionable?) > 7. `make repro' produces warnings > 8. Insertion tracking is over-eager, leading to spurious LaTeX fragment > generation in programmatic editing (multiple insert calls in one > function) > > Issues 7 and 8 are being discussed in > https://list.orgmode.org/87cy2ngcr0.fsf@localhost, the rest will be > addressed in this chain. Ok. -- 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>
