-
When making resources indirect in from_dr, the code was using the wrong owning QPDF, forgetting that from_dr had already been copied using CopyForeignObject.
-
When adding a QPDFObjectHandle to an array or dictionary, if possible, check if the new object belongs to the same QPDF. This makes it much easier to find incorrect code than waiting for the situation to be detected when the file is written.
-
This was originally not public because I wanted to get rid fo the pages cache, but I recently realized there were deep reasons not to do that, and the author of pikepdf wanted this, so I decided to make it public.
-
The /Subtype entry that specifies the mime type of an embedded file is inside the embedded file stream dictionary directly, not it in the parameter dictionary. See Table 45 and 46 in the PDF 1.7 specification: https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#page=112
-
Check for this->encrypt seems to be moved to plugged crypto implementations, so it can be removed from Pl_AES_PDF.cc.
-
Operations that add the same object to multiple places in the pages tree are throwing exceptions and then later causing assertion failures. The assert calls shouldn't be there.
-
Also handle direct annotation, though this is much less likely.
-
Also improve behavior around direct vs. indirect resources.
-
Converted ResourceFinder to ParserCallbacks so we can better detect the name that precedes various operators and use the operators to sort the names into resource types. This enables us to be smarter about detecting unreferenced resources in pages and also sets the stage for reconciling differences in /DR across documents.
-
If not found in the field hierarchy, /Q and /DA are supposed to be looked up in the document-level form dictionary. /DR is supposed to only come from the document dictionary.
-
This results in a performance penalty of 1% to 2% when replaceObject and swapObjects are never called and a somewhat larger penalty if they are called, but it's worth it to avoid very confusing behavior as discussed in depth in qpdf#507.