From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QBESLsz9SV/cNgAA0tVLHw (envelope-from ) for ; Sat, 29 Aug 2020 07:03:40 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id MOABKsz9SV/8dwAA1q6Kng (envelope-from ) for ; Sat, 29 Aug 2020 07:03:40 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id B399E9403C9 for ; Sat, 29 Aug 2020 07:03:39 +0000 (UTC) Received: from localhost ([::1]:37160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kButl-0006bu-3L for larch@yhetil.org; Sat, 29 Aug 2020 03:03:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kButI-0006bk-Vq for emacs-orgmode@gnu.org; Sat, 29 Aug 2020 03:03:09 -0400 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:37446) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kButF-0002LF-BL; Sat, 29 Aug 2020 03:03:08 -0400 Received: by mail-lj1-x229.google.com with SMTP id w14so1276379ljj.4; Sat, 29 Aug 2020 00:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xtd8DVQ/TtL4oiBBdQi7A7h0GLdWfqJjRkroK9cK8js=; b=LSmnrJowr3sqh+ocVAQf2HcGHDlEfgCHdgcNHoA2OOKlSo6Lv1WY7OKainUNLkjgur O6p5MNsUzLjMD3V/HQiYtkkWmKof0cofrpSSBRlRyZMVIQNoQIkdv88kQWu46lJ94s4P HzcHWpnOLF9lYXmcUHcRmdlbx1s9y1MJGHd4hsIQ7QP4wRt/QJgC5Fwww/J5ZLXfLOxA oAm2pnJxU4dMWKG82fuoMnm2Uz+r2dkVecH8A6bMQI0Q5BxDRQEGwMqn2VvKvz+5OtZe KaCFgYj0bGeRX6jJszazHBCTb/heCe8PBSpv4fPrU8BhbG8UbMSf2x/+fw1gNfTtdsyj nUAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xtd8DVQ/TtL4oiBBdQi7A7h0GLdWfqJjRkroK9cK8js=; b=ZJEsPx0F1U9M6uHjveeYLKY0IdbKStixlXYlpq0PZnZ4ymVTCl60y+Mx5ibU6QRbjZ f28+cIU6yqP7yE/m1u81RizCLvlqeCU6VujauwwlJeCpoWjWcGcESNnTGBKbDkGlOopn NE/EDiNr9xTkQJR7eU/DNjUgtwWnwx9GLL7soSMkSpX0DfYeQLduFNnbXV74790dEPRv x59YOtH7qcO9S8MEll4zTvBASUiAs+NpFmKgMrcsuobMBqTnlY/jNARq4YRcrckiGdGD SEpVbZxr7b03szjN7u5yabtSayfz1skjNl2JmPhnxrxQkDMYTZD/He6MAf/PzBGfW0vs 4Xcw== X-Gm-Message-State: AOAM530H4jjmgfINE69FstHWhuM6GtAvAOnf717xkcLJPE5PW9GYvJNH 2Vkrq3j43tY6hklOwCWI+wzW44TUt0I6Vz9gG3/lxoRG4aWk0g== X-Google-Smtp-Source: ABdhPJyfgmltt3jAE/qSv/o1pQ9sfFsT/97YPhD9+VPOEq78yITZz57Xw4PQGm/S+R7UGBOFp04hhGEOEtkv/8H1Sj4= X-Received: by 2002:a05:651c:294:: with SMTP id b20mr938682ljo.4.1598684582392; Sat, 29 Aug 2020 00:03:02 -0700 (PDT) MIME-Version: 1.0 References: <874kw6ztr9.fsf@gmail.com> <871rrayrsc.fsf@gmail.com> <87y2thylcb.fsf@gmail.com> <87r1z29abl.fsf@gnu.org> <87y2lynft3.fsf@gmail.com> In-Reply-To: <87y2lynft3.fsf@gmail.com> From: Matt Huszagh Date: Sat, 29 Aug 2020 00:02:51 -0700 Message-ID: Subject: Re: babel latex headers and image generation commands To: Bastien Content-Type: multipart/mixed; boundary="000000000000a47d2105adfec292" Received-SPF: pass client-ip=2a00:1450:4864:20::229; envelope-from=huszaghmatt@gmail.com; helo=mail-lj1-x229.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (body hash did not verify) header.d=gmail.com header.s=20161025 header.b=LSmnrJow; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: UmNQlXP7WMLs --000000000000a47d2105adfec292 Content-Type: multipart/alternative; boundary="000000000000a47d1f05adfec290" --000000000000a47d1f05adfec290 Content-Type: text/plain; charset="UTF-8" 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 > > --000000000000a47d1f05adfec290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bastien <bzg@gnu.org> writes:

