From: Rasmus <rasmus@gmx.us>
To: emacs-orgmode@gnu.org
Subject: Re: Some thought about `org-latex-pdf-process-alist', was Re: (V9) [PATCH] New feature: Use dvisvgm to preview latex formular
Date: Sun, 22 May 2016 14:27:27 +0200 [thread overview]
Message-ID: <87r3cub7m8.fsf@gmx.us> (raw)
In-Reply-To: 87twhrdmn4.fsf@163.com
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
next prev parent reply other threads:[~2016-05-22 12:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-21 23:19 Some thought about `org-latex-pdf-process-alist', was Re: (V9) [PATCH] New feature: Use dvisvgm to preview latex formular Feng Shu
2016-05-22 0:11 ` Feng Shu
2016-05-22 12:27 ` Rasmus [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-05-23 4:20 Feng Shu
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3cub7m8.fsf@gmx.us \
--to=rasmus@gmx.us \
--cc=emacs-orgmode@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).