-
For wildcard expansion to work properly with the msvc binary, it is necessary to link with setargv.obj or wsetargv.obj, depending on whether wmain is in use.
-
Even though this is disallowed by the spec, files like this have been encountered in the wild.
-
Various PDF digital signing tools do not encrypt /Contents value in signature dictionary. Adobe Acrobat Reader DC can handle a PDF with the /Contents value not encrypted. Write Contents in signature dictionary without encryption Tests ensure that string /Contents are not handled specially when not found in sig dicts.
-
It seems better not to compress signature dictionaries. Various PDF digital signing tools, including Adobe Acrobat Reader DC, do not compress signature dictionaries. Table 8.93 "Entries in a signature dictionary" in PDF 1.5 reference describes that /ByteRange in the signature dictionary shall be used to describe a digest that does not include the signature value (/Contents) itself. The byte ranges cannot be determined if the dictionary is compressed.
-
Table 8.93 "Entries in a signature dictionary" in PDF 1.5 reference describes that the value of Contents entry is a hexadecimal string representation when ByteRange is specified. This commit makes QPDF always uses hexadecimal strings representation instead of literal strings for it.
-
It's detected in QPDFWriter instead of at parse time because I can't figure out how to construct a test case in a reasonable time. This commit moves the fuzz file into the regular test suite for a QTC coverage case.
-
Just because we know an indirect reference is null, doesn't mean we shouldn't keep it indirect.
-
For some reason, qpdf from the beginning was replacing indirect references to null with literal null in arrays even after removing the old behavior of flattening scalar references. This seems like a bad idea.
-
This message used to only appear for PDF >= 1.2. The invalid name is valid for PDF 1.0 and 1.1. However, since QPDFWriter may write a newer version, it's better to detect and warn in all cases. Therefore make the warning more informative.
-
This change works around STL problems with Embarcadero C++ Builder version 10.2, but std::vector is more common than std::list in qpdf, and this is a relatively new API, so an API change is tolerable. Thanks to Thorsten Schöning <6223655+ams-tschoening@users.noreply.github.com> for the fix.
-
This also reverts the addition of a new checkLinearization that distinguishes errors from warnings. There's no practical distinction between what was considered an error and what was considered a warning.