> If you find the time to share your change as a _patch_ (not the whole<= br> > updated Elisp function), that will allow more readers on this list to<= br> > quickly understand what is at stake.

 Ok, I've finally gotten around to taking a crack at this. The patch is<= br> 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=3D6\)) 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)
=C2=A0 (let ((ret nil))
=C2=A0 =C2=A0 (if org-export-current-backend
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (let* ((backend-name org-export-current-backend= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(elem (assoc backend= -name blist)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if elem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq ret (cdr elem)))) =C2=A0 =C2=A0 =C2=A0 (let ((elem (assoc t blist)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq ret (cdr elem))))
=C2=A0 =C2=A0 (eval ret)))

;; custom function for preamble generation
(defun latex-preamble-by-backend (params)
=C2=A0 (concat "\\documentclass{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (cdr (assoc :class params))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\\definecolor{fg}{rgb}{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (by-backend '((html . "0,0,0&qu= ot;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (t . (org-latex-color :foreground))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}\n"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\\definecolor{bg}{rgb}{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (by-backend '((html . "1,1,1&qu= ot;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (t . (org-latex-color :background))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}\n"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\\def\\pc{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (by-backend '((html . "100"= ;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (t . "20")))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}\n"))

;; actual set customization
(setq org-babel-latex-preamble
=C2=A0 =C2=A0 =C2=A0 (lambda (params)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (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| =3D \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| =3D \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<= br> 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 di= scuss
options for further refactoring the latex execute function.

Matt

On Fri, Aug 28, 2020 at 11:10 PM Matt Huszagh <huszaghmatt@gmail.com> wrote:
Bastien <bzg@gnu.org> writes:

> If you find the time to share your change as a _patch_ (not the whole<= br> > updated Elisp function), that will allow more readers on this list to<= br> > quickly understand what is at stake.

Ok, I've finally gotten around to taking a crack at this. The patch is<= br> 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=3D6\)) 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)
=C2=A0 (let ((ret nil))
=C2=A0 =C2=A0 (if org-export-current-backend
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (let* ((backend-name org-export-current-backend= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(elem (assoc backend= -name blist)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if elem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq ret (cdr elem)))) =C2=A0 =C2=A0 =C2=A0 (let ((elem (assoc t blist)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq ret (cdr elem))))
=C2=A0 =C2=A0 (eval ret)))

;; custom function for preamble generation
(defun latex-preamble-by-backend (params)
=C2=A0 (concat "\\documentclass{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (cdr (assoc :class params))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\\definecolor{fg}{rgb}{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (by-backend '((html . "0,0,0&qu= ot;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (t . (org-latex-color :foreground))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}\n"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\\definecolor{bg}{rgb}{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (by-backend '((html . "1,1,1&qu= ot;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (t . (org-latex-color :background))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}\n"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\\def\\pc{"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (by-backend '((html . "100"= ;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (t . "20")))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}\n"))

;; actual set customization
(setq org-babel-latex-preamble
=C2=A0 =C2=A0 =C2=A0 (lambda (params)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (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| =3D \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| =3D \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<= br> 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 di= scuss
options for further refactoring the latex execute function.

Matt

--000000000000a47d1f05adfec290-- --000000000000a47d2105adfec292 Content-Type: application/octet-stream; name="0001-ob-latex.el-Make-latex-to-svg-compilation-very-custo.patch" Content-Disposition: attachment; filename="0001-ob-latex.el-Make-latex-to-svg-compilation-very-custo.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kefbihdm0 RnJvbSAwODM0ZjU5YWM5NDg1MTU4YzI2YzRiMjVlYzQwZGY1NmJlMmMxNWNhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXR0IEh1c3phZ2ggPGh1c3phZ2htYXR0QGdtYWlsLmNvbT4K RGF0ZTogRnJpLCAyOCBBdWcgMjAyMCAyMjoyNjowNSAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIG9i LWxhdGV4LmVsOiBNYWtlIGxhdGV4IHRvIHN2ZyBjb21waWxhdGlvbiB2ZXJ5IGN1c3RvbWl6YWJs ZQoKKiBsaXNwL29iLWxhdGV4LmVsIChvcmctYmFiZWwtbGF0ZXgtcHJlYW1ibGUpOiBBZGQgbGF0 ZXggcHJlYW1ibGUKY3VzdG9taXphdGlvbi4KKG9yZy1iYWJlbC1sYXRleC1wZGYtc3ZnLXByb2Nl c3MpOiBBZGQgY3VzdG9taXphdGlvbiBmb3IgY29udmVydGluZyBhCnBkZiB0byBzdmcuCihvcmct YmFiZWwtZXhlY3V0ZTpsYXRleCk6IEFkZCBzcGVjaWZpYyBjYXNlIGZvciBzdmcgZ2VuZXJhdGlv biBmcm9tCmxhdGV4IGJsb2NrLgotLS0KIGxpc3Avb2ItbGF0ZXguZWwgfCAzNSArKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKystLQogMSBmaWxlIGNoYW5nZWQsIDMzIGluc2VydGlvbnMo KyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9vYi1sYXRleC5lbCBiL2xpc3Av b2ItbGF0ZXguZWwKaW5kZXggNGIzNDNkZDE0Li5iYTdiYjgyNzcgMTAwNjQ0Ci0tLSBhL2xpc3Av b2ItbGF0ZXguZWwKKysrIGIvbGlzcC9vYi1sYXRleC5lbApAQCAtNzAsNiArNzAsMjMgQEAKICAg Omdyb3VwICdvcmctYmFiZWwKICAgOnR5cGUgJ3N0cmluZykKIAorKGRlZmN1c3RvbSBvcmctYmFi ZWwtbGF0ZXgtcHJlYW1ibGUKKyAgKGxhbWJkYSAoXykKKyAgICAiXFxkb2N1bWVudGNsYXNzW3By ZXZpZXdde3N0YW5kYWxvbmV9CitcXGRlZlxccGdmc3lzZHJpdmVye3BnZnN5cy10ZXg0aHQuZGVm fQorIikKKyAgIkNsb3N1cmUgd2hpY2ggZXZhbHVhdGVzIGF0IHJ1bnRpbWUgdG8gdGhlIGxhdGV4 IHByZWFtYmxlLiAgSXQKK3Rha2VzIDEgYXJndW1lbnQgd2hpY2ggaXMgdGhlIHBhcmFtZXRlcnMg b2YgdGhlIHNvdXJjZSBibG9jay4iCisgIDpncm91cCAnb3JnLWJhYmVsCisgIDp0eXBlICdmdW5j dGlvbikKKworKGRlZmN1c3RvbSBvcmctYmFiZWwtbGF0ZXgtcGRmLXN2Zy1wcm9jZXNzCisgICJp bmtzY2FwZSAtLXBkZi1wb3BwbGVyICVmIC1UIC1sIC1vICVPIgorICAiQ29tbWFuZCB1c2VkIHRv IGNvbnZlcnQgYSBQREYgZmlsZSB0byBhbiBTVkcgZmlsZSB3aGVuCitleGVjdXRpbmcgYSBsYXRl eCBzb3VyY2UgYmxvY2suIgorICA6Z3JvdXAgJ29yZy1iYWJlbAorICA6dHlwZSAnc3RyaW5nKQor CiAoZGVmY3VzdG9tIG9yZy1iYWJlbC1sYXRleC1odGxhdGV4LXBhY2thZ2VzCiAgICcoIlt1c2Vu YW1lc117Y29sb3J9IiAie3Rpa3p9IiAie2NvbG9yfSIgIntsaXN0aW5nc30iICJ7YW1zbWF0aH0i KQogICAiUGFja2FnZXMgdG8gdXNlIGZvciBodGxhdGV4IGV4cG9ydC4iCkBAIC0xMTQsMTIgKzEz MSwyNiBAQCBUaGlzIGZ1bmN0aW9uIGlzIGNhbGxlZCBieSBgb3JnLWJhYmVsLWV4ZWN1dGUtc3Jj LWJsb2NrJy4iCiAJCQkgKG1hcGNvbmNhdCAjJ2lkZW50aXR5IGhlYWRlcnMgIlxuIikpKSkKIAkg ICAob3JnLWNyZWF0ZS1mb3JtdWxhLWltYWdlCiAgICAgICAgICAgICBib2R5IG91dC1maWxlIG9y Zy1mb3JtYXQtbGF0ZXgtb3B0aW9ucyBpbi1idWZmZXIpKSkKKwkgKChzdHJpbmc9ICJzdmciIGV4 dGVuc2lvbikKKwkgICh3aXRoLXRlbXAtZmlsZSB0ZXgtZmlsZQorCQkgKGluc2VydCAoY29uY2F0 IChmdW5jYWxsIG9yZy1iYWJlbC1sYXRleC1wcmVhbWJsZSBwYXJhbXMpCisJCQkgKG1hcGNvbmNh dCAjJ2lkZW50aXR5IGhlYWRlcnMgIlxuIikKKwkJCSAiXFxiZWdpbntkb2N1bWVudH0iCisJCQkg Ym9keQorCQkJICJcXGVuZHtkb2N1bWVudH0iKSkpCisJICAobGV0ICgodG1wLXBkZiAob3JnLWJh YmVsLWxhdGV4LXRleC10by1wZGYgdGV4LWZpbGUpKSkKKyAgICAgICAgICAgICAgICAgIChsZXQq ICgobG9nLWJ1ZiAoZ2V0LWJ1ZmZlci1jcmVhdGUgIipPcmcgQmFiZWwgTGFUZVggT3V0cHV0KiIp KQorICAgICAgICAgICAgICAgICAgICAgICAgIChlcnItbXNnICJvcmcgYmFiZWwgbGF0ZXggZmFp bGVkIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAoaW1nLW91dCAob3JnLWNvbXBpbGUtZmls ZQorCSAgICAgICAgICAgICAgICAgICAgICAgICAgIHRtcC1wZGYKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGxpc3Qgb3JnLWJhYmVsLWxhdGV4LXBkZi1zdmctcHJvY2VzcykK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9uIGVyci1tc2cgbG9n LWJ1ZikpKQorICAgICAgICAgICAgICAgICAgICAoc2hlbGwtY29tbWFuZCAoZm9ybWF0ICJtdiAl cyAlcyIgaW1nLW91dCBvdXQtZmlsZSkpKSkpCiAgICAgICAgICAoKHN0cmluZy1zdWZmaXgtcCAi LnRpa3oiIG91dC1maWxlKQogCSAgKHdoZW4gKGZpbGUtZXhpc3RzLXAgb3V0LWZpbGUpIChkZWxl dGUtZmlsZSBvdXQtZmlsZSkpCiAJICAod2l0aC10ZW1wLWZpbGUgb3V0LWZpbGUKIAkgICAgKGlu c2VydCBib2R5KSkpCi0JICgoYW5kIChvciAoc3RyaW5nPSAic3ZnIiBleHRlbnNpb24pCi0JCSAg IChzdHJpbmc9ICJodG1sIiBleHRlbnNpb24pKQorCSAoKGFuZCAoc3RyaW5nPSAiaHRtbCIgZXh0 ZW5zaW9uKQogCSAgICAgICAoZXhlY3V0YWJsZS1maW5kIG9yZy1iYWJlbC1sYXRleC1odGxhdGV4 KSkKIAkgIDs7IFRPRE86IHRoaXMgaXMgYSB2ZXJ5IGRpZmZlcmVudCB3YXkgb2YgZ2VuZXJhdGlu ZyB0aGUKIAkgIDs7IGZyYW1lIGxhdGV4IGRvY3VtZW50IHRoYW4gaW4gdGhlIHBkZiBjYXNlLiAg SWRlYWxseSwgYm90aAotLSAKMi4yOC4wCgo= --000000000000a47d2105adfec292--