From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
Date: Mon, 25 Sep 2023 18:49:11 +0000 [thread overview]
Message-ID: <875y3yytp4.fsf@posteo.net> (raw)
In-Reply-To: <ues3ln$9rj$1@ciao.gmane.io> (Max Nikulin's message of "Mon, 25 Sep 2023 20:58:14 +0700")
Max Nikulin writes:
> On 25/09/2023 01:42, Juan Manuel Macías wrote:
>> According to the pdfx package documentation
>> (https://www.ctan.org/pkg/pdfx), p. 6 (at the bottom of the page)/7:
>> ---
>> Warning: The \jobname.xmpdata file may be included in the main document
>> source, within a {filecontents*} environment, provided this comes before
>> the \documentclass command, as follows[...]
>> ---
>
> Does it mean that with hyperxmp you can not generate documents
> satisfying some requirements and you need namely pdfx? Is there a
> reason that .xmpdata files must be generated namely by a LaTeX engine
> and writing them by elisp code is unacceptable?
In the hyperxmp manual a comparison is made with the pdfx package and
other similar packages. Anyway, this topic deviates drastically from the
original topic of the thread. There will be users who prefer to use
hyperxmp package and users who prefer pdfx. Hyperxmp is probably more
recommended, but I don't know either one deeply, so I couldn't say. In
any case: I think the central issue is to provide support for inserting
arbitrary code before \documentclass. The pdfx example is just one valid
example (ideally Org should not put obstacles to the use of any
package). As I said, there are more cases. For example, a few packages
(I don't remember their names) are recommended to be loaded first using
\RequirePackage. And there is also the case of the \PassOptionsToPackage
command. A good practice in LaTeX documents is usually to put this
command at the very beginning of the document, to avoid messages such as
"option class for xx package error". It is placed at the very beginning
because there may be classes that already require the package involved
in the error. And one more example: a new package for LuaLaTeX was
recently uploaded to CTAN, which allows the use of shebangs in LaTeX
documents. In short, there are many heterogeneous cases, and it is the
very heterogeneity of these cases that leads to a solution similar to
LaTeX_header, IMHO. Actually, any code (except \usepackage) would be
possible before \cocumentclass.
>> For example, the newpax package, to preserve the internal links of a pdf
>> included in the document, requires putting commands like
>> \DocumentMetadata{ } before documentclass.
>
> If I understand it correctly, \DocumentMetadata is a switch to enable
> "new" LaTeX like it was for \documentclass vs. \documentstyle during
> transition to LaTeX2e from LaTeX 2.09.
https://tex.stackexchange.com/questions/686898/what-is-documentmetadata-what-key-value-pairs-does-it-take-and-when-should-i-u
(As for the transition from LaTeX2e to LaTeX 3, it seems that it is not
going to be as defined as the transition we witnessed in the leap from
LaTeX 2.09. In reality it seems that there is not going to be such a
leap but rather a "coexistence" of both worlds:
https://www.latex-project.org/publications/2020-FMi-TUB-tb128mitt-quovadis.pdf)
> If so, Org should have native support of \DocumentMetadata, not
> LATEX_PRE_HEADER or something similar.
If it were the only case of code before \documentclass, I would agree.
But, as I have already said above, the diversity of use cases makes the
implementation of /ad hoc/ solutions unviable, in my opinion.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
next prev parent reply other threads:[~2023-09-25 18:50 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 [this message]
2023-09-25 21:57 ` Thomas S. Dye
2023-09-26 15:39 ` Max Nikulin
2023-09-26 19:12 ` Juan Manuel Macías
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=875y3yytp4.fsf@posteo.net \
--to=maciaschain@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/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).