Re: [O] Some thought about `org-latex-pdf-process-alist', was Re: (V9) [PATCH] New feature: Use dvisvgm to preview latex formular

[Rasmus]

Hi Feng,

Thanks for the detailed explanation.

"Feng Shu" <address@hidden> writes:

> #+BEGIN_SRC emacs-lisp
> (setq org-latex-pdf-process-alist
>       '(("pdflatex-pdflatex-pdflatex"
>          :commands ("pdflatex -interaction nonstopmode -output-directory %o 
> %f"
>                     "pdflatex -interaction nonstopmode -output-directory %o 
> %f"
>                     "pdflatex -interaction nonstopmode -output-directory %o 
> %f")
>
>          ;; A string in `:valid-classes',
>          ;; when nil, fallback to `org-latex-default-class'
>          :default-class "article"



>          ;; class-settings which works well with the process,
>          ;; they must be defined `org-latex-classes'.
>          ;; when nil, all class-settings defined `org-latex-classes'
>          ;; are valid.
>          :valid-classes ("article" "beamer" "report" "book")
>
>          ;; the process's default packages, when nil
>          ;; fallback to `org-latex-default-packages-alist'
>          :default-packages-alist nil
>
>          ;; the process's packages, when nil
>          ;; fallback to `org-latex-packages-alist'
>          :packages-alist nil
>          :packages-override nil)))
> #+END_SRC


This is mixing together org-latex-packages-alist, org-latex-pdf-process
and org-latex-document-class, org-latex-default-class,
org-koma-letter-default-class etc, and latexmk/carara into one (modulus
typos).  IMO, it introduces too much dependency and convolution.  Take
:valid-class; When I add a new class CLASS, I need to add it to the
correct entries in org-latex-pdf-process-alist.  You ask me to form a
joint opinion about too many things at once.

LaTeX is very modular and straight forward.  Little "bottles" curated
towards specific use-cases is rather the business of LyX (which is a great
program).

>>> 3. Add #+LATEX_PDF_PROCESS setting
>>
>> Is this the same as #+latex_compiler, which is used for setting the
>> process to pdflatex, xelatex or lualatex?
>
> It is different, 3 runs of latex as example:
>
> if we don't deal with %latex place-hold in process commands,
> #+latex_compiler is useless, we need to define pdf process
> in org-latex-pdf-process-alist, 

But we do define %latex everywhere,

    http://orgmode.org/cgit.cgi/org-mode.git/tree/lisp/ox-latex.el#n1149
  
> otherwise, we can use #+latex_compile and define pdf process
>
>    "latex-latex-latex"

%latex × 3 is a subpar solution.  Programs like latexmk or something
equivalent should be used.  I don’t care about the process.  I care about
the final document and its correctness.

> Reason:
> 1. Not so simple, we often need to edit `org-latex-classes'
>    `org-latex-default-packages-alist' and `org-latex-package-alist'
>    for many reason, for example: macro conflict

This is the nature of LaTeX.  The packages that Org selects by default do
not conflict with each other.

> 2. I don't want every users have to write latex-header in every org-file
> and I like: install ox-latex-chinese and
>
>        (setq org-latex-default-pdf-process "cn/xelatex-xelatex-xelatex")
>
> every org-file can export to pdf.

I strongly disagree with this vision.

This should be possible with org-latex-classes without limiting the
flexibility of ox-latex.  Also, we already have a way of solving this
use-case, namely org-export-define-derived-backend.

> By the way, I don't like the #+latex_compile approach, In my opinion, it seem 
> to be a
> hack. For user, ox-latex provide too much configure options.

LaTeX success rests in its flexibility, so this critique is misfounded
IMO.  The success of ox-latex is that it’s flexible enough to satisfy even
power users’ use-cases, making it an uncompromizing alternative to plain
LaTeX.

Take the example of "𝟙" (U+1D7D9).  This is only supported with
"unicode-math" which in turn requires xelatex/lualatex.  OTOH, microtype
supports pdflatex better.  As such, the "optimal" compiler depends on the
content.

> Maybe someone says, it is stupid duplicate code:
>
> #+BEGIN_COMMENT
> pdflatex-pdflatex-pdflatex
> pdflatex-pdflatex-pdflatex
> pdflatex-bibtex-pdflatex-pdflatex
> xelatex-xelatex-pdflatex
> xelatex-xelatex-pdflatex
> xelatex-bibtex-xelatex-xelatex
> luatex-luatex-lualatex
> luatex-luatex-lualatex
> luatex-bibtex-luatex-lualatex
> #+END_COMMENT
>
> but I think, it is a right approach, we must know, we have org contrib
> package, and we have other personnel org extension package, we don't
> need put all the process setting to ox-latex.el, we just add the
> following three as defaults and examples.
>
> #+BEGIN_COMMENT
> pdflatex-pdflatex-pdflatex
> pdflatex-pdflatex-pdflatex
> pdflatex-bibtex-pdflatex-pdflatex
> #+END_SRC
>
> ox-latex-process:xelatex package can be provided in elpa or melpa,
> if some need xelatex process setting, just install it.
>
> Users can develop and share their own special processes with the
> help of emacs package.

This sounds like a step back.

Rasmus

-- 
Got mashed potatoes. Ain't got no T-Bone. No T-Bone