keywords are enumerated wrongly in PDF

[jonassmedegaard]

The default template data/templates/hypersetup.latex enumerates keywords using simple comma. That fails to properly encode keywords that contains a comma.

Please replace this line:

  pdfkeywords={$for(keywords)$$keywords$$sep$, $endfor$},

with these:

  pdfkeywords={$for(keywords)$
    \xmpquote{$keywords$}$sep$, $endfor$},

The difference can be seen when generating a tagged PDF and extracting the embedded XMP metadata (a crude way to do that is to open the PDF file in a text editor, because the XMP data is uncompressed).

[jonassmedegaard]

Whoops - initially I titled this issue as also affecting authors, but it seems only Quarto, not Pandoc, auto-generates listings of multi-authored documents.

For those curious - now that I accidentally revealed that larger scope - a fix for both is here.

[SmallHollow]

After upgrading pandoc to 3.9.0.2, I get an error:

Error producing PDF.
! Undefined control sequence.
<argument> \xmpquote 
                     {keywordA}, \xmpquote {keywordB}, \xmpquot...
l.198   pdfcreator={LaTeX via pandoc}}

If I remove the keywords from the YAML metadata block, the problem disappears.

I believe this issue is related to this recent change.

[jonassmedegaard]

Hmm. It looks like \xmpquote is implemented in the LaTeX package hyperxmp, so if using different hyperref drivers it will fail.

Perhaps the solution is to simply add this shim, after loading hyperref and before first use of \xmpquote:

\@ifundefined{xmpquote}{%
  \newcommand{\xmpquote}[1]{#1}%
}{}

[jgm]

@jonassmedegaard this is unfortunate. I'm not understanding the issue. Is it a matter of including the hyperxmp package? Did you not test with the default template?

[jonassmedegaard]

I tested with the default template.

I did not test using a variety of usage patterns.
My own use is with modern LuaLaTeX where (as I now understand it) hyperref by default uses hyperxmp.

Assuming my current understanding is correct, then indeed one solution is to load hyperxmp in the default template. I don't think that is a nice solution, however: That forces use of a specific hyperref driver which really is unneeded. What is needed is that when \xmpquote is defined then it is relevant to use it, and if it is not defined (i.e. when another hyperref driver is used, either because another one is chosen or because an older LaTeX is used) then fall back to doing nothing.

So I propose to replace the (recently changed)

  pdfkeywords={$for(keywords)$
    \xmpquote{$keywords$}$sep$, $endfor$},

with this:

  \@ifundefined{xmpquote}{%
    % dummy-implement command only need by the hyperref driver hyperxmp
    \newcommand{\xmpquote}[1]{#1}%
  }{}
  pdfkeywords={$for(keywords)$
    \xmpquote{$keywords$}$sep$, $endfor$},

[SmallHollow]

I'd like to add that I was using xelatex pdf-engine with the latest MacTeX-2026 distribution.

[jonassmedegaard]

thanks for the added detail, @SmallHollow - with that modern setup you should have the following options:

1. add \newcommand{\xmpquote}[1]{#1} before defining pdfkeywords
   (i.e. my workaround proposed above)
2. use hyperxmp somewhere in the header
3. set pdfstandard.version in document metadata

Option 1) leads to wrongly enumerated keywords in PDF metadata, but you might not care about that.

Option 2) should be adueqate to generate correctly enumerated keywords in PDF metadata, and let you stay with XeLaTeX.

Option 3) enables modern PDF rendering using LuaLaTeX - I am not sure how well it works if you insist on staying with XeLaTeX while enabling modern rendering - I guess it will work, but not sure.

[jgm]

Regarding 2: the manual says

To use hyperxmp, merely put a \usepackage{hyperxmp} in your document’s pream-
ble. That line can appear anywhere after the \usepackage{hyperref} but before
hyperref’s pdf options are specified with \hypersetup.

[jonassmedegaard]

My only concern with option 2) is that it raises the bar for the LaTeX environment to one that comes with hyperxmp.

[SmallHollow]

@jonassmedegaard , thank you for your suggestions to solve this problem.

The reason I went from LuaLaTeX to XeLaTeX is because the former is too slow for my purposes. I'm working on a 250-page document and LuaLaTeX is ca. 2,5x slower than XeLaTeX (in seconds: 12 vs. 30). At this stage, I prefer XeLaTeX's speed over any modern features LuaLaTeX may have.

Anyway, I just removed the keywords from the YAML metadata so I don't have to worry about this until later.