Bastien writes: > If you find the time to share your change as a _patch_ (not the whole > updated Elisp function), that will allow more readers on this list to > quickly understand what is at stake. Ok, I've finally gotten around to taking a crack at this. The patch is attached. Basically, it allows a lot more control when converting a latex source block into an svg image file. Specifically, this new method does not place any restrictions on the latex contents (the old svg generation required the use of \documentclass[preview]{standalone}), or on the specific generation commands (it does require first compiling to pdf then to svg, though I guess this could be generalized if necessary). Additionally, it allows you to use a setup independent of the setup used for inline latex snippets. I think this is important because snippets and latex source blocks have different use cases. For instance, I use snippets for simple inline math (e.g. \(x=6\)) and source blocks for complicated full-blown latex pictures and sets of equations, etc. that are not supported by latex fragments. I'll present my use case as an example (see the patch to understand the customizations). ;; this is particular to my use case, see `latex-preamble-by-backend' (defun by-backend (blist) (let ((ret nil)) (if org-export-current-backend (let* ((backend-name org-export-current-backend) (elem (assoc backend-name blist))) (if elem (setq ret (cdr elem)))) (let ((elem (assoc t blist))) (setq ret (cdr elem)))) (eval ret))) ;; custom function for preamble generation (defun latex-preamble-by-backend (params) (concat "\\documentclass{" (cdr (assoc :class params)) "}" "\\definecolor{fg}{rgb}{" (by-backend '((html . "0,0,0") (t . (org-latex-color :foreground)))) "}\n" "\\definecolor{bg}{rgb}{" (by-backend '((html . "1,1,1") (t . (org-latex-color :background)))) "}\n" "\\def\\pc{" (by-backend '((html . "100") (t . "20"))) "}\n")) ;; actual set customization (setq org-babel-latex-preamble (lambda (params) (latex-preamble-by-backend params))) Now if I define a source block: #+header: :class math :results file link replace :file tmp/some-file.svg #+begin_src latex :hidden {\color{fg} \begin{equation*} |z| = \sqrt{x^2 + y^2} \end{equation*} } #+end_src Using my customization above, this will turn into the following latex \documentclass{math}\definecolor{fg}{rgb}{0.819608,0.721569,0.592157} \definecolor{bg}{rgb}{0.0235294,0.137255,0.160784} \def\pc{20} \begin{document}{\color{fg} \begin{equation*} |z| = \sqrt{x^2 + y^2} \end{equation*} }\end{document} which is then turned into an svg with inkscape, though this could be dvisvgm, or whatever you want. Math is a custom document class I've defined. But my function also allows the setting of other classes (which is useful because some classes work better for tikz-like images and others work better for math). In fact, since the preamble generation function can use any of the source block parameters, I could make it do a bunch of other conditional stuff. I've also configured it to set my color scheme in a backend-dependent way. This allows me to get color schemes that match my emacs theme when generating images for viewing within emacs and another color scheme (in my case black foreground, white background) when exporting to html. Note that none of this is enforced on other people. My patch simply allows you to achieve this sort of flexibility. I think this patch needs some discussing. I had some trouble deciding on the best way to implement this functionality because its hard to get anything to be thematically consistent with the current latex execute command, which feels like a collection of loosely-related functionality (for instance, the htlatex backend generates a completely different latex source than the imagemagick backend, even though the outputs could be quite similar -- svg and png). I think there's a lot of room for improvement in the latex execute function that could make it more general and flexible, but it's hard to do this in a way that doesn't break existing workflows. My patch tries to be minimally invasive to these workflows, though it will break workflows in an easily recoverable way for anyone using htlatex for svg output. Anyway, I'd be curious to hear thoughts and I'd be interested to discuss options for further refactoring the latex execute function. Matt On Fri, Aug 28, 2020 at 11:10 PM Matt Huszagh wrote: > Bastien writes: > > > If you find the time to share your change as a _patch_ (not the whole > > updated Elisp function), that will allow more readers on this list to > > quickly understand what is at stake. > > Ok, I've finally gotten around to taking a crack at this. The patch is > attached. Basically, it allows a lot more control when converting a > latex source block into an svg image file. > > Specifically, this new method does not place any restrictions on the > latex contents (the old svg generation required the use of > \documentclass[preview]{standalone}), or on the specific generation > commands (it does require first compiling to pdf then to svg, though I > guess this could be generalized if necessary). Additionally, it allows > you to use a setup independent of the setup used for inline latex > snippets. I think this is important because snippets and latex source > blocks have different use cases. For instance, I use snippets for simple > inline math (e.g. \(x=6\)) and source blocks for complicated full-blown > latex pictures and sets of equations, etc. that are not supported by > latex fragments. > > I'll present my use case as an example (see the patch to understand the > customizations). > > ;; this is particular to my use case, see `latex-preamble-by-backend' > (defun by-backend (blist) > (let ((ret nil)) > (if org-export-current-backend > (let* ((backend-name org-export-current-backend) > (elem (assoc backend-name blist))) > (if elem > (setq ret (cdr elem)))) > (let ((elem (assoc t blist))) > (setq ret (cdr elem)))) > (eval ret))) > > ;; custom function for preamble generation > (defun latex-preamble-by-backend (params) > (concat "\\documentclass{" > (cdr (assoc :class params)) > "}" > "\\definecolor{fg}{rgb}{" > (by-backend '((html . "0,0,0") > (t . (org-latex-color :foreground)))) > "}\n" > "\\definecolor{bg}{rgb}{" > (by-backend '((html . "1,1,1") > (t . (org-latex-color :background)))) > "}\n" > "\\def\\pc{" > (by-backend '((html . "100") > (t . "20"))) > "}\n")) > > ;; actual set customization > (setq org-babel-latex-preamble > (lambda (params) > (latex-preamble-by-backend params))) > > Now if I define a source block: > > #+header: :class math :results file link replace :file tmp/some-file.svg > #+begin_src latex :hidden > {\color{fg} > \begin{equation*} > |z| = \sqrt{x^2 + y^2} > \end{equation*} > } > #+end_src > > Using my customization above, this will turn into the following latex > > \documentclass{math}\definecolor{fg}{rgb}{0.819608,0.721569,0.592157} > \definecolor{bg}{rgb}{0.0235294,0.137255,0.160784} > \def\pc{20} > \begin{document}{\color{fg} > \begin{equation*} > |z| = \sqrt{x^2 + y^2} > \end{equation*} > }\end{document} > > which is then turned into an svg with inkscape, though this could be > dvisvgm, or whatever you want. > > Math is a custom document class I've defined. But my function also > allows the setting of other classes (which is useful because some > classes work better for tikz-like images and others work better for > math). In fact, since the preamble generation function can use any of > the source block parameters, I could make it do a bunch of other > conditional stuff. I've also configured it to set my color scheme in a > backend-dependent way. This allows me to get color schemes that match my > emacs theme when generating images for viewing within emacs and another > color scheme (in my case black foreground, white background) when > exporting to html. Note that none of this is enforced on other > people. My patch simply allows you to achieve this sort of flexibility. > > I think this patch needs some discussing. I had some trouble deciding on > the best way to implement this functionality because its hard to get > anything to be thematically consistent with the current latex execute > command, which feels like a collection of loosely-related functionality > (for instance, the htlatex backend generates a completely different > latex source than the imagemagick backend, even though the outputs could > be quite similar -- svg and png). I think there's a lot of room for > improvement in the latex execute function that could make it more > general and flexible, but it's hard to do this in a way that doesn't > break existing workflows. My patch tries to be minimally invasive to > these workflows, though it will break workflows in an easily recoverable > way for anyone using htlatex for svg output. > > Anyway, I'd be curious to hear thoughts and I'd be interested to discuss > options for further refactoring the latex execute function. > > Matt > >