--cleartext-metadata option removes metadata entries
PDF transformation/manipulation program + library
Brought to you by:
jay_berkenbilt,
m-holger
Hello. I apologize for the delay in response to your bug report. I'm not able to see exactly what you're referring to here. What I see is a single /Metadata entry in the root object, and the metadata object itself contains some XML text with the various keywords and so forth. When I run the command you provided, I still see the same thing: a single /Metadata key in the root object pointing to XML data, and when I extract the data from both files, the contents are the same. Also the metadata does appear in clear text in the encrypted file as it should.
Can you please clarify exactly what you're doing to see the behavior you're seeing? What tools are you using to look at this, and what exactly are you referring to as the "metadata tree" and subentries therein? Thanks!
XMP metadata differences; test files and description
Hello Jay. The delay is not a real problem, thanks for taking the time.
The XMP metadata is not equal; more info in the attached 7zip.
Great, thanks for the additional information. Hopefully I will have time to look into this at some point in the not-too-distant future.
I'm not able to find the option you describe in Adobe reader. I might have access to the full Acrobat at work somewhere. I'll see if I can find some time to look into the problem. qpdf itself is not doing anything to the metadata stream and should be fully content-preserving, so I'll have to see if I can figure out what's really going on here. Opening the file in a text editor, I see no differences in the metadata stream at all. Anyway, I'll dig deeper as time permits.
Sorry for the inconvenience. I have tested it with the only other PDF viewer on my system - PDF-XChange Viewer. The XMP metadate tree is visible here (same procedure to get there), but saving is not possible.
Anyhow, the XMP metadata is shown correctly in both PDF there. A direct view into the PDF gave the same result. So you are right, the problem is not the stream data itself.
Mh, looks more tricky than expected. I'll investigate further and report back then.
uncompressed PDF
I have made new, uncompressed examples, so that you can easily 'read' the PDF.
The \Root entry looks equal too, so where to look else? Seems more like an Acrobat bug to me. If I find out something new, I will add a note here. Thanks for the help!
Sounds like it might be an Acrobat bug. It wouldn't be the first time. One way that I sometimes compare PDF files is to run qpdf -qdf on the files and compare the results. in QDF mode, qpdf writes out the file in a predictable way. If you use the --no-original-object-ids and --qdf flags together on the original file and on the linearized, encrypted file, you should be able to diff the results. I'm not sure what OS you're using, but on a UNIX-based OS (Linux, for example), you can probably use diff -a on the two files, and they should be exactly or nearly identical. Unless you use the --static-id option (which is intended only for testing and debugging), then at least the /ID line will differ, but otherwise they may be the same. I do this in the qpdf test suite in a number of cases to make sure that content is fully preserved by numerous of qpdf's transitions.
I wonder whether Acrobat has a problem if you don't specify --cleartext-metadata. Maybe there is some issue there. But I see in Adobe reader that at least some of the metadata fields are visible.
Anyway, it will be interesting to see what you find out. I won't pursue this further for now, but I'd like to know what you learn. Particularly if you find a PDF file with extended metadata information that is not encrypted in an otherwise encrypted file and that Acrobat does display, it would be good to inspect that file and see what sort of structural differences it might have from the one qpdf has. I don't know whether there is a mechanism to report a bug in Acrobat and get a response. If there is, that might be another way to go.
I'm guessing at this point that this is not actually a bug with qpdf, so I'm going to close this issue. However, if you do find that it's a qpdf problem or have additional information, feel free to reopen or post a new issue. Thanks!
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
Hello,
I'm seeing the same issue with Evince document viewer on Lubuntu.