-
#863 uses a single null object for nulls that were previously implicit. In certain circumstances this shared null object gets destroyed (i.e changed to a QPDF_Destroyed object) when a QPDF object is destroyed. Modify the QPDF destructor so that null objects get disconnected from the dying QPDF object but not destroyed to prevent this from happening.
-
Code tidy re-throwing of exceptions
-
Avoid copying exceptions.
-
A new private overload of QPDF::makeIndirectObject breaks pikepdf's build, so renaming function.
-
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().
-
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.
-
This is in preparation for restoring a QPDFObject.hh to ease the transition on qpdf_object_type_e. This commit was created by * Renaming QPDFObject.cc and QPDFObject.hh * Replacing QPDFObject\b with QPDFValueProxy (where \b is word boundary) * Running format-code * Manually resorting files in libqpdf/CMakeLists.txt * Manually refilling the comment in QPDF.hh near class Resolver