Attached are two PDF files.  output.pdf has some XMP metadata that is
compressed.  Running "pdftk output.pdf output uncomp.pdf uncompress"
produces uncomp.pdf.  However, uncomp.pdf has corrupt XMP metadata.
This is because it inserts an xmp:ModifyDate element into the metadata,
but does not ensure that there is a namespace declaration for the xmp
prefix.  Consequently, the XML is ill-formed.

Ideally, pdftk would not modify the XMP metadata at all, but if it must,
it should ensure that the XMP metadata it outputs is always well-formed
XML.

reassign 603284 libitext-java 2.1.7-2
retitle libitext-java: corrupts XMP metadata
affects 603284 pdftk
--

Thanks for your bug report.

I reassign this bug to libitext-java, because
the wrong XMP metadata is generated automatically by itext, which is
used by pdftk 1.41+dfsg-9.

This bug does not affect pdftk 1.44 (packaged in experimental),
because this new version uses bundled itext-paulo instead of itext 2.1.7
and therefore does not modify XMP metadata.

There is an encoding problem in output.pdf which maybe trigger this bug:
The XML data are encoded in ISO 8859-1 or ISO 8859-15 but nowhere this
encoding is set explicitly.

For example, evince prints the following error message:
Entity: line 10: parser error : Input is not proper UTF-8, indicate
encoding !
Bytes: 0xAE 0x20 0x4F 0x66
   xap:CreatorTool="Microsoft� Office Word 2007"
                             ^
The call
 pdftk output.pdf output /dev/null
without the uncompress option gives an exception in itext:

Unhandled Java Exception:
gnu.xml.dom.ls.DomLSException
   at gnu.xml.dom.ls.DomLSParser.doParse(DomLSParser.java:326)
   at gnu.xml.dom.ls.DomLSParser.parse(DomLSParser.java:159)
   at gnu.xml.dom.DomDocumentBuilder.parse(DomDocumentBuilder.java:128)
   at com.lowagie.text.xml.xmp.XmpReader.<init>(itext-2.1.7.jar.so)
   at com.lowagie.text.pdf.PdfStamperImp.close(itext-2.1.7.jar.so)
Caused by: org.xml.sax.SAXParseException
   at gnu.xml.stream.SAXParser.parse(SAXParser.java:661)
   at gnu.xml.dom.ls.DomLSParser.doParse(DomLSParser.java:308)
   ...4 more
Caused by: javax.xml.stream.XMLStreamException
   at gnu.xml.stream.XMLParser.next(XMLParser.java:1215)
   at gnu.xml.stream.SAXParser.parse(SAXParser.java:380)
   ...5 more
Caused by: java.io.IOException: unpaired surrogate: U+dad3
   at gnu.xml.stream.UnicodeReader.read(UnicodeReader.java:142)
   at gnu.xml.stream.XMLParser$Input.read(XMLParser.java:5246)
   at gnu.xml.stream.XMLParser.read(XMLParser.java:1254)
   at gnu.xml.stream.XMLParser.tryRead(XMLParser.java:1359)
   at gnu.xml.stream.XMLParser.next(XMLParser.java:1159)

Yes, I know this.  It's a testcase for a bug I'm working on fixing, and
it happens to be broken, since XMP requires using a Unicode encoding.
But thanks for pointing it out.

Right.  The metadata should definitely be UTF-8, and it's okay with me
if pdftk complains and refuses to perform any action whatsoever.  But
deciding to modify the data in a peculiar and bizarre way is not okay.
As I said, I'd prefer if the behavior were not to modify the XMP data at
all, regardless of whether it's done by iText or pdftk.

Hi

I've developped a patch to make iText not modify metadata on
PdfStamperImp.java unless explicitily instructed.

Patch attached