diff options
| -rw-r--r-- | ChangeLog | 6 | ||||
| -rw-r--r-- | TODO | 396 | ||||
| -rw-r--r-- | include/qpdf/QPDF.hh | 11 | ||||
| -rw-r--r-- | include/qpdf/QPDFObjectHandle.hh | 40 | ||||
| -rw-r--r-- | libqpdf/QPDF.cc | 18 | ||||
| -rw-r--r-- | libqpdf/QPDFAcroFormDocumentHelper.cc | 2 | ||||
| -rw-r--r-- | libqpdf/QPDFObjectHandle.cc | 30 | ||||
| -rw-r--r-- | libqpdf/QPDFWriter.cc | 2 | ||||
| -rw-r--r-- | libqpdf/QPDF_json.cc | 11 | ||||
| -rw-r--r-- | libqpdf/QPDF_linearization.cc | 24 | ||||
| -rwxr-xr-x | qtest/bin/qtest-driver | 2 |
11 files changed, 292 insertions, 250 deletions
@@ -1,3 +1,9 @@ +2022-08-06 Jay Berkenbilt <ejb@ql.org> + + * Added by m-holger: QPDF::getObject() method as a simpler form of + getObjectByID or getObjectByObjGen. The older methods are being + retained for compatibility and are not deprecated. + 2022-07-24 Jay Berkenbilt <ejb@ql.org> * include/qpdf/JSON.hh: Schema validation: allow a single item to @@ -4,9 +4,14 @@ Next Before Release: -* At next release, hide release-qpdf-10.6.3.0cmake* versions at readthedocs +* Improve performance around QTC + * Make it possible to compile it out and deal with it in the tests + * Make sure at least some CI test is run with coverage enabled + * Cache environment variables + * Remove coverage cases for things that are heavily exercised or are + in critical paths +* Evaluate issues tagged with `next` * Stay on top of https://github.com/pikepdf/pikepdf/pull/315 -* Release qtest with updates to qtest-driver and copy back into qpdf Next: * Support json v2 in the C API. At a minimum, write_json, @@ -21,31 +26,15 @@ Pending changes: appimage build specifically is setting the runpath, which is actually desirable in this case. Make sure to understand and document this. Maybe add a check for it in the build. -* Decide what to do about #664 (get*Box) -* Add an option --ignore-encryption to ignore encryption information - and treat encrypted files as if they weren't encrypted. This should - make it possible to solve #598 (--show-encryption without a - password). We'll need to make sure we don't try to filter any - streams in this mode. Ideally we should be able to combine this with - --json so we can look at the raw encrypted strings and streams if we - want to, though be sure to document that the resulting JSON won't be - convertible back to a valid PDF. Since providing the password may - reveal additional details, --show-encryption could potentially retry - with this option if the first time doesn't work. Then, with the file - open, we can read the encryption dictionary normally. -* In libtests, separate executables that need the object library - from those that strictly use public API. Move as many of the test - drivers from the qpdf directory into the latter category as long - as doing so isn't too troublesome from a coverage standpoint. -* Consider adding fuzzer code for JSON -* Consider generating a non-flat pages tree before creating output to - better handle files with lots of pages. If there are more than 256 - pages, add a second layer with the second layer nodes having no more - than 256 nodes and being as evenly sizes as possible. Don't worry - about the case of more than 65,536 pages. If the top node has more - than 256 children, we'll live with it. -Parent pointer idea: +Soon: Break ground on "Document-level work" + +Fix Multiple Direct Object Owner Issue +====================================== + +These are some ideas I've had, but I'm parking them until I fully +understand m-holger's proposal to split QPDFObject into QPDFObject and +QPDFValue. * Add std::weak_ptr<QPDFObject> parent to QPDFObject. When adding a direct object to an array or dictionary, set its parent. When @@ -65,8 +54,6 @@ Note that arrays and dictionaries still need to contain QPDFObjectHandle because of indirect objects. This only pertains to direct objects, which are always "resolved" in QPDFObjectHandle. -Soon: Break ground on "Document-level work" - Possible future JSON enhancements ================================= @@ -376,169 +363,196 @@ directory or that are otherwise not publicly accessible. This includes things sent to me by email that are specifically not public. Even so, I find it useful to make reference to them in this list. - * Look at https://bestpractices.coreinfrastructure.org/en - - * Rework tests so that nothing is written into the source directory. - Ideally then the entire build could be done with a read-only - source tree. - - * Large file tests fail with linux32 before and after cmake. This was - first noticed after 10.6.3. I don't think it's worth fixing. - - * Consider updating the fuzzer with code that exercises - copyAnnotations, file attachments, and name and number trees. Check - fuzzer coverage. - - * Add code for creation of a file attachment annotation. It should - also be possible to create a widget annotation and a form field. - Update the pdf-attach-file.cc example with new APIs when ready. - - * Flattening of form XObjects seems like something that would be - useful in the library. We are seeing more cases of completely valid - PDF files with form XObjects that cause problems in other software. - Flattening of form XObjects could be a useful way to work around - those issues or to prepare files for additional processing, making - it possible for users of the qpdf library to not be concerned about - form XObjects. This could be done recursively; i.e., we could have a - method to embed a form XObject into whatever contains it, whether - that is a form XObject or a page. This would require more - significant interpretation of the content stream. We would need a - test file in which the placement of the form XObject has to be in - the right place, e.g., the form XObject partially obscures earlier - code and is partially obscured by later code. Keys in the resource - dictionary may need to be changed -- create test cases with lots of - duplicated/overlapping keys. - - * Part of closed_file_input_source.cc is disabled on Windows because - of odd failures. It might be worth investigating so we can fully - exercise this in the test suite. That said, ClosedFileInputSource - is exercised elsewhere in qpdf's test suite, so this is not that - pressing. - - * If possible, consider adding CCITT3, CCITT4, or any other easy - filters. For some reference code that we probably can't use but may - be handy anyway, see - http://partners.adobe.com/public/developer/ps/sdk/index_archive.html - - * If possible, support the following types of broken files: - - - Files that have no whitespace token after "endobj" such that - endobj collides with the start of the next object - - - See ../misc/broken-files - - - See ../misc/bad-files-issue-476. This directory contains a - snapshot of the google doc and linked PDF files from issue #476. - Please see the issue for details. - - * Additional form features - * set value from CLI? Specify title, and provide way to - disambiguate, probably by giving objgen of field - - * Pl_TIFFPredictor is pretty slow. - - * Support for handling file names with Unicode characters in Windows - is incomplete. qpdf seems to support them okay from a functionality - standpoint, and the right thing happens if you pass in UTF-8 - encoded filenames to QPDF library routines in Windows (they are - converted internally to wchar_t*), but file names are encoded in - UTF-8 on output, which doesn't produce nice error messages or - output on Windows in some cases. - - * If we ever wanted to do anything more with character encoding, see - ../misc/character-encoding/, which includes machine-readable dump - of table D.2 in the ISO-32000 PDF spec. This shows the mapping - between Unicode, StandardEncoding, WinAnsiEncoding, - MacRomanEncoding, and PDFDocEncoding. - - * Some test cases on bad files fail because qpdf is unable to find - the root dictionary when it fails to read the trailer. Recovery - could find the root dictionary and even the info dictionary in - other ways. In particular, issue-202.pdf can be opened by evince, - and there's no real reason that qpdf couldn't be made to be able to - recover that file as well. - - * Audit every place where qpdf allocates memory to see whether there - are cases where malicious inputs could cause qpdf to attempt to - grab very large amounts of memory. Certainly there are cases like - this, such as if a very highly compressed, very large image stream - is requested in a buffer. Hopefully normal input to output - filtering doesn't ever try to do this. QPDFWriter should be checked - carefully too. See also bugs/private/from-email-663916/ - - * Interactive form modification: - https://github.com/qpdf/qpdf/issues/213 contains a good discussion - of some ideas for adding methods to modify annotations and form - fields if we want to make it easier to support modifications to - interactive forms. Some of the ideas have been implemented, and - some of the probably never will be implemented, but it's worth a - read if there is an intention to work on this. In the issue, search - for "Regarding write functionality", and read that comment and the - responses to it. - - * Look at ~/Q/pdf-collection/forms-from-appian/ - - * When decrypting files with /R=6, hash_V5 is called more than once - with the same inputs. Caching the results or refactoring to reduce - the number of identical calls could improve performance for - workloads that involve processing large numbers of small files. - - * Consider adding a method to balance the pages tree. It would call - pushInheritedAttributesToPage, construct a pages tree from scratch, - and replace the /Pages key of the root dictionary with the new - tree. - - * Study what's required to support savable forms that can be saved by - Adobe Reader. Does this require actually signing the document with - an Adobe private key? Search for "Digital signatures" in the PDF - spec, and look at ~/Q/pdf-collection/form-with-full-save.pdf, which - came from Adobe's example site. See also - ../misc/digital-sign-from-trueroad/. If digital signatures are - implemented, update the docs on crypto providers, which mention - that this may happen in the future. - - * Qpdf does not honor /EFF when adding new file attachments. When it - encrypts, it never generates streams with explicit crypt filters. - Prior to 10.2, there was an incorrect attempt to treat /EFF as a - default value for decrypting file attachment streams, but it is not - supposed to mean that. Instead, it is intended for conforming - writers to obey this when adding new attachments. Qpdf is not a - conforming writer in that respect. - - * The whole xref handling code in the QPDF object allows the same - object with more than one generation to coexist, but a lot of logic - assumes this isn't the case. Anything that creates mappings only - with the object number and not the generation is this way, - including most of the interaction between QPDFWriter and QPDF. If - we wanted to allow the same object with more than one generation to - coexist, which I'm not sure is allowed, we could fix this by - changing xref_table. Alternatively, we could detect and disallow - that case. In fact, it appears that Adobe reader and other PDF - viewing software silently ignores objects of this type, so this is - probably not a big deal. - - * From a suggestion in bug 3152169, consider having an option to - re-encode inline images with an ASCII encoding. - - * From github issue 2, provide more in-depth output for examining - hint stream contents. Consider adding on option to provide a - human-readable dump of linearization hint tables. This should - include improving the 'overflow reading bit stream' message as - reported in issue #2. There are multiple calls to stopOnError in - the linearization checking code. Ideally, these should not - terminate checking. It would require re-acquiring an understanding - of all that code to make the checks more robust. In particular, - it's hard to look at the code and quickly determine what is a true - logic error and what could happen because of malformed user input. - See also ../misc/linearization-errors. - - * If I ever decide to make appearance stream-generation aware of - fonts or font metrics, see email from Tobias with Message-ID - <5C3C9C6C.8000102@thax.hardliners.org> dated 2019-01-14. - - * Look at places in the code where object traversal is being done and, - where possible, try to avoid it entirely or at least avoid ever - traversing the same objects multiple times. +* Add an option --ignore-encryption to ignore encryption information + and treat encrypted files as if they weren't encrypted. This should + make it possible to solve #598 (--show-encryption without a + password). We'll need to make sure we don't try to filter any + streams in this mode. Ideally we should be able to combine this with + --json so we can look at the raw encrypted strings and streams if we + want to, though be sure to document that the resulting JSON won't be + convertible back to a valid PDF. Since providing the password may + reveal additional details, --show-encryption could potentially retry + with this option if the first time doesn't work. Then, with the file + open, we can read the encryption dictionary normally. + +* In libtests, separate executables that need the object library + from those that strictly use public API. Move as many of the test + drivers from the qpdf directory into the latter category as long + as doing so isn't too troublesome from a coverage standpoint. + +* Consider generating a non-flat pages tree before creating output to + better handle files with lots of pages. If there are more than 256 + pages, add a second layer with the second layer nodes having no more + than 256 nodes and being as evenly sizes as possible. Don't worry + about the case of more than 65,536 pages. If the top node has more + than 256 children, we'll live with it. This is only safe if all + intermediate page nodes have only /Kids, /Parent, /Type, and /Count. + +* Look at https://bestpractices.coreinfrastructure.org/en + +* Consider adding fuzzer code for JSON + +* Rework tests so that nothing is written into the source directory. + Ideally then the entire build could be done with a read-only + source tree. + +* Large file tests fail with linux32 before and after cmake. This was + first noticed after 10.6.3. I don't think it's worth fixing. + +* Consider updating the fuzzer with code that exercises + copyAnnotations, file attachments, and name and number trees. Check + fuzzer coverage. + +* Add code for creation of a file attachment annotation. It should + also be possible to create a widget annotation and a form field. + Update the pdf-attach-file.cc example with new APIs when ready. + +* Flattening of form XObjects seems like something that would be + useful in the library. We are seeing more cases of completely valid + PDF files with form XObjects that cause problems in other software. + Flattening of form XObjects could be a useful way to work around + those issues or to prepare files for additional processing, making + it possible for users of the qpdf library to not be concerned about + form XObjects. This could be done recursively; i.e., we could have a + method to embed a form XObject into whatever contains it, whether + that is a form XObject or a page. This would require more + significant interpretation of the content stream. We would need a + test file in which the placement of the form XObject has to be in + the right place, e.g., the form XObject partially obscures earlier + code and is partially obscured by later code. Keys in the resource + dictionary may need to be changed -- create test cases with lots of + duplicated/overlapping keys. + +* Part of closed_file_input_source.cc is disabled on Windows because + of odd failures. It might be worth investigating so we can fully + exercise this in the test suite. That said, ClosedFileInputSource + is exercised elsewhere in qpdf's test suite, so this is not that + pressing. + +* If possible, consider adding CCITT3, CCITT4, or any other easy + filters. For some reference code that we probably can't use but may + be handy anyway, see + http://partners.adobe.com/public/developer/ps/sdk/index_archive.html + +* If possible, support the following types of broken files: + + - Files that have no whitespace token after "endobj" such that + endobj collides with the start of the next object + + - See ../misc/broken-files + + - See ../misc/bad-files-issue-476. This directory contains a + snapshot of the google doc and linked PDF files from issue #476. + Please see the issue for details. + +* Additional form features + * set value from CLI? Specify title, and provide way to + disambiguate, probably by giving objgen of field + +* Pl_TIFFPredictor is pretty slow. + +* Support for handling file names with Unicode characters in Windows + is incomplete. qpdf seems to support them okay from a functionality + standpoint, and the right thing happens if you pass in UTF-8 + encoded filenames to QPDF library routines in Windows (they are + converted internally to wchar_t*), but file names are encoded in + UTF-8 on output, which doesn't produce nice error messages or + output on Windows in some cases. + +* If we ever wanted to do anything more with character encoding, see + ../misc/character-encoding/, which includes machine-readable dump + of table D.2 in the ISO-32000 PDF spec. This shows the mapping + between Unicode, StandardEncoding, WinAnsiEncoding, + MacRomanEncoding, and PDFDocEncoding. + +* Some test cases on bad files fail because qpdf is unable to find + the root dictionary when it fails to read the trailer. Recovery + could find the root dictionary and even the info dictionary in + other ways. In particular, issue-202.pdf can be opened by evince, + and there's no real reason that qpdf couldn't be made to be able to + recover that file as well. + +* Audit every place where qpdf allocates memory to see whether there + are cases where malicious inputs could cause qpdf to attempt to + grab very large amounts of memory. Certainly there are cases like + this, such as if a very highly compressed, very large image stream + is requested in a buffer. Hopefully normal input to output + filtering doesn't ever try to do this. QPDFWriter should be checked + carefully too. See also bugs/private/from-email-663916/ + +* Interactive form modification: + https://github.com/qpdf/qpdf/issues/213 contains a good discussion + of some ideas for adding methods to modify annotations and form + fields if we want to make it easier to support modifications to + interactive forms. Some of the ideas have been implemented, and + some of the probably never will be implemented, but it's worth a + read if there is an intention to work on this. In the issue, search + for "Regarding write functionality", and read that comment and the + responses to it. + +* Look at ~/Q/pdf-collection/forms-from-appian/ + +* When decrypting files with /R=6, hash_V5 is called more than once + with the same inputs. Caching the results or refactoring to reduce + the number of identical calls could improve performance for + workloads that involve processing large numbers of small files. + +* Consider adding a method to balance the pages tree. It would call + pushInheritedAttributesToPage, construct a pages tree from scratch, + and replace the /Pages key of the root dictionary with the new + tree. + +* Study what's required to support savable forms that can be saved by + Adobe Reader. Does this require actually signing the document with + an Adobe private key? Search for "Digital signatures" in the PDF + spec, and look at ~/Q/pdf-collection/form-with-full-save.pdf, which + came from Adobe's example site. See also + ../misc/digital-sign-from-trueroad/. If digital signatures are + implemented, update the docs on crypto providers, which mention + that this may happen in the future. + +* Qpdf does not honor /EFF when adding new file attachments. When it + encrypts, it never generates streams with explicit crypt filters. + Prior to 10.2, there was an incorrect attempt to treat /EFF as a + default value for decrypting file attachment streams, but it is not + supposed to mean that. Instead, it is intended for conforming + writers to obey this when adding new attachments. Qpdf is not a + conforming writer in that respect. + +* The whole xref handling code in the QPDF object allows the same + object with more than one generation to coexist, but a lot of logic + assumes this isn't the case. Anything that creates mappings only + with the object number and not the generation is this way, + including most of the interaction between QPDFWriter and QPDF. If + we wanted to allow the same object with more than one generation to + coexist, which I'm not sure is allowed, we could fix this by + changing xref_table. Alternatively, we could detect and disallow + that case. In fact, it appears that Adobe reader and other PDF + viewing software silently ignores objects of this type, so this is + probably not a big deal. + +* From a suggestion in bug 3152169, consider having an option to + re-encode inline images with an ASCII encoding. + +* From github issue 2, provide more in-depth output for examining + hint stream contents. Consider adding on option to provide a + human-readable dump of linearization hint tables. This should + include improving the 'overflow reading bit stream' message as + reported in issue #2. There are multiple calls to stopOnError in + the linearization checking code. Ideally, these should not + terminate checking. It would require re-acquiring an understanding + of all that code to make the checks more robust. In particular, + it's hard to look at the code and quickly determine what is a true + logic error and what could happen because of malformed user input. + See also ../misc/linearization-errors. + +* If I ever decide to make appearance stream-generation aware of + fonts or font metrics, see email from Tobias with Message-ID + <5C3C9C6C.8000102@thax.hardliners.org> dated 2019-01-14. + +* Look at places in the code where object traversal is being done and, + where possible, try to avoid it entirely or at least avoid ever + traversing the same objects multiple times. ---------------------------------------------------------------------- diff --git a/include/qpdf/QPDF.hh b/include/qpdf/QPDF.hh index fcc17522..7c389c1d 100644 --- a/include/qpdf/QPDF.hh +++ b/include/qpdf/QPDF.hh @@ -382,8 +382,15 @@ class QPDF QPDF_DLL QPDFObjectHandle makeIndirectObject(QPDFObjectHandle); - // Retrieve an object by object ID and generation. Returns an - // indirect reference to it. + // Retrieve an object by object ID and generation. Returns an + // indirect reference to it. The getObject() methods were added + // for qpdf 11. + QPDF_DLL + QPDFObjectHandle getObject(QPDFObjGen const&); + QPDF_DLL + QPDFObjectHandle getObject(int objid, int generation); + // These are older methods, but there is no intention to deprecate + // them. QPDF_DLL QPDFObjectHandle getObjectByObjGen(QPDFObjGen const&); QPDF_DLL diff --git a/include/qpdf/QPDFObjectHandle.hh b/include/qpdf/QPDFObjectHandle.hh index 7ea6b062..5d9f52d5 100644 --- a/include/qpdf/QPDFObjectHandle.hh +++ b/include/qpdf/QPDFObjectHandle.hh @@ -319,7 +319,7 @@ class QPDFObjectHandle QPDF_DLL QPDFObjectHandle& operator=(QPDFObjectHandle const&) = default; QPDF_DLL - bool isInitialized() const; + inline bool isInitialized() const; // Return type code and type name of underlying object. These are // useful for doing rapid type tests (like switch statements) or @@ -367,7 +367,7 @@ class QPDFObjectHandle // This returns true in addition to the query for the specific // type for indirect objects. QPDF_DLL - bool isIndirect(); + inline bool isIndirect() const; // True for everything except array, dictionary, stream, word, and // inline image. @@ -1300,11 +1300,11 @@ class QPDFObjectHandle // QPDFObjGen instead. QPDF_DLL - QPDFObjGen getObjGen() const; + inline QPDFObjGen getObjGen() const; QPDF_DLL - int getObjectID() const; + inline int getObjectID() const; QPDF_DLL - int getGeneration() const; + inline int getGeneration() const; QPDF_DLL std::string unparse(); @@ -1846,4 +1846,34 @@ class QPDFObjectHandle::QPDFArrayItems QPDFObjectHandle oh; }; +inline QPDFObjGen +QPDFObjectHandle::getObjGen() const +{ + return og; +} + +inline int +QPDFObjectHandle::getObjectID() const +{ + return og.getObj(); +} + +inline int +QPDFObjectHandle::getGeneration() const +{ + return og.getGen(); +} + +inline bool +QPDFObjectHandle::isIndirect() const +{ + return initialized && (getObjectID() != 0); +} + +inline bool +QPDFObjectHandle::isInitialized() const +{ + return initialized; +} + #endif // QPDFOBJECTHANDLE_HH diff --git a/libqpdf/QPDF.cc b/libqpdf/QPDF.cc index 7e0dd11e..b96b0674 100644 --- a/libqpdf/QPDF.cc +++ b/libqpdf/QPDF.cc @@ -2148,7 +2148,7 @@ QPDF::reserveObjectIfNotExists(QPDFObjGen const& og) resolve(og); replaceObject(og, QPDFObjectHandle::Factory::makeReserved()); } - return getObjectByObjGen(og); + return getObject(og); } QPDFObjectHandle @@ -2159,15 +2159,27 @@ QPDF::reserveStream(QPDFObjGen const& og) } QPDFObjectHandle -QPDF::getObjectByObjGen(QPDFObjGen const& og) +QPDF::getObject(QPDFObjGen const& og) { return QPDFObjectHandle::Factory::newIndirect(this, og); } QPDFObjectHandle +QPDF::getObject(int objid, int generation) +{ + return getObject(QPDFObjGen(objid, generation)); +} + +QPDFObjectHandle +QPDF::getObjectByObjGen(QPDFObjGen const& og) +{ + return getObject(og); +} + +QPDFObjectHandle QPDF::getObjectByID(int objid, int generation) { - return getObjectByObjGen(QPDFObjGen(objid, generation)); + return getObject(QPDFObjGen(objid, generation)); } void diff --git a/libqpdf/QPDFAcroFormDocumentHelper.cc b/libqpdf/QPDFAcroFormDocumentHelper.cc index 23d021ff..6fec0587 100644 --- a/libqpdf/QPDFAcroFormDocumentHelper.cc +++ b/libqpdf/QPDFAcroFormDocumentHelper.cc @@ -183,7 +183,7 @@ QPDFAcroFormDocumentHelper::getFormFields() analyze(); std::vector<QPDFFormFieldObjectHelper> result; for (auto const& iter: this->m->field_to_annotations) { - result.push_back(this->qpdf.getObjectByObjGen(iter.first)); + result.push_back(this->qpdf.getObject(iter.first)); } return result; } diff --git a/libqpdf/QPDFObjectHandle.cc b/libqpdf/QPDFObjectHandle.cc index 152f1ae2..cf5460d7 100644 --- a/libqpdf/QPDFObjectHandle.cc +++ b/libqpdf/QPDFObjectHandle.cc @@ -286,12 +286,6 @@ QPDFObjectHandle::setObjectDescriptionFromInput( QUtil::int_to_string(offset))); } -bool -QPDFObjectHandle::isInitialized() const -{ - return this->initialized; -} - QPDFObject::object_type_e QPDFObjectHandle::getTypeCode() { @@ -435,12 +429,6 @@ QPDFObjectHandle::isReserved() } bool -QPDFObjectHandle::isIndirect() -{ - return this->initialized && (getObjectID() != 0); -} - -bool QPDFObjectHandle::isScalar() { return ( @@ -1499,24 +1487,6 @@ QPDFObjectHandle::replaceStreamData( sdp, filter, decode_parms); } -QPDFObjGen -QPDFObjectHandle::getObjGen() const -{ - return og; -} - -int -QPDFObjectHandle::getObjectID() const -{ - return og.getObj(); -} - -int -QPDFObjectHandle::getGeneration() const -{ - return og.getGen(); -} - std::map<std::string, QPDFObjectHandle> QPDFObjectHandle::getPageImages() { diff --git a/libqpdf/QPDFWriter.cc b/libqpdf/QPDFWriter.cc index e33d0965..028f73dc 100644 --- a/libqpdf/QPDFWriter.cc +++ b/libqpdf/QPDFWriter.cc @@ -1897,7 +1897,7 @@ QPDFWriter::writeObjectStream(QPDFObjectHandle object) // pass 1. indicateProgress(true, false); } - QPDFObjectHandle obj_to_write = this->m->pdf.getObjectByObjGen(obj); + QPDFObjectHandle obj_to_write = this->m->pdf.getObject(obj); if (obj_to_write.isStream()) { // This condition occurred in a fuzz input. Ideally we // should block it at at parse time, but it's not diff --git a/libqpdf/QPDF_json.cc b/libqpdf/QPDF_json.cc index a3d50cfb..131e7dee 100644 --- a/libqpdf/QPDF_json.cc +++ b/libqpdf/QPDF_json.cc @@ -14,8 +14,11 @@ // | st_initial // { | -> st_top -// "qpdf-v2": { | -> st_qpdf -// "objects": { | -> st_objects +// "qpdf": [ | -> st_qpdf +// { | -> st_qpdf_meta +// ... | ... +// }, | ... +// { | -> st_objects // "obj:1 0 R": { | -> st_object_top // "value": { | -> st_object // "/Pages": "2 0 R", | ... @@ -41,7 +44,7 @@ // } | <- st_trailer // } | <- st_objects // } | <- st_qpdf -// } | <- st_top +// ] | <- st_top // } | <- st_initial static char const* JSON_PDF = ( @@ -394,7 +397,7 @@ QPDF::JSONReactor::replaceObject( auto og = to_replace.getObjGen(); this->reserved.erase(og); this->pdf.replaceObject(og, replacement); - auto oh = pdf.getObjectByObjGen(og); + auto oh = pdf.getObject(og); setObjectDescription(oh, value); } diff --git a/libqpdf/QPDF_linearization.cc b/libqpdf/QPDF_linearization.cc index f89ed188..e988092e 100644 --- a/libqpdf/QPDF_linearization.cc +++ b/libqpdf/QPDF_linearization.cc @@ -706,7 +706,7 @@ QPDF::getUncompressedObject( return obj; } else { int repl = (*(object_stream_data.find(obj.getObjectID()))).second; - return getObjectByObjGen(QPDFObjGen(repl, 0)); + return getObject(repl, 0); } } @@ -1381,9 +1381,9 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) stopOnError("found other than one root while" " calculating linearization data"); } - this->m->part4.push_back(getObjectByObjGen(*(lc_root.begin()))); + this->m->part4.push_back(getObject(*(lc_root.begin()))); for (auto const& og: lc_open_document) { - this->m->part4.push_back(getObjectByObjGen(og)); + this->m->part4.push_back(getObject(og)); } // Part 6: first page objects. Note: implementation note 124 @@ -1412,11 +1412,11 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) // hint tables. for (auto const& og: lc_first_page_private) { - this->m->part6.push_back(getObjectByObjGen(og)); + this->m->part6.push_back(getObject(og)); } for (auto const& og: lc_first_page_shared) { - this->m->part6.push_back(getObjectByObjGen(og)); + this->m->part6.push_back(getObject(og)); } // Place the outline dictionary if it goes in the first page section. @@ -1462,7 +1462,7 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) for (auto const& og: this->m->obj_user_to_objects[ou]) { if (lc_other_page_private.count(og)) { lc_other_page_private.erase(og); - this->m->part7.push_back(getObjectByObjGen(og)); + this->m->part7.push_back(getObject(og)); ++this->m->c_page_offset_data.entries.at(i).nobjects; } } @@ -1479,7 +1479,7 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) // Order is unimportant. for (auto const& og: lc_other_page_shared) { - this->m->part8.push_back(getObjectByObjGen(og)); + this->m->part8.push_back(getObject(og)); } // Part 9: other objects @@ -1501,7 +1501,7 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) for (auto const& og: pages_ogs) { if (lc_other.count(og)) { lc_other.erase(og); - this->m->part9.push_back(getObjectByObjGen(og)); + this->m->part9.push_back(getObject(og)); } } @@ -1531,7 +1531,7 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) for (auto const& og: ogs) { if (lc_thumbnail_private.count(og)) { lc_thumbnail_private.erase(og); - this->m->part9.push_back(getObjectByObjGen(og)); + this->m->part9.push_back(getObject(og)); } } } @@ -1544,7 +1544,7 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) // Place shared thumbnail objects for (auto const& og: lc_thumbnail_shared) { - this->m->part9.push_back(getObjectByObjGen(og)); + this->m->part9.push_back(getObject(og)); } // Place outlines unless in first page @@ -1554,7 +1554,7 @@ QPDF::calculateLinearizationData(std::map<int, int> const& object_stream_data) // Place all remaining objects for (auto const& og: lc_other) { - this->m->part9.push_back(getObjectByObjGen(og)); + this->m->part9.push_back(getObject(og)); } // Make sure we got everything exactly once. @@ -1656,7 +1656,7 @@ QPDF::pushOutlinesToPart( lc_outlines.erase(outlines_og); part.push_back(outlines); for (auto const& og: lc_outlines) { - part.push_back(getObjectByObjGen(og)); + part.push_back(getObject(og)); ++this->m->c_outline_data.nobjects; } } diff --git a/qtest/bin/qtest-driver b/qtest/bin/qtest-driver index c37c4d1d..fa8d82c3 100755 --- a/qtest/bin/qtest-driver +++ b/qtest/bin/qtest-driver @@ -33,7 +33,7 @@ require TestDriver; if ((@ARGV == 1) && ($ARGV[0] eq '--version')) { - print "$whoami version 1.8\n"; + print "$whoami version 1.9\n"; exit 0; } if ((@ARGV == 1) && ($ARGV[0] eq '--print-path')) |