all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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


  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.