From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org, "Thomas S. Dye" <tsd@tsdye.online>
Subject: Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
Date: Tue, 26 Sep 2023 19:12:46 +0000 [thread overview]
Message-ID: <87lecsvjdd.fsf@posteo.net> (raw)
In-Reply-To: <ueuu03$fsk$1@ciao.gmane.io> (Max Nikulin's message of "Tue, 26 Sep 2023 22:39:46 +0700")
Max Nikulin writes:
> I just have checked that a dirty hack with a few lines of code for
> `org-export-filter-final-output-functions' allows to insert arbitrary
> text to the beginning of export result. Perhaps a more elegant solution
> exists, but I admit it is not a straightforward way. At least it is
> possible.
And it is also possible by simply defining a new class (in Org
terminology, not LaTeX). My usual class is an almost empty one, without
documentclass and without packages, because I don't want org to write
the preamble for me. But I think this is not the point.
> I do not mind that generation of preamble should be more flexible, but I
> consider LATEX_PRE_HEADER as an ad hoc solution, so I am trying to find
> a better variant. That is why I asked for details concerning particular
> use cases.
IMHO, LaTeX_pre_header is obvious and transparent to the user: a version
of LaTeX_header that behaves exactly the same, except that it exports
the lines before \documentclass. It is simple and requires little code
to implement, and it is used for all cases of code before the
declaration of the class, since its syntax is consistent with
LaTeX_header. And its use does not require further explanation. You can
even play with constructions like:
#+NAME: pre
#+begin_src latex :exports none
(some stuff)
#+end_src
#+begin_src latex :noweb yes :results raw
,#+LaTeX_pre_header: <<pre>>
#+end_src
> I remember recipes like "put \usepackage{cmap} immediately after
> \documentclass" (nowadays this particular one should not be necessary).
> So I would prefer to avoid keywords per each chunk of preamble code.
I think that this would not be the case. This is not just any part of
the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
would take care of what is after \documenclass (the axis of a LaTeX
document); LaTeX_pre_header would do it of anything that may have come
before. And both provide a less constricted preamble for advanced use of
LaTeX. Frankly, I can't think of a simpler solution.
> \begin{filecontents*} from the original post is not convincing.
Are you not convinced by some instructions that are included in the
official documentation of a LaTeX package (pdfx)?
https://i.imgur.com/NdLWmwc.png
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
next prev parent reply other threads:[~2023-09-26 19:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-16 18:00 [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword Juan Manuel Macías
2023-09-17 10:02 ` Ihor Radchenko
2023-09-17 17:23 ` Timothy
2023-09-18 8:09 ` Ihor Radchenko
2023-09-22 16:38 ` Max Nikulin
2023-09-24 18:42 ` Juan Manuel Macías
2023-09-25 13:58 ` Max Nikulin
2023-09-25 18:49 ` Juan Manuel Macías
2023-09-25 21:57 ` Thomas S. Dye
2023-09-26 15:39 ` Max Nikulin
2023-09-26 19:12 ` Juan Manuel Macías [this message]
2023-09-28 10:07 ` Max Nikulin
2023-09-28 12:31 ` Juan Manuel Macías
2023-09-29 2:38 ` Max Nikulin
2023-10-01 16:32 ` Max Nikulin
2023-09-28 15:36 ` AW
2023-10-01 16:02 ` Max Nikulin
2023-10-01 17:48 ` Juan Manuel Macías
2023-10-02 10:42 ` Max Nikulin
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=87lecsvjdd.fsf@posteo.net \
--to=maciaschain@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=tsd@tsdye.online \
/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).