Add support for Adobe Extensible Metadata Platform (XMP)

[GreyWyvern]

Is your feature request related to a problem? Please describe.
This pdfparser currently only accesses the standard document metadata through InformationDictionary. It ignores any metadata included with Adobe's XMP system. https://developer.adobe.com/xmp/docs/

Describe the solution you'd like
Add support for reading custom metadata from XMP blocks in PDFs if available. This is one of the big changes I added to the Smalot PdfParser and I crave it. If you need any advice or help implementing it, let me know.

[PrinsFrank]

Thanks for the suggestion! Looks to be easily implemented! Would you have an example document that can can be added to this codebase as a test case? Or one that I can at least test with?

What use case do you have for this? Is there a scenario where data like a creator is not set in the information dictionary but is set in the metadata? Just curious, and relevant for how this will be implemented in the code. ;)

[GreyWyvern]

I think pretty much any document edited with Acrobat or output by Adobe tools gets such a section. The Dublin Core <dc> module in particular is very widely used. Here's an example section from one of our PDFs where I work. The file is huge though, so I'll try to find one that smaller and freely available.

42 0 obj
<</Length 3469/Subtype/XML/Type/Metadata>>stream
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c015 84.159810, 2016/09/10-02:41:30        ">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:xmp="http://ns.adobe.com/xap/1.0/"
            xmlns:pdf="http://ns.adobe.com/pdf/1.3/"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/">
         <xmp:CreateDate>2016-06-23T16:47:33-04:00</xmp:CreateDate>
         <xmp:CreatorTool>PScript5.dll Version 5.2.2</xmp:CreatorTool>
         <xmp:ModifyDate>2017-07-11T08:47:34-04:00</xmp:ModifyDate>
         <xmp:MetadataDate>2017-07-11T08:47:34-04:00</xmp:MetadataDate>
         <pdf:Producer>Acrobat Distiller 10.1.13 (Windows)</pdf:Producer>
         <dc:format>application/pdf</dc:format>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">AMC_Networks.ai</rdf:li>
            </rdf:Alt>
         </dc:title>
         <dc:creator>
            <rdf:Seq>
               <rdf:li>RPool</rdf:li>
            </rdf:Seq>
         </dc:creator>
         <xmpMM:DocumentID>uuid:17a09839-9775-4a67-967e-222e7a3046ef</xmpMM:DocumentID>
         <xmpMM:InstanceID>uuid:97a33c9f-31a6-45b1-aefd-0ff4f10ebb3a</xmpMM:InstanceID>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

A notable thing about the XMP, especially Dublin Core, is that it allows multiple values for properties. The document above could easily have three "creators" by doing:

<dc:creator>
   <rdf:Seq>
      <rdf:li>RPool</rdf:li>
      <rdf:li>CDavis</rdf:li>
      <rdf:li>JKing</rdf:li>
   </rdf:Seq>
</dc:creator>

In quite a few documents we have, the documents have things like "Description" or "Keywords" or even "Titles" that are only in the XMP and not in the regular InformationDictionary. I believe this might be because someone input values for these properties that contain characters the regular InformationDictionary character encoding doesn't support. But don't quote me on that.

When I use the Smalot PDFParser, my search script tries to get the regular InformationDictionary values first, and if nothing is found, it goes through several standard XMP properties to find them instead. Like so:

// Prefer regular PDF metadata first, then try XMP
$getItems = array(
  'title' => array('Title', 'dc:title', 'pdf:title'),
  'description' => array('Subject', 'dc:description', 'pdf:subject'),
  'keywords' => array('Keywords', 'dc:subject', 'pdf:keywords'),
  'modified' => array('SourceModified', 'pdfx:sourcemodified', 'CreationDate', 'xmp:createdate')
);

[GreyWyvern]

Oh, It's also important to note that XMP blocks can also be added for individual parts of a PDF, like an embedded image, or a table, instead of the entire document. The code I wrote made sure the <dc:format> of the XMP block being used was application/pdf as a strong indicator the block was referring to the entire document itself, but there's probably a better, more 100% way of ensuring that.

[GreyWyvern]

You can use this file I created for the Smalot PdfParser when I fixed an issue with PDFDocEncoding in the InformationDictionary. I noticed at the time that the same values were stored in perfect UTF-8 in the XMP data, so it made sense to add functionality to get that data somehow.

https://github.com/smalot/pdfparser/blob/master/samples/bugs/Issue609.pdf