-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deactivate \keywords after \maketitle #2464
Deactivate \keywords after \maketitle #2464
Conversation
hmm, well, it's the wrong fix, isn't it? In the cited issue, the pdf actually has keywords appearing twice (whether or not that's healthy). But the underlying issue seems to be that |
Update: my PR appears to have accidentally unlocked |
On a third(!) look, I was fooled by missing a new page getting shipped. Indeed, the keywords appear twice in the PDF for this example. I still think my PR attempt is a good patch for the current approach of latexml, or do we really want to enable By "current approach" I am mostly refering to the comment above the maketitle binding:
Which I still think is a good strategy for now. |
or do we really want to enable |\keywords| to deposit
metadata before and after |\maketitle| in latexml?
I'd invert the question: Do we really want to disable that, when LaTeX
itself does not? It's maybe even ironic, since the original issue is
that latexml (in `LaTeX.pool`) disabled `\and` while `llncs.cls` does not.
In any case, I think the whole duplicate `\keywords` is a red herring
introduced simply to demonstrate that `\maketitle` had unexpected
side-effects.
|
Yes, but we've patched this school of herrings before, so might as well be consistent... We can keep the llncs-sepcific issue open until some better solution comes to mind, but I think the PR itself may avoid an edge case in the mid-term. |
what edge case? What is the problem you're trying to solve?
|
I am trying to disable all frontmatter-depositing macros after The edge case this avoids is depositing duplicate metadata unintentionally. The difference to latex this (continues to) cause is that in some .cls files the frontmatter macros after Edit: This has a healthy development approach to it as well, as redefining |
On 1/23/25 9:17 AM, Deyan Ginev wrote:
I am trying to disable all frontmatter-depositing macros after |
\maketitle| has been encountered, as is the current intent of the |
\maketitle| binding in LaTeX.pool.
I think you're inferring more intent than is there; the intent is to
emulate LaTeX's `\maketitle`.
The edge case this avoids is depositing duplicate metadata unintentionally.
But the metadata was *intentionally* duplicated. And your patch doesn't
avoid duplication, it avoids it completely where you apparently don't
want it.
The difference to latex this (continues to) cause is that in some .cls
files the frontmatter macros after |\maketitle| indeed do deposit ink to
the page, where latexml will silently ignore them. I think we can stay
consistent with that behavior (namely, include |\keywords| to the
neutralization code) until a larger redesign takes place.
LaTeXML silently ignores metadata? I don't recall having seen this. It
seems like a completely different bug (that would be more confusing to
fix later, if we patch things to perpetuate the bug). Shouldn't we just
fix that bug?
|
I think you mean article.cls here, which is where the Ok, if there is a moratorium on improving that, I will let that be as it is. |
Fixes #2263 .
That issue could also be closed as wontfix, as it is not really a "healthy" use of LaTeX syntax, since using \keywords after \maketitle is asking for trouble.
But since trouble is often a part of life, and we have some idiosyncratic code that caused the behavior, I took a pass ironing it out a little further.
Namely, after
\maketitle
executes in a document, we try to deactivate a number of frontmatter macros. This PR adds\keywords
to that list of macros, but also redoes the deactivation as a subroutine, so that deactivated macros can also consume their arguments. The guard in question seems to have been around since 2007, so I am conservatively sticking with it here.