A PDF 1.0 to 1.4 file can say who made it, with what, when and what it is about, in two places. Every version has the document information dictionary, a short set of text entries named by the trailer. PDF 1.4 added metadata streams in Adobe’s XMP, an XML form that can describe the document and also any page, image or font in it. Writers of 1.4 files often fill in both, with the same values.
The document information dictionary
The trailer’s Info entry points at a dictionary of text strings and
dates. Every entry is optional.
| Key | Type | Since | Meaning |
|---|---|---|---|
Title | text string | 1.1 | The document’s title |
Author | text string | 1.0 | The person who made it |
Subject | text string | 1.1 | What it is about |
Keywords | text string | 1.1 | Keywords, in one string |
Creator | text string | 1.0 | The program the original was made in, if it was converted to PDF, such as a word processor |
Producer | text string | 1.0 | The program that wrote the PDF |
CreationDate | date | 1.0 | When the document was made |
ModDate | date | 1.1 | When it was last changed |
Trapped | name | 1.3 | Whether trapping has been done for printing: True, False or Unknown (the default) |
Other keys may be added, each with a text string value; viewers show them as custom properties. The dictionary from the small PDF 1.3 example:
1 0 obj
<< /Producer (Mac OS X 10.6 Quartz PDFContext) /CreationDate (D:20060214123151-08'00')
/ModDate (D:20060214123151-08'00') >>
endobjThe strings are text strings, in PDFDocEncoding or, from PDF 1.2, UTF-16BE; the dates are in the date format. In an encrypted file they are encrypted like any other string, because the dictionary is an ordinary object.
XMP metadata streams
From PDF 1.4 the catalog’s Metadata entry can point at a metadata
stream:
| Key | Meaning |
|---|---|
Type | Required: Metadata |
Subtype | Required: XML |
Length | Required, as in any stream |
The stream holds an XMP packet: RDF/XML wrapped in processing instructions, so that a tool which knows nothing of PDF can find it by scanning the bytes. Writers usually leave it uncompressed for that reason.
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/">
<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/"
xmlns:xmp="http://ns.adobe.com/xap/1.0/"
xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
<dc:title><rdf:Alt><rdf:li xml:lang="x-default">Annual report</rdf:li></rdf:Alt></dc:title>
<xmp:CreateDate>2002-03-15T10:21:00Z</xmp:CreateDate>
<pdf:Producer>Acrobat Distiller 5.0</pdf:Producer>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>The id value is fixed by the XMP specification. White space before
<?xpacket end is padding that lets the metadata grow in place;
end="w" says it may be written to.
Info entries in XMP
| Info key | XMP property |
|---|---|
Title | dc:title |
Author | dc:creator, a list |
Subject | dc:description |
Keywords | pdf:Keywords |
Creator | xmp:CreatorTool |
Producer | pdf:Producer |
CreationDate | xmp:CreateDate |
ModDate | xmp:ModifyDate |
Trapped | pdf:Trapped |
XMP dates are ISO 8601, unlike PDF’s D: strings. When the two
disagree, a reader can compare the Info dictionary’s ModDate with
the packet’s xmp:MetadataDate to see which was updated last: a
program that knew only the Info dictionary may have changed it alone.
Metadata for parts of a document
Any stream or dictionary that describes a component can have its own
Metadata stream from PDF 1.4: pages, image XObjects, form XObjects,
ICC profiles, embedded font files, and others. A photograph keeps its camera and
rights information this way when placed in a layout.
Programs can also keep private data, not metadata in this sense, in
PieceInfo dictionaries (PDF 1.3) on pages and form XObjects and (1.4)
in the catalog: one entry a program, each with a LastModified date and
a Private value only that program reads.