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

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

[Feng Shu]

> Hi Feng,
>
> Thanks for the patches. 
>
> "Feng Shu" <tumashu@163.com> writes:
>
>> 1. org-latex-pdf-process -> org-latex-pdf-default-process
>> 2. Add new variable org-latex-pdf-process-alist
>
> What do you have in mind?  I assume it’s something more than just ripping
> out the :type part of org-latex-pdf-process.
>

Similar, but include more information, maybe it it like:

#+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

>> 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, 

   "pdflatex-pdflatex-pdflatex" "xelatex-xelatex-xelatex" "lualatex-lualatex-lualatex"
 
otherwise, we can use #+latex_compile and define pdf process

   "latex-latex-latex"


>
>> I am a member of emacs community in chinese, many org-mode latex
>> beginners will ask me: "How to export org to pdf by latex?",
>> this problem is annoying, so i deside to write a package:
>> ox-latex-chinese and tell them: "Install org-latex-chinese package!"
>
> It sounds like #+language support should be extended.  A basic Chinese
> document with org doesn’t seem that hard.  With ttf-hannom, all I need is
> this:
>
>     #+latex_compiler: xelatex
>     #+latex_header: \usepackage{xeCJK}
>     #+latex_header: \setCJKmainfont{HAN NOM A}
>     文章内容
>
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

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.

> Rasmus

-- 


-- 

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

[Feng Shu]

> 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, 
>
>    "pdflatex-pdflatex-pdflatex" "xelatex-xelatex-xelatex" "lualatex-lualatex-lualatex"
>  
> otherwise, we can use #+latex_compile and define pdf process
>
>    "latex-latex-latex"

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.

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.

Re: 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" <tumashu@163.com> 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

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

[Feng Shu]

> 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.

Yes, I think: compile + class + packages = process, if I don't joint
them to a profile setting, it is impossible to swith process easily.


If you know the default class and packages setting is suitable for your
process, just ignore :default-class :valid-classes :packages-alist
:default-packages-alist and :packages-override, the four options are
used by user special processes.


> equivalent should be used.  I don’t care about the process.  I care about
> the final document and its correctness.

because latex system can deal with English very well by default, so you
can "don't care about the process", if I don't care about the process,
"the final document and its correctness" is just a dream. :-)


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

packages selected by org may conflict with user's latex package, so user
should edit `org-latex-default-packages-alist' by hand.

>
>> 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`.

`org-export-define-derived-backend' seem to be overkill for this situation.

> 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.

power users can do "anything" in org-mode, even rewrite ox-latex, my
question is that: is it flexible enough to let some power users to well
maintain some predefined configures which can make many beginning user's
install and config easily?

--