-
Lazily load MD5 and RC4 once in the life of the program. Only load the legacy provider if RC4 is actually being used.
-
* Define it even though previous experiments have shown it to be unnecessary since it seems like it may be necessary after all * Add QPDF_DLL_CLASS to QPDFObjectHelper and QPDFDocumentHelper in case there's some future unknown reason why someone may want to have them and/or in case it helps with the weird QPDFNameTreeObjectHelper problem.
-
Avoid representing as PDF Doc encoding any string whose PDF Doc encoding representation starts with a UTF-16 or UTF-8 marker.
-
Base implementation of the buffer on std::basic_string<unsigned char>.
-
An indirect object reference to 0, 0 is invalid. If it appears in the file or is parsed from a string, the parser catches it. This check would only be useful for someone explicitly calling getObject with 0, 0, and that would trigger an error during resolve().
-
This was broken for cross-compilation and has probably been unnecessary for several years now. Also fix extraneous whitespace in related some tests.
-
Replace operator== and operator!=, which were testing for the same underlying object, with isSameObjectAs. This change was motivated by the fact that pikepdf internally had its own operator== method for QPDFObjectHandle that did structural comparison. I backed out qpdf's operator== as a courtesy to pikepdf (in my own testing) but also because I think people might naturally assume that operator== does a structural comparison, and isSameObjectAs is clearer in its intent.
-
Expose functions to the C API to create new loggers and to setLogger and getLogger for QPDF and QPDFJob.
-
QPDFValueProxy wasn't a good name for it. We decided the evil of having the header file be named QPDFObject_private.hh was less than the evil of having the class be named something other than what it should have been named.
-
Preparing to change the class name back to QPDFObject
-
I decided that it's actually fine to copy a direct object to another QPDF. Even if we eventually prevent a QPDFObject from having multiple parents, this could happen if an object is moved.
-
When a QPDF is destroyed, changing indirect objects to direct nulls makes them effectively disappear silently when they sneak into other places. Instead, we should treat this as an error. Adding a destroyed object type makes this possible.
-
The qpdf member was already sufficient. Removing this actually fixed a few pre-existing issues around detecting foreign ownership and allowing certain conditions to be warnings rather than exceptions.
-
Add copy_if_fallback and explain how it differs from copy_if_shared.