OpenSystemsDevelopment / qpdf

Commit aea885aab292abfb583232f0069ee47acbd94bbd

Authored by Jay Berkenbilt
Committed by GitHub
2 parents e641a883 e93c5ec9

Merge pull request #1136 from m-holger/todo 

Update TODO.md regarding indirect nulls in QPDF_Dictionary
Inline Side-by-side
Showing 1 changed file with 3 additions and 3 deletions
... ... @@ -337,9 +337,9 @@ so, I find it useful to make reference to them in this list.
337 337 Note that there's nothing that says an indirect object in one update can't refer to an object that
338 338 doesn't appear until a later update. This means that QPDF has to hang onto indirect nulls,
339 339 including when they appear as dictionary values. In this case, QPDF_Dictionary::getKeys() ignores
340   - all keys with null values, and hasKey() returns false for keys that have null values. We would
341   - probably want to make QPDF_Dictionary able to handle the special case of keys that are indirect
342   - nulls and basically never have it drop any keys that are indirect objects. We also have to make
  340 + all keys with null values, and hasKey() returns false for keys that have null values. QPDF_Dictionary
  341 + already handles the special case of keys that are indirect nulls, which is used to reserve foreign
  342 + objects, including foreign pages which may or may not be copied. We also have to make
343 343 sure that the testing for this handles non-trivial cases of the targets of indirect nulls being
344 344 replaced by real objects in an update. Such indirect nulls should appear in tests as dictionary
345 345 values and as array values. In the distant past, qpdf used to replace indirect nulls with direct
... ...