From a800b4eaa125f424fb6fc6868a64a020a22aa7fb Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Sat, 27 Mar 2010 15:53:44 +0000 Subject: [PATCH] updated ChangeLog git-svn-id: svn+q:///qpdf/trunk@947 71b93d88-0707-0410-a8cf-f5a4172ac649 --- ChangeLog | 15 +++++++++++++++ TODO | 26 ++++++++++++++++++++++++++ 2 files changed, 41 insertions(+) diff --git a/ChangeLog b/ChangeLog index 2f4cdfac..02711bf5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,18 @@ +2010-03-27 Jay Berkenbilt + + * libqpdf/QPDF_optimization.cc (flattenScalarReferences): Flatten + scalar references for unreferenced objects as well as those seen + during traversal of the file. This matters when preserving object + streams that contain unreferenced objects with indirect scalars. + (Fixes qpdf-Bugs-2974522.) Updated TODO with a description of a + possibly better fix involving removal of flattenScalarReferences. + + * libqpdf/Pl_AES_PDF.cc (finish): Don't complain if an AES input + buffer is not a multiple of 16 bytes. Instead, just pad with + nulls and hope for the best. PDF files have been encountered "in + the wild" that contain AES buffers that aren't a multiple of 16 + bytes. + 2010-01-24 Jay Berkenbilt * 2.1.2: release diff --git a/TODO b/TODO index d27ba473..58e8e3de 100644 --- a/TODO +++ b/TODO @@ -15,6 +15,32 @@ General ======= + * 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. + + 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. + + If flattenScalarReferences is removed, a new method will be needed + for checking PDF files. + * For debugging linearization bugs, consider adding an option to save pass 1 of linearization. This code is sufficient. Change the interface to allow specification of a pass1 file, which would