aboutsummaryrefslogtreecommitdiffstats
path: root/TODO
diff options
context:
space:
mode:
authorJay Berkenbilt <ejb@ql.org>2012-12-27 17:39:01 +0100
committerJay Berkenbilt <ejb@ql.org>2012-12-31 11:36:48 +0100
commit04c203ae060458ae39253263c7dd1c603b931bf0 (patch)
tree2ef17e10a0e62146ae9a8b57d1c6e86fe452bf5d /TODO
parentb4b8b28ed237f127c6b8c31fbb244efacc70e0a8 (diff)
downloadqpdf-04c203ae060458ae39253263c7dd1c603b931bf0.tar.zst
Eliminate flattenScalarReferences
Diffstat (limited to 'TODO')
-rw-r--r--TODO32
1 files changed, 0 insertions, 32 deletions
diff --git a/TODO b/TODO
index c8e0ceca..c744b103 100644
--- a/TODO
+++ b/TODO
@@ -41,38 +41,6 @@ General
outlines, page labels, thumbnails, zones. There are probably
others.
- * See whether it's possible to remove the call to
- flattenScalarReferences. I can't easily figure out why I do it,
- but removing it causes strange test failures in linearization. I
- would have to study the optimization and linearization code to
- figure out why I added this to begin with and what in the code
- assumes it's the case. For enqueueObject and unparseChild in
- QPDFWriter, simply removing the checks for indirect scalars seems
- sufficient. Looking back at the branch in the apex epub
- repository, before flattening scalar references, there was special
- case code in QPDFWriter to avoid writing out indirect nulls. It's
- still not obvious to me why I did it though.
-
- To pursue this, remove the call to flattenScalarReferences in
- QPDFWriter.cc and disable the logic_error exceptions for indirect
- scalars. Just search for flattenScalarReferences in QPDFWriter.cc
- since the logic errors have comments that mention
- flattenScalarReferences. Then run the test suite. Several files
- that explicitly test flattening of scalar references fail, but the
- indirect scalars are properly preserved and written. But then
- there are some linearized files that have a bunch of unreferenced
- objects that contain scalars. Need to figure out what these are
- and why they're there. Maybe they're objects that used to be
- stream lengths. Probably we just need to make sure don't traverse
- through a stream's /Length stream when enqueueing stream
- dictionaries. This could potentially happen with any object that
- QPDFWriter replaces when writing out files. Such objects would be
- orphaned in the newly written file. This could be fixed, but it
- may not be worth fixing.
-
- If flattenScalarReferences is removed, a new method will be needed
- for checking PDF files.
-
* See if we can avoid preserving unreferenced objects in object
streams even when preserving the object streams.