From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
Date: Thu, 28 Sep 2023 17:07:41 +0700 [thread overview]
Message-ID: <uf3j9f$62n$1@ciao.gmane.io> (raw)
In-Reply-To: <87lecsvjdd.fsf@posteo.net>
On 27/09/2023 02:12, Juan Manuel Macías wrote:
> Max Nikulin writes:
>> 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.
LaTeX code may be inserted
- before \DocumentMetadata
- between \DocumentMetadata and \documentclass
- between \documentclass and preamble added by Org
- between Org preamble and \begin{document}
Since ordering is important, I would prefer to assemble preamble from
predefined fragments (or replace particular ones) to putting code into
these (and probably more) slots.
>> \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)?
More I read about .xmpdata, more it looks similar to an ugly kludge from
my point of view. The following phrases are hardly consistent:
- "Including the metadata with the LATEX source is very convenient."
- "remember to remove the existing copy of \jobname.xmpdata file before
the next processing run".
(A side note: "overwrite" option of filecontents looks promising.)
So the goal is an XML document embedded into PDF. I admit, Org can not
provide it directly since e.g. PDF compliance level is responsibility of
a PDF engine.
However the intermediate .xmpdata file may be provided independently of
its .tex counterpart accordingly to docs. This file contains metadata
and in Org metadata are managed through keywords. Significant fraction
of metadata may be shared with HTML or MarkDown, so keywords should be
considered as primary data. Writing this file from Org (e.g. by a babel
source code block) should avoid issues with LaTeX input encodings
described in the docs. Thus generation of .xmpdata during exporting of
an .org file allows to keep metadata consistent.
Currently I do not see a way to get values of INFO argument of
org-export functions from source code blocks making access to metadata
tricky. This should be addressed somehow. I would consider specifying
metadata in a way similar to org-babel header arguments to allow more
fields than currently supported by Org. It should facilitate generation
of \DocumentMedata, .xmpdada, etc.
Ability to overwrite fragments of preamble should be supported, but only
as last resort. Specifying \DocumentMetadata or .xmpdata contents
literally should be avoided to prevent discrepancy with metadata keywords.
I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable (but
perhaps fragile) hack for LaTeX-first document. During export of Org
file, this file should be written directly with values from Org metadata.
next prev parent reply other threads:[~2023-09-28 10:08 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
2023-09-28 10:07 ` Max Nikulin [this message]
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='uf3j9f$62n$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--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).