-
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
-
Allow QPDFObjectHandle::obj to be set prior resolving object. ot_unresolved has been appended to the list object types in order to preserve the output of existing test cases.
-
Report mem usage
-
Part of #729
-
Also, revert inlining of unparse and operator << from commit 4c6640c in order to avoid exposing QUtil.
-
ABI breaking change
-
Also add stubs for top-level QPDF methods (createFromJSON, updateFromJSON)
-
Bidirectional base64; will be used by JSON v2.
-
It was being run at configuration time, not build time.
-
* Change DLL_EXPORT to libqpdf_EXPORTS (internal to the build). The new name is cmake's default, is more conventional, and is less likely to clash with other symbols. * Add QPDF_DLL_PRIVATE for non-Windows * Make logic around when to define QPDF_DLL et al more explicit * Add detailed comments
-
Also add a pkg-config runtime test that would have caught the error.
-
Some platforms need it for atomic<long long> but not for atomic<int>.