diff options
author | Jay Berkenbilt <ejb@ql.org> | 2013-11-30 22:04:21 +0100 |
---|---|---|
committer | Jay Berkenbilt <ejb@ql.org> | 2013-12-14 21:17:36 +0100 |
commit | b802ca47e9ec854bc7cd11311ccce0ffdbf5165e (patch) | |
tree | 6d2ebd6daccb5365f63b531623291b3f6b4409f8 /TODO | |
parent | cdff7a49669956ab8b6bd82741199d8f50c5b35a (diff) | |
download | qpdf-b802ca47e9ec854bc7cd11311ccce0ffdbf5165e.tar.zst |
Comments about incremental update support
Also remove some trivial, non-functional code.
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 34 |
1 files changed, 34 insertions, 0 deletions
@@ -64,6 +64,40 @@ General ======= + * Provide support in QPDFWriter for writing incremental updates. + Provide support in qpdf for preserving incremental updates. The + goal should be that QDF mode should be fully functional for files + with incremental updates including fix_qdf. + + Note that there's nothing that says an indirect object in one + update can't refer to an object that doesn't appear until a later + update. This means that QPDF has to treat indirect null objects + differently from how it does now. QPDF drops indirect null objects + that appear as members of arrays or dictionaries. For arrays, it's + handled in QPDFWriter where we make indirect nulls direct. This is + in a single if block, and nothing else in the code cares about it. + We could just remove that if block and not break anything except a + few test cases that exercise the current behavior. For + dictionaries, it's more complicated. In this case, + QPDF_Dictionary::getKeys() ignores all keys with null values, and + hasKey() returns false for keys that have null values. We would + probably want to make QPDF_Dictionary able to handle the special + case of keys that are indirect nulls and basically never have it + drop any keys that are indirect objects. + + If we make a change to have qpdf preserve indirect references to + null objects, we have to note this in ChangeLog and in the release + notes since this will change output files. We did this before when + we stopped flattening scalar references, so this is probably not a + big deal. We also have to make sure that the testing for this + handles non-trivial cases of the targets of indirect nulls being + replaced by real objects in an update. I'm not sure how this plays + with linearization, if at all. For cases where incremental updates + are not being preserved as incremental updates and where the data + is being folded in (as is always the case with qpdf now), none of + this should make any difference in the actual semantics of the + files. + * 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 |