From: Ihor Radchenko <yantar92@gmail.com>
To: reza <reza@housseini.me>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: svg file from tikz picture
Date: Wed, 21 Sep 2022 17:32:17 +0800 [thread overview]
Message-ID: <875yhhxece.fsf@localhost> (raw)
In-Reply-To: <010201835a532739-08121085-5b99-4410-8f53-11b74f8d7dcc-000000@eu-west-1.amazonses.com>
reza <reza@housseini.me> writes:
First of all, thanks a lot for digging into ob-latex!
This file has not been touched seriously since 7 years ago and the last
major change is 8 years ago (510e70379).
> When having a look at the code inside ob-latex.el I also encountered a
> few stuff which made me wondering:
>
> 1. png generation is done with the preview code inside org.el
> (org-create-formula-image), there is also a perfectly fine svg preview
> function but this does not get used for the svg extension which does the
> svg conversion without any external tools like inkscape (see
> https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L156 and
> https://github.com/bzg/org-mode/blob/main/lisp/org.el#L3181)
This, and many other oddities are likely related to the fact that org.el
preview code is more up-to-date, while ob-latex have not been changed,
including its assumptions about org.el's LaTeX preview.
I suspect that some features in org.el were implemented
separately, but did not get integrated with ob-latex.
> 2. there is a tikz extension switch which does insert the code verbatim,
> which in my opinion does create a whole bunch of problems (backend
> dependency issues). Not to mention that it also mimics behaviour which
> is reserved for the header :results (see
> https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L177).
Could you please elaborate?
> 3. there is a html extension switch with an unclear purpose to me (in
> what scenario would you want to produce an html file?). It also has some
> strange (and contradicting) checking if an svg or an html file got
> produced. As far as I can tell this code never gets executed and is
> therefore pointless (see
> https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L181).
Well. We do not remove existing features unless there is strong
justifications. See https://bzg.fr/en/the-software-maintainers-pledge/
As for the contradicting checking, it is likely a classic copy-paste
error when html and svg branches of the code got split.
> 4. the whole pdf generation looks like duplicate code which is already
> done in other parts of the code base (ox-latex.el and for the svg
> extension) it ais also not using the variable org-babel-latex-begin-env
> and org-babel-latex-end-env (see
> https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L225).
Again, I am not sure here. It is a very old code. My best guess is that
it was developer prior to ox-latex.
The best hint I can provide is
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html
that should document some details of the logic.
> I don't want to criticize anyone, I just want to find answers for in my
> opinion some strange decisions.
Criticism is welcome as long as it is aiming to improve Org. No worries.
If you want to dig further, I can also suggest to use git blame and dig
into mailing list messages from Eric Schulte, the original author of
ob-latex.
> My propositions for refactoring is:
>
> 1. use the svg preview code for svg generation (and therefore ditching
> the whole imagemagick headers)
Note that imagemagick argument does more than you may expect. For
example, one can apply various image effects on the generated file via
imagemagick:
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html
>> :imagemagick
>> When not nil the source block is processed to pdf and the pdf is converted with ImageMagick to whatever is given as :file. Thus, the format is not limited to png.
>> :iminoptions
>> This is passed to ImageMagick before the pdf file.
>> :imoutoptions
>> This is passed to ImageMagick before the output file.
That said, I do agree that re-using svg preview generation sounds like
an improvement. But we need to be careful not to remove the existing
functionality.
> 2. remove the whole tikz generation completely
>
> 3. remove the whole html generation completely
I did not see justification why we need to do it other than lack of
ideas why they are useful. For now, I do not think that removing
tikz/html generation is a good idea.
According to
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html,
tikz generation can be useful during LaTeX export.
> 4. try to merge pdf generation with org.el and ox-latex.el or
> incorporating it into he preview code and
> org-preview-latex-process-alist (this is probably a whole project of it own)
This sounds like a very good idea. I'd merge the preview code from
org.el into ob-latex.
> WDYT?
Improving ob-latex is most welcome. I think that the first step is
incremental refactor. Let's not remove features until we have less
tangled code that is easier to understand.
--
Ihor Radchenko,
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
next prev parent reply other threads:[~2022-09-21 9:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3bc47afb-0bac-f6e8-1097-13dcb6f2be1f@housseini.me>
2022-08-15 18:50 ` svg file from tikz picture reza
2022-08-16 9:42 ` Ihor Radchenko
[not found] ` <964a4117-ef6c-8d41-a25d-00e61c0c93d8@housseini.me>
2022-08-16 10:00 ` reza
2022-08-16 10:13 ` Ihor Radchenko
[not found] ` <0931497c-9075-c214-c7f2-6507340a6d74@housseini.me>
2022-08-16 10:19 ` reza
2022-08-16 10:31 ` Ihor Radchenko
[not found] ` <6daeb56b-163c-f862-5866-da624b43edd9@housseini.me>
2022-08-16 11:06 ` reza
2022-08-16 11:22 ` Ihor Radchenko
[not found] ` <7dcd1348-6faf-8464-38b5-8efac7c69250@housseini.me>
2022-08-16 11:25 ` reza
[not found] ` <be3e5412-37ff-c1c7-7a27-3793d72842d4@housseini.me>
2022-09-20 9:55 ` reza
2022-09-20 20:53 ` Edouard Debry
2022-09-21 9:32 ` Ihor Radchenko [this message]
2022-09-23 2:28 ` Akira Kyle
2022-09-25 7:52 ` Ihor Radchenko
2022-11-14 5:52 ` Ihor Radchenko
2023-03-24 23:22 ` Akira Kyle
2023-03-25 18:13 ` Ihor Radchenko
2023-03-25 18:14 ` Akira Kyle
2023-03-25 18:25 ` Ihor Radchenko
2023-04-19 9:57 ` Bastien Guerry
2023-08-05 9:34 ` Ihor Radchenko
2023-08-05 17:29 ` Bastien Guerry
2023-08-05 18:38 ` Akira Kyle
2023-08-06 5:37 ` Bastien Guerry
2023-08-06 5:40 ` Bastien Guerry
2023-10-19 9:51 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875yhhxece.fsf@localhost \
--to=yantar92@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=reza@housseini.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.