-
They have to be ot_* rather than qpdf_ot_* for compatibility. * Different enumerated types are not assignment-compatible in C++, at least with strict compiler settings * While you can do `constexpr ot_xyz = ::qpdf_ot_xyz` in QPDFObject.hh to make QPDFObject::ot_xyz work, QPDFObject::object_type_e::ot_xyz will only work if the enumerated type names are the same.
-
* Make it a runtime error, not a logic error * Include additional information * Capture it properly in checkLinearization
-
* Handle error conditions that occur when using the object handle interfaces. In the past, some exceptions were not correctly converted to errors or warnings. * Add more detailed information to qpdf-c.h * Make it possible to work more explicitly with uninitialized objects
-
It was exercised in the pdf-linearize example but not in qpdf-ctest.
-
Return new qpdf_oh from qpdf_oh_wrap_in_array when input is already an array. Update some doc comments in qpdf-c.h.
-
Don't assume endobj is at the beginning of the line. This means we are looking at tokens for every line, but the odds of n n obj appearing in the middle of the object are likely much lower than endobj not being at the beginning of the line or missing entirely. This will probably have a negative impact on recovery time for very large files. Hopefully it will be worth it.
-
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.