octoleo
/
qpdf
mirror of https://github.com/qpdf/qpdf.git
2
1
Fork 0
Code Issues Releases Wiki Activity

updated ChangeLog 

git-svn-id: svn+q:///qpdf/trunk@947 71b93d88-0707-0410-a8cf-f5a4172ac649
This commit is contained in:
Jay Berkenbilt 2010-03-27 15:53:44 +00:00
parent 218900d2c3
commit a800b4eaa1
2 changed files with 41 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
ChangeLog
View File

@ -1,3 +1,18 @@
2010-03-27 Jay Berkenbilt <ejb@ql.org>
* 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 <ejb@ql.org>
* 2.1.2: release

26
TODO
View File

@ -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