OpenSystemsDevelopment / qpdf

Commit ed8166b21ea8c33328457912aad4f3e181bf255a

Authored by Jay Berkenbilt
1 parent 2001cbc8

TODO/README-maintainer cleanup

Inline Side-by-side
Showing 2 changed files with 2 additions and 29 deletions
README-maintainer
  View file @ed8166b
... ... @@ -83,7 +83,7 @@ RELEASE PREPARATION
83 83 * Check for open fuzz crashes at https://oss-fuzz.com
84 84  
85 85 * Check all open issues and pull requests in github and the
86   - sourceforge trackers.
  86 + sourceforge trackers. See ~/scripts/github-issues.
87 87  
88 88 * Check `TODO` file to make sure all planned items for the release are
89 89 done or retargeted.
... ...
... ... @@ -86,21 +86,11 @@ directory or that are otherwise not publicly accessible. This includes
86 86 things sent to me by email that are specifically not public. Even so,
87 87 I find it useful to make reference to them in this list
88 88  
89   - * See if there is a way to provide an option to use higher
90   - compression with zlib. See #113. This can be done by adding options
91   - to Pl_Flate and having QPDFWriter optionally use those options.
92   - Also increasing the buffer size may help.
93   -
94 89 * Add support for writing name and number trees
95 90  
96 91 * Figure out how to render Gajić correctly in the PDF version of the
97 92 qpdf manual.
98 93  
99   - * Decide whether errors thrown by checkLinearization should be
100   - converted to warnings. Take a pass through the linearization code
101   - to see whether it's correct. Be able to view linearization data
102   - even when there are errors. See linearization label in github.
103   -
104 94 * Consider creating a PPA for Ubuntu
105 95  
106 96 * Investigate whether there is a way to automate the memory checker
... ... @@ -242,21 +232,6 @@ I find it useful to make reference to them in this list
242 232 spec, and look at ~/Q/pdf-collection/form-with-full-save.pdf, which
243 233 came from Adobe's example site.
244 234  
245   - * Consider the possibility of doing something locale-aware to support
246   - non-ASCII passwords. Update documentation if this is done. Consider
247   - implementing full Unicode password algorithms from newer encryption
248   - formats. See ../misc/unicode-password*. If code is added to
249   - properly encode Unicode passwords, figure out how to deal with
250   - backward compatibility. Either require some additional flag to
251   - decode the password or provide a `--raw-password` flag to suppress
252   - decoding. While automatically encoding breaks backward
253   - compatibility, it's probably the right behavior because the current
254   - behavior is arguably a bug. Alternatively, if the password doesn't
255   - work as a raw password and contains characters outside US-ASCII,
256   - try various encoding methods to see if any work. See section
257   - 7.6.3.3, algorithms 2 and 2A, in the ISO spec for details. (This is
258   - tracked in https://github.com/qpdf/qpdf/issues/215.)
259   -
260 235 * See if we can avoid preserving unreferenced objects in object
261 236 streams even when preserving the object streams.
262 237  
... ... @@ -319,9 +294,7 @@ I find it useful to make reference to them in this list
319 294 embedded prior to appended sections.
320 295  
321 296 * From a suggestion in bug 3152169, consider having an option to
322   - re-encode inline images with an ASCII encoding. This is also
323   - https://github.com/qpdf/qpdf/issues/278. It would be interesting to
324   - make optimize-images work with inline images.
  297 + re-encode inline images with an ASCII encoding.
325 298  
326 299 * From github issue 2, provide more in-depth output for examining
327 300 hint stream contents. Consider adding on option to provide a
... ...