* [patch] Add two new header args to LaTeX block
@ 2024-02-10 1:58 Juan Manuel Macías
2024-02-10 14:37 ` Ihor Radchenko
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-10 1:58 UTC (permalink / raw)
To: orgmode
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
The attached patch adds two new header args to the LaTeX block:
- `:pdf-process' allows modifying the value of `org-latex-pdf-process'
locally to the block. This can be useful for evaluating a given block
with another LaTeX compiler, or even using some custom script.
Example:
#+begin_src latex :pdf-process '("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f")
\textbf{hello world}
#+end_src
- `:full-to-pdf' makes the block like a standalone LaTeX document, which
should contain everything needed to be compiled, from \documentclass{}
to \end{document}. Example:
#+begin_src latex :full-to-pdf yes
\documentclass{article}
\begin{document}
\textbf{hello world}
\end{document}
#+end_src
I think both arguments can have many practical uses. For example, to
compile separately and load multiple subdocuments, with different
preambles:
#+NAME: doc1
#+begin_src org :exports none :results latex
,#+include: some-document.org
#+end_src
#+begin_src latex :noweb yes :results silent file :file file.pdf :full-to-pdf yes
\documentclass{article}
\usepackage[spanish]{babel}
\usepackage{fontspec}
\setmainfont{Vollkorn}
\begin{document}
<<doc1()>>
\end{document}
#+end_src
#+latex: \includepdf{file.pdf}
Or even to evaluate ConTeXt code within a LaTeX block:
#+begin_src latex :full-to-pdf yes :results raw file :file file.pdf :pdf-process '("cd %o && context %f")
\starttext
\startsection[title={Testing ConTeXt}]
Lorem ipsum dolor.
\stopsection
\stoptext
#+end_src
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2148 bytes --]
From fe1b40e2b22e2c668440bea13feda0ab7923bdd8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.
* (org-babel-execute:latex): `:pdf-process' allows modifying the value
of `org-latex-pdf-process' in a specific block. The `:full-to-pdf'
argument requires that the LaTeX block contains all the code necessary
to be compiled, as if it were an autonomous LaTeX document: the
expected result will always be a PDF file.
---
lisp/ob-latex.el | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..118d81338 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,9 @@ This function is called by `org-babel-execute-src-block'."
(height (and fit (cdr (assq :pdfheight params))))
(width (and fit (cdr (assq :pdfwidth params))))
(headers (cdr (assq :headers params)))
+ (pdf-process (cdr (assq :pdf-process params)))
+ (org-latex-pdf-process (if pdf-process pdf-process org-latex-pdf-process))
+ (full-to-pdf (cdr (assq :full-to-pdf params)))
(in-buffer (not (string= "no" (cdr (assq :buffer params)))))
(org-latex-packages-alist
(append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +190,14 @@ This function is called by `org-babel-execute-src-block'."
(list org-babel-latex-pdf-svg-process)
extension err-msg log-buf)))
(rename-file img-out out-file t))))
+ ((and (string= "pdf" extension) full-to-pdf)
+ (with-temp-file tex-file
+ (insert body))
+ (when (file-exists-p out-file) (delete-file out-file))
+ (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+ (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+ (err-msg "org babel latex failed"))
+ (rename-file tmp-pdf out-file t))))
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 1:58 [patch] Add two new header args to LaTeX block Juan Manuel Macías
@ 2024-02-10 14:37 ` Ihor Radchenko
2024-02-10 15:20 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Ihor Radchenko @ 2024-02-10 14:37 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> The attached patch adds two new header args to the LaTeX block:
>
> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
> locally to the block. This can be useful for evaluating a given block
> with another LaTeX compiler, or even using some custom script.
> Example:
> ...
> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
> should contain everything needed to be compiled, from \documentclass{}
> to \end{document}. Example:
Thanks!
May you please explain in more detail how these new header arguments fit
into other available LaTeX code block parameters? In particular, when
exporting to .png/.svg/.html or when :imagemagick header argument is provided.
--
Ihor Radchenko // yantar92,
Org mode contributor,
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 14:37 ` Ihor Radchenko
@ 2024-02-10 15:20 ` Juan Manuel Macías
2024-02-10 16:35 ` Ihor Radchenko
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-10 15:20 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> The attached patch adds two new header args to the LaTeX block:
>>
>> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>> locally to the block. This can be useful for evaluating a given block
>> with another LaTeX compiler, or even using some custom script.
>> Example:
>> ...
>> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
>> should contain everything needed to be compiled, from \documentclass{}
>> to \end{document}. Example:
>
> Thanks!
> May you please explain in more detail how these new header arguments fit
> into other available LaTeX code block parameters? In particular, when
> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
Sure! `:pdf-process' simply applies a local value to
org-latex-pdf-process. It does not affect the export to png in its
version without imagemagick process, since this option depends on
org-create-formula-image, which in turn depends on
org-preview-latex-default-process. It also does not affect the export to
html, which depends on org-babel-latex-htlatex. It should work in all
other cases, including imagemagick, which ultimately depend on
org-latex-pdf-process.
As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
better name), the expected result is a pdf file. Therefore it is
incompatible with exporting to png, svg or conversion with imagemagick.
For it to work, it is enough to provide these 2 args: ":file foo.pdf
:full-to-pdf yes."
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 15:20 ` Juan Manuel Macías
@ 2024-02-10 16:35 ` Ihor Radchenko
2024-02-10 17:48 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Ihor Radchenko @ 2024-02-10 16:35 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> May you please explain in more detail how these new header arguments fit
>> into other available LaTeX code block parameters? In particular, when
>> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
>
> Sure! `:pdf-process' simply applies a local value to
> org-latex-pdf-process. It does not affect the export to png in its
> version without imagemagick process, since this option depends on
> org-create-formula-image, which in turn depends on
> org-preview-latex-default-process. It also does not affect the export to
> html, which depends on org-babel-latex-htlatex. It should work in all
> other cases, including imagemagick, which ultimately depend on
> org-latex-pdf-process.
Would it make sense to make :pdf-process work for png previews as well?
> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
> better name), the expected result is a pdf file. Therefore it is
> incompatible with exporting to png, svg or conversion with imagemagick.
> For it to work, it is enough to provide these 2 args: ":file foo.pdf
> :full-to-pdf yes."
Maybe just :standalone?
--
Ihor Radchenko // yantar92,
Org mode contributor,
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 16:35 ` Ihor Radchenko
@ 2024-02-10 17:48 ` Juan Manuel Macías
2024-02-10 19:35 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-10 17:48 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> May you please explain in more detail how these new header arguments fit
>>> into other available LaTeX code block parameters? In particular, when
>>> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
>>
>> Sure! `:pdf-process' simply applies a local value to
>> org-latex-pdf-process. It does not affect the export to png in its
>> version without imagemagick process, since this option depends on
>> org-create-formula-image, which in turn depends on
>> org-preview-latex-default-process. It also does not affect the export to
>> html, which depends on org-babel-latex-htlatex. It should work in all
>> other cases, including imagemagick, which ultimately depend on
>> org-latex-pdf-process.
>
> Would it make sense to make :pdf-process work for png previews as well?
It would be ideal. The expected value for org-latex-pdf-process is a
command or a list of commands, but org-preview-latex-default-process
expects a plist of various processes and parameters. Maybe with some
conditional? If only the png extension is provided (without the
:imagemagick argument), then the expected value is for
org-preview-latex-default-process. In all other cases, the value is for
org-latex-pdf-process. The argument could then be called simply
:process. E.g.:
Assuming the user has somewhere (add-to-list
org-preview-latex-process-alist my-process):
:results file :file foo.png :process 'my-process [or :process '(a plist)]
In other cases, like this:
:imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")
wdyt?
>> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
>> better name), the expected result is a pdf file. Therefore it is
>> incompatible with exporting to png, svg or conversion with imagemagick.
>> For it to work, it is enough to provide these 2 args: ":file foo.pdf
>> :full-to-pdf yes."
>
> Maybe just :standalone?
Yes, I totally agree.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 17:48 ` Juan Manuel Macías
@ 2024-02-10 19:35 ` Juan Manuel Macías
2024-02-10 21:07 ` Ihor Radchenko
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-10 19:35 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
Juan Manuel Macías writes:
>> Ihor Radchenko writes:
>> Would it make sense to make :pdf-process work for png previews as well?
>
> It would be ideal. The expected value for org-latex-pdf-process is a
> command or a list of commands, but org-preview-latex-default-process
> expects a plist of various processes and parameters. Maybe with some
> conditional? If only the png extension is provided (without the
> :imagemagick argument), then the expected value is for
> org-preview-latex-default-process. In all other cases, the value is for
> org-latex-pdf-process. The argument could then be called simply
> :process. E.g.:
>
> Assuming the user has somewhere (add-to-list
> org-preview-latex-process-alist my-process):
>
> :results file :file foo.png :process 'my-process [or :process '(a plist)]
>
> In other cases, like this:
>
> :imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")
>
> wdyt?
I am attaching a new patch with this idea incorporated. I have also
changed the name from full-to-pdf to standalone.
Best regards,
Juan Manuel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2634 bytes --]
From a7f72015007722e665338c39b9a02d675c31cd93 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.
* (org-babel-execute:latex): `:process' allows modifying the value of
`org-latex-pdf-process' or `org-preview-latex-default-process' in a
specific block. If only the `png' extension is provided (without the
`:imagemagick' argument), then the expected value is for
`org-preview-latex-default-process'. In all other cases, the value is
for `org-latex-pdf-process'. This argument has no effect if the
conversion is to `HTML'. The `:standalone' argument requires that
the LaTeX block contains all the code necessary to be compiled, as if
it were an autonomous LaTeX document: the expected result will always
be a PDF file.
---
lisp/ob-latex.el | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..8bec0c661 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,14 @@ This function is called by `org-babel-execute-src-block'."
(height (and fit (cdr (assq :pdfheight params))))
(width (and fit (cdr (assq :pdfwidth params))))
(headers (cdr (assq :headers params)))
+ (process (cdr (assq :process params)))
+ (org-preview-latex-default-process (if (and process
+ (string-suffix-p ".png" out-file)
+ (not imagemagick))
+ process
+ org-preview-latex-default-process))
+ (org-latex-pdf-process (if process process org-latex-pdf-process))
+ (standalone (cdr (assq :standalone params)))
(in-buffer (not (string= "no" (cdr (assq :buffer params)))))
(org-latex-packages-alist
(append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +195,14 @@ This function is called by `org-babel-execute-src-block'."
(list org-babel-latex-pdf-svg-process)
extension err-msg log-buf)))
(rename-file img-out out-file t))))
+ ((and (string= "pdf" extension) standalone)
+ (with-temp-file tex-file
+ (insert body))
+ (when (file-exists-p out-file) (delete-file out-file))
+ (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+ (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+ (err-msg "org babel latex failed"))
+ (rename-file tmp-pdf out-file t))))
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 19:35 ` Juan Manuel Macías
@ 2024-02-10 21:07 ` Ihor Radchenko
2024-02-10 23:34 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Ihor Radchenko @ 2024-02-10 21:07 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> I am attaching a new patch with this idea incorporated. I have also
> changed the name from full-to-pdf to standalone.
>
> + (process (cdr (assq :process params)))
> + (org-preview-latex-default-process (if (and process
> + (string-suffix-p ".png" out-file)
> + (not imagemagick))
Considering that 'imagemagick is one of the variants in
`org-preview-latex-process-alist', it might be reasonable to allow
:process imagemagick == :imagemagick yes
Also, it feels incomplete to be able to define latex command for :file
foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
--
Ihor Radchenko // yantar92,
Org mode contributor,
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 21:07 ` Ihor Radchenko
@ 2024-02-10 23:34 ` Juan Manuel Macías
2024-02-11 14:43 ` Ihor Radchenko
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-10 23:34 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I am attaching a new patch with this idea incorporated. I have also
>> changed the name from full-to-pdf to standalone.
>>
>> + (process (cdr (assq :process params)))
>> + (org-preview-latex-default-process (if (and process
>> + (string-suffix-p ".png" out-file)
>> + (not imagemagick))
>
> Considering that 'imagemagick is one of the variants in
> `org-preview-latex-process-alist', it might be reasonable to allow
> :process imagemagick == :imagemagick yes
I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
Instead, «:process 'imagemagick» depends on:
(imagemagick :programs
("latex" "convert")
:description "pdf > png"
:message "you need to install the programs: latex and imagemagick."
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("pdflatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O"))
Also, one may want to put «:imagemagick yes» and compile the PDF
with another compiler or with a custom script:
:imagemagick yes :process '(...)
> Also, it feels incomplete to be able to define latex command for :file
> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
The ".png" method without ":imagemagick" does not depend on
'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
depends on the value of 'org-preview-latex-default-process':
...
((and (string-suffix-p ".png" out-file) (not imagemagick))
(let ((org-format-latex-header
(concat org-format-latex-header "\n"
(mapconcat #'identity headers "\n"))))
(org-create-formula-image
body out-file org-format-latex-options in-buffer)))
...
If you put :file foo.png without :imagemagick, and want to control the
process or change the compiler, you can do it with:
:process '(foo :latex-compiler ("some LaTeX command"))
since this syntax is what org-preview-latex-default-process expects.
In all other cases, including :imagemagick, the compilation process
depends on the value of org-latex-pdf-process.
Anyway, I don't understand why that feature option (convert to an image
without :imagemagick method) is limited to .png, when other graphic files are
possible. I can define something like this:
(setq org-preview-latex-default-process
'(my-process
:programs ("lualatex" "convert")
:description "pdf > jpg"
:image-input-type "pdf"
:image-output-type "jpg"
:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
But if I put :file foo.jpg nothing happens. Maybe that part should be
corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-10 23:34 ` Juan Manuel Macías
@ 2024-02-11 14:43 ` Ihor Radchenko
2024-02-11 20:01 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Ihor Radchenko @ 2024-02-11 14:43 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Considering that 'imagemagick is one of the variants in
>> `org-preview-latex-process-alist', it might be reasonable to allow
>> :process imagemagick == :imagemagick yes
>
> I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
> Instead, «:process 'imagemagick» depends on:
>
> (imagemagick :programs
> ...
Agree.
>> Also, it feels incomplete to be able to define latex command for :file
>> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
>
> The ".png" method without ":imagemagick" does not depend on
> 'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
> depends on the value of 'org-preview-latex-default-process':
> ...
> If you put :file foo.png without :imagemagick, and want to control the
> process or change the compiler, you can do it with:
>
> :process '(foo :latex-compiler ("some LaTeX command"))
>
> since this syntax is what org-preview-latex-default-process expects.
>
> In all other cases, including :imagemagick, the compilation process
> depends on the value of org-latex-pdf-process.
Got it.
Although, it is confusing to have different formats of :process
value depending on :file extension.
It would make things easier for users if
:results file :file foo.png :process '("lualatex -interaction nonstopmode
-output-directory %o %f")
worked as expected, automatically overriding :latex-compiler value in
let-bound `org-preview-latex-process-alist'.
> Anyway, I don't understand why that feature option (convert to an image
> without :imagemagick method) is limited to .png, when other graphic files are
> possible. I can define something like this:
>
> (setq org-preview-latex-default-process
> '(my-process
> :programs ("lualatex" "convert")
> :description "pdf > jpg"
> :image-input-type "pdf"
> :image-output-type "jpg"
> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
>
> But if I put :file foo.jpg nothing happens. Maybe that part should be
> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
I agree that it should be corrected.
Moreover, it would be nice to unify handling .png and imagemagick
branches of the code.
--
Ihor Radchenko // yantar92,
Org mode contributor,
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-11 14:43 ` Ihor Radchenko
@ 2024-02-11 20:01 ` Juan Manuel Macías
2024-02-13 13:42 ` Ihor Radchenko
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-11 20:01 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Got it.
> Although, it is confusing to have different formats of :process
> value depending on :file extension.
Indeed. For that reason I changed the original name I gave from
":pdf-process" to simply ":process". IMHO this function has a tremendous
problem: two methods coexist to convert a PDF compiled with LaTeX to an
image: the method with :imagemagick and the method without :imagemagick,
although this can also use imagemagick, which in itself is a first mess.
I don't know if this state of affairs is clear to the user...
The method without :imagemagick, furthermore, is the only one that
depends on a different process (leaving aside the case of conversion to
html, where another process is used).
The method with :imagemagick is, like the rest, more "transparent" (it is
the one I use, and I think many users prefer it):
TeX file --> compilation --> PDF --> conversion --> image file
The method without :imagemagick, which depends on the value of
org-preview-latex-default-process could be schematized like this:
TeX file --> {compilation + PDF + conversion + params.} --> image file
That is, the compilation and conversion processes along with the
parameters are included in the same pack.
> It would make things easier for users if
> :results file :file foo.png :process '("lualatex -interaction nonstopmode
> -output-directory %o %f")
>
> worked as expected, automatically overriding :latex-compiler value in
> let-bound `org-preview-latex-process-alist'.
I think that can cause certain drawbacks. Suppose a user has dvipng
as the value of org-preview-latex-default-process. If he/she puts
":process '(luatex etc ...)"
he/she will not be able to create the image because dvipng has the
value of ":image-converter" as the dvipng program, which, to put it
briefly and without going into details, would not work well with LuaTeX.
It is the problem of the same pack that I mentioned before. That's why I
think the lesser evil would be to allow the user to control the
necessary parameters at will, if the output file is an image file and
":imagemagick" is not present. Anyway, see what I say below.
>> Anyway, I don't understand why that feature option (convert to an image
>> without :imagemagick method) is limited to .png, when other graphic files are
>> possible. I can define something like this:
>>
>> (setq org-preview-latex-default-process
>> '(my-process
>> :programs ("lualatex" "convert")
>> :description "pdf > jpg"
>> :image-input-type "pdf"
>> :image-output-type "jpg"
>> :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
>> :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
>>
>> But if I put :file foo.jpg nothing happens. Maybe that part should be
>> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
>
> I agree that it should be corrected.
> Moreover, it would be nice to unify handling .png and imagemagick
> branches of the code.
I agree. In any case, I still think that the coexistence of two methods
to convert to images, when one of the methods has a scheme so different
from the rest, becomes difficult: for the user as well as for
maintaining the code.
The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
But I suppose this could cause unwanted inconveniences. We should see
what more users think.
Another possibility is to clarify the names a little more (for the user):
:image-conv [possible values: default, imagemagick (= :imagemagick yes)]
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-11 20:01 ` Juan Manuel Macías
@ 2024-02-13 13:42 ` Ihor Radchenko
2024-02-13 20:25 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Ihor Radchenko @ 2024-02-13 13:42 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> Moreover, it would be nice to unify handling .png and imagemagick
>> branches of the code.
>
> I agree. In any case, I still think that the coexistence of two methods
> to convert to images, when one of the methods has a scheme so different
> from the rest, becomes difficult: for the user as well as for
> maintaining the code.
>
> The first solution that occurs to me (I'm afraid it's too radical) is to
> leave only the :imagemagick method, and maintain the possibility of
> using the other one through a variable. Something like
> org-babel-latex-default-image-conversion-method or something similar.
> But I suppose this could cause unwanted inconveniences. We should see
> what more users think.
I am not sure.
Conceptually, .png method is more flexible than imagemagick - it uses
`org-create-formula-image' that is handling (1) preamble; (2) conversion
not only to png but to svg and other arbitrary formats.
ob-latex is duplicating org-create-formula-image code, layering custom
latex preamble and more commands on top.
So, ideally, I'd prefer to obsolete the custom code in ob-latex and make
use of `org-create-formula-image', possibly extending it to fit ob-latex
needs.
--
Ihor Radchenko // yantar92,
Org mode contributor,
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-13 13:42 ` Ihor Radchenko
@ 2024-02-13 20:25 ` Juan Manuel Macías
2024-02-18 14:20 ` Ihor Radchenko
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-13 20:25 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Moreover, it would be nice to unify handling .png and imagemagick
>>> branches of the code.
>>
>> I agree. In any case, I still think that the coexistence of two methods
>> to convert to images, when one of the methods has a scheme so different
>> from the rest, becomes difficult: for the user as well as for
>> maintaining the code.
>>
>> The first solution that occurs to me (I'm afraid it's too radical) is to
>> leave only the :imagemagick method, and maintain the possibility of
>> using the other one through a variable. Something like
>> org-babel-latex-default-image-conversion-method or something similar.
>> But I suppose this could cause unwanted inconveniences. We should see
>> what more users think.
>
> I am not sure.
> Conceptually, .png method is more flexible than imagemagick - it uses
> `org-create-formula-image' that is handling (1) preamble; (2) conversion
> not only to png but to svg and other arbitrary formats.
> ob-latex is duplicating org-create-formula-image code, layering custom
> latex preamble and more commands on top.
> So, ideally, I'd prefer to obsolete the custom code in ob-latex and make
> use of `org-create-formula-image', possibly extending it to fit ob-latex
> needs.
It is true that the "org-create-formula-image" method is much more
complete. But, IMHO, I think it's a method focused on the buffer (rather
than the block) or previewing LaTeX code in the buffer. In the case of
the LaTeX block, I think the :imagemagick method is simpler. It depends
on two simple processes: imagemagick and org-latex-pdf-process and
parameters such as the width or height of the generated image, the
density in dpi, etc. can be easily applied, via arguments. In the case
of the other method, in addition to the value of
org-preview-latex-default-process, there is that of
org-format-latex-options. There are, in short, many parameters that are
perfect for a file or an Emacs session but for a simple block I find
overhelming.
In any case, if the org-create-formula-image method is going to stay, I
think it is fine as it is (except for extending the allowed file formats
to more extensions, and not only .png). I also believe that the :process
argument is sufficient for the user to control the value of
org-latex-pdf-process or org-preview-latex-default-process, as
appropriate.
Best regards,
Juan Manuel
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-18 14:20 ` Ihor Radchenko
@ 2024-02-18 13:43 ` Juan Manuel Macías
2024-02-19 11:15 ` Ihor Radchenko
0 siblings, 1 reply; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-18 13:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
>> In any case, if the org-create-formula-image method is going to stay, I
>> think it is fine as it is (except for extending the allowed file formats
>> to more extensions, and not only .png). I also believe that the :process
>> argument is sufficient for the user to control the value of
>> org-latex-pdf-process or org-preview-latex-default-process, as
>> appropriate.
>
> My concern about your patch is that it creates even more divergence
> between different branches of code in `org-babel-execute:latex'.
> With the new proposed features only available to some code branches,
> `org-babel-execute:latex' will just become more messy and harder to
> maintain.
>
> I'd prefer to refactor `org-babel-execute:latex' first, before adding
> new header arguments.
org-create-formula-image inserts LaTeX code:
...
(with-temp-file texfile
(insert latex-header)
(insert "\n\\begin{document}\n"
"\\definecolor{fg}{rgb}{" fg "}%\n"
(if bg
(concat "\\definecolor{bg}{rgb}{" bg "}%\n"
"\n\\pagecolor{bg}%\n")
"")
"\n{\\color{fg}\n"
string
"\n}\n"
"\n\\end{document}\n"))
...
that, /in principle/, would make it incompatible with the :standalone
argument (in my patch), which allows writing all LaTeX code from scratch
in the block content.
Anyway, it is true that org-babel-execute:latex has grown in a somewhat
irregular way. For example, I don't quite understand why the simple
output to PDF and the conversion to an image with :imagemagick live in
the same conditional:
(or (string= "pdf" extension) imagemagick)
I would propose three main branches in this function:
- A PDF branch, using org-format-latex-header with its valid options,
and other sub-branches with conversion from the PDF, for example, the
use of :imagemagick. Or you could even think of any possible
conversion process using a hypothetical :pdf-postprocess
- A branch for orf-create-formula-image
- a third branch to export to html, with org-babel-latex-htlatex.
Having three clearly differentiated branches would make the code easier
to maintain.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-13 20:25 ` Juan Manuel Macías
@ 2024-02-18 14:20 ` Ihor Radchenko
2024-02-18 13:43 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Ihor Radchenko @ 2024-02-18 14:20 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
> It is true that the "org-create-formula-image" method is much more
> complete. But, IMHO, I think it's a method focused on the buffer (rather
> than the block) or previewing LaTeX code in the buffer.
What do you mean? `org-create-formula-image' is passed a string of LaTeX
code. Note that `org-create-formula-image' is also used in HTML export.
> ... In the case of
> the LaTeX block, I think the :imagemagick method is simpler. It depends
> on two simple processes: imagemagick and org-latex-pdf-process and
> parameters such as the width or height of the generated image, the
> density in dpi, etc. can be easily applied, via arguments.
ob-latex does not have to expose all the possible toggles
`org-latex-pdf-process' has.
> ... In the case
> of the other method, in addition to the value of
> org-preview-latex-default-process, there is that of
> org-format-latex-options. There are, in short, many parameters that are
> perfect for a file or an Emacs session but for a simple block I find
> overhelming.
We can fix the parameters we do not want to expose.
> In any case, if the org-create-formula-image method is going to stay, I
> think it is fine as it is (except for extending the allowed file formats
> to more extensions, and not only .png). I also believe that the :process
> argument is sufficient for the user to control the value of
> org-latex-pdf-process or org-preview-latex-default-process, as
> appropriate.
My concern about your patch is that it creates even more divergence
between different branches of code in `org-babel-execute:latex'.
With the new proposed features only available to some code branches,
`org-babel-execute:latex' will just become more messy and harder to
maintain.
I'd prefer to refactor `org-babel-execute:latex' first, before adding
new header arguments.
--
Ihor Radchenko // yantar92,
Org mode contributor,
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-18 13:43 ` Juan Manuel Macías
@ 2024-02-19 11:15 ` Ihor Radchenko
2024-02-19 13:24 ` Juan Manuel Macías
0 siblings, 1 reply; 16+ messages in thread
From: Ihor Radchenko @ 2024-02-19 11:15 UTC (permalink / raw)
To: Juan Manuel Macías; +Cc: orgmode
Juan Manuel Macías <maciaschain@posteo.net> writes:
>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>> new header arguments.
>
> org-create-formula-image inserts LaTeX code:
`org-create-formula-image' will be obsoleted after Timothy merges his
latex preview branch. If the new implementation turns out to be not
flexible enough, we can always refactor it further to meet ob-latex
needs.
--
Ihor Radchenko // yantar92,
Org mode contributor,
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] Add two new header args to LaTeX block
2024-02-19 11:15 ` Ihor Radchenko
@ 2024-02-19 13:24 ` Juan Manuel Macías
0 siblings, 0 replies; 16+ messages in thread
From: Juan Manuel Macías @ 2024-02-19 13:24 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: orgmode
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>>> new header arguments.
>>
>> org-create-formula-image inserts LaTeX code:
>
> `org-create-formula-image' will be obsoleted after Timothy merges his
> latex preview branch. If the new implementation turns out to be not
> flexible enough, we can always refactor it further to meet ob-latex
> needs.
In that case, I think this patch could be considered canceled.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-02-19 13:25 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-10 1:58 [patch] Add two new header args to LaTeX block Juan Manuel Macías
2024-02-10 14:37 ` Ihor Radchenko
2024-02-10 15:20 ` Juan Manuel Macías
2024-02-10 16:35 ` Ihor Radchenko
2024-02-10 17:48 ` Juan Manuel Macías
2024-02-10 19:35 ` Juan Manuel Macías
2024-02-10 21:07 ` Ihor Radchenko
2024-02-10 23:34 ` Juan Manuel Macías
2024-02-11 14:43 ` Ihor Radchenko
2024-02-11 20:01 ` Juan Manuel Macías
2024-02-13 13:42 ` Ihor Radchenko
2024-02-13 20:25 ` Juan Manuel Macías
2024-02-18 14:20 ` Ihor Radchenko
2024-02-18 13:43 ` Juan Manuel Macías
2024-02-19 11:15 ` Ihor Radchenko
2024-02-19 13:24 ` Juan Manuel Macías
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).