emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: svg file from tikz picture


From: Ihor Radchenko
Subject: Re: svg file from tikz picture
Date: Wed, 21 Sep 2022 17:32:17 +0800

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]