How to embed abstract as an XMP metadata?

Question

Can hyperxmp embed the document's abstract as an XMP metadata in LaTeX? If not, can anyone suggest a way on how I can execute this?

Answer 1

Currently, there are two three packages that I am aware of that will embed XMP: hyperxmp xmpincl and pdfx. The advantage of the first is that it is easy to use; the second is perhaps more extensible.

Another consideration is that, according to (a fairly quick glance at the three files that comprise) the XMP specification, there is no innate "abstract" property. Your two most suitable options are:

• dc:description, which is (supposed to be) 'an account of the resource'; and
• dc:subject, which is (supposed to be) 'the topic of the resource', adding the following comment: 'Typically, the subject will be represented using keywords, key phrases, or classification codes....'

With hyperxmp, these are already mapped to specific options. xmpincl expects you to do what you want and what you are required to do, and provides very little help to make sure things turn out OK.

Hyperxmp is designed to be used with hyperref, and it maps these two fields in the following way:

• dc:description to pdfsubject
• dc:subject to pdfkeywords

This suggests that the easiest way to embed the abstract is to put it in hyperref's pdfsubject as mediated by hyperxmp. Something like this:

\documentclass{article}
\usepackage{lipsum}% just for the example
\usepackage{hyperxmp}
\usepackage{hyperref}

% Set metadata once for reuse
\newcommand\myabstract{%
  hyperxmp makes it easy for an author to include xmp metadata in a
  pdf document produced by \texorpdfstring{\LaTeX}{LaTeX} seamlessly
  with hyperref and requires virtually no modifications to a document
  that already specifies document metadata through hyperref’s
  mechanisms.}

\title{Abstracts in XMP Metadata}
\author{\myauthor}

\hypersetup{%
  pdfsubject={\myabstract},
}

\begin{document}
\maketitle

\begin{abstract}
  \myabstract
\end{abstract}

\lipsum[1]

\end{document}

This seems to work. However, I am on Linux and cannot easily see what happens to this file with Adobe Acrobat. pdfinfo returns the following:

Title:          Abstracts in XMP Metadata
Subject:        hyperxmp makes it easy for an author to include xmp metadata in a pdf document produced by LaTeX seamlessly with hyperref and requires virtually no modifications to a document that already specifies document metadata through hyperref's mechanisms.
Keywords:       
Author:         Jane Smith
Creator:        LaTeX with hyperref package
Producer:       pdfTeX-1.40.16
[... etc....]

I would be curious to have someone confirm that things are as they should be in a more XMP-aware environment. Note also that there are some special rules to observe about including commas in fields that are comma-separated (e.g., pdfauthor and pdfkeywords); consult the manual for more information.

XMPincl is less user-friendly, at least at first. You must set up an .xmp file, which you then include. Using the package in your LaTeX document is easy. The author recommends calling the package before \documentclass, so a simple file would look like this:

\RequirePackage{xmpincl}
\includexmp{example}
\documentclass{article}
\usepackage{lipsum}
% \usepackage{hyperref}

\begin{document}

\begin{abstract}
  xmpincl makes it possible for an author to include xmp metadata in a
  pdf document produced by \LaTeX.
\end{abstract}

\lipsum[1]

\end{document}

However, you need to have also a file in the same directory (which I happen to have called) example.xmp, which should look something like this:

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c017 91.164374, 2020/03/05-20:41:30        ">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">xmpincl</rdf:li>
            </rdf:Alt>
         </dc:title>
         <dc:description>
            <rdf:Alt>
                <rdf:li xml:lang="x-default">A LaTeX package to include XMP metadata in files generated through pdfLaTeX</rdf:li>
            </rdf:Alt>
         </dc:description>
         <dc:creator>
            <rdf:Seq>
               <rdf:li>Maarten Sneep</rdf:li>
            </rdf:Seq>
         </dc:creator>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

pdfinfo -meta gives me:

[…]
<dc:description>
<rdf:Alt>
<rdf:li xml:lang="x-default">A LaTeX package to include XMP metadata in files generated through pdfLaTeX</rdf:li>
</rdf:Alt>
</dc:description>
[... etc....]

So this works as well. A drawback is that if you use hyperref also, there's no (easy?) way to re-use the metadata as I did with the hyperxmp example above. That means you're going to be putting them in the hyperref fields anyway (or at least some of these entries).

PDFX also allows for adding metadata via XMP (it relies on xmpincl) The manual is quite helpful, and suggests as I did above to use what amounts to as dc:description via the \Subject command of pdfx. The other key thing to be aware of is that you should call the XMP data file the same name as the actual .tex file, but with the extension .xmpdata. That is, if your file is called myfile.tex, name the metadata file myfile.xmpdata. (Note: this is easily accomplished with the \jobname primitive, which the example below uses.)

Here's an example file constructed mostly from the package's manual:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lipsum}
\usepackage[colorlinks]{hyperref}

\usepackage{filecontents}
% Notes:
% - It is suggested you put this file right before you load `pdfx`
% - `pdfx` depends on `hyperref`, so you need to load it before `pdfx`
%   if you are going to load `hyperref` with options
% - The information below comes from the `pdfx` manual
\begin{filecontents*}{\jobname.xmpdata}
\Title{Baking through the ages}

\Author{A. Baker\sep C. Kneader}

\Keywords{cookies\sep muffins\sep cakes}

\Subject{The abstract.}

\Publisher{Baking International.}

\Copyright{A copyright statement.}

\CopyrightURL{location of a web page describing the owner and/or
  rights statement for this document.}

\Copyrighted{‘True’ if the document is copyrighted, and ‘False’ if it
  isn’t. This is au- tomatically set to ‘True’ if either}

\PublicationType{The type of publication. If defined, must be one of
  ‘book’, ‘catalog’, ‘feed’, ‘journal’, ‘magazine’, ‘manual’,
  ‘newsletter’, ‘pamphlet’. This is automatically set to ‘journal’ if
  \string\Journaltitle is specified, but can be overridden.}

\Journaltitle{The title of the journal in which the document was
  published.}

\Journalnumber{The ISSN for the publication in which the document was
  published.}

\Volume{Journal volume.}

\Issue{Journal issue/number.}

\Firstpage{First page number of the published version of the
  document.}

\Lastpage{Last page number of the published version of the document.}

\Doi{Digital Object Identifier (DOI) for the document, without the
  leading ‘doi:’.}

\CoverDisplayDate{Date on the cover of the journal issue, as a
  human-readable text string.}

\CoverDate{Date on the cover of the journal issue, in a format
  suitable for storing in a database field with a ‘date’ data type;
  e.g. YYYY-MM, or YYYY-MM-DD.}

\end{filecontents*}
\usepackage{pdfx}

\begin{document}

\lipsum[1]

\end{document}

This will produce a file called pdfa.xmpi (It is PDF/A because of the options [not] used.) And the XMP data produced is valid according to http://www.pdflib.com/knowledge-base/xmp-metadata/free-xmp-validator/

Thus, I would suggest either hyperxmp or pdfx as a good method for embedding things like the abstract in the metadata.

Answer 2

hyperxmp works on Mac OSX with XeLaTeX (2021). The abstract is stored in the Subject field, which can be viewed in Acrobat DC 2021, Preview, Skim, XnViewMP, and Finder. However, all, except Finder truncate the subject field. Only Finder is displaying it in multiline. So, my advice is to avoid putting any long text into the subject because in most pdf readers it won't be readable.