Commit 78c49824eb7ad969be59291d4d7e44314078e828

Authored by Jay Berkenbilt
1 parent d4d7630c

TODO updates

Showing 1 changed file with 30 additions and 15 deletions
1 1 Candidates for upcoming release
2 2 ===============================
3 3  
  4 +* Enable discussions in github. See if any open issues should be there.
  5 +
4 6 * Open "next" issues
5 7 * bugs
6 8 * #473: zsh completion with directories
  9 + * Investigate how serverless does completion
7 10 * Non-bugs
8 11 * #436: parsing of document with form xobject
  12 + * #488: allow specification of jpeg compression quality; may also
  13 + need an option to recompress jpeg
  14 +
  15 +* Json mode enhancements:
  16 + * Put something in the json that makes it easier to find the
  17 + definition of an object without breaking compatibility
  18 + * See if the objects part can be sorted by object number
9 19  
10 20 * QPDFObjectHandle::pipeContentStreams calls finish() after each
11 21 stream. In some code paths, Pl_Concatenate is used, which suppresses
... ... @@ -45,20 +55,6 @@ Candidates for upcoming release
45 55 images and page splitting as those operations become more
46 56 elaborate, particularly with handling of form XObjects.
47 57  
48   -* Flattening of form XObjects seems like something that would be
49   - useful in the library. We are seeing more cases of completely valid
50   - PDF files with form XObjects that cause problems in other software.
51   - Flattening of form XObjects could be a useful way to work around
52   - those issues or to prepare files for additional processing, making
53   - it possible for users of the qpdf library to not be concerned about
54   - form XObjects. This could be done recursively; i.e., we could have a
55   - method to embed a form XObject into whatever contains it, whether
56   - that is a form XObject or a page. This would require more
57   - significant interpretation of the content stream. We would need a
58   - test file in which the placement of the form XObject has to be in
59   - the right place, e.g., the form XObject partially obscures earlier
60   - code and is partially obscured by later code.
61   -
62 58 * See if the tokenizer is a performance bottleneck and, if so,
63 59 optimize it. We might end up with a high-performance tokenizer that
64 60 has a different interface but still ultimately creates the same
... ... @@ -301,7 +297,26 @@ General
301 297 NOTE: Some items in this list refer to files in my personal home
302 298 directory or that are otherwise not publicly accessible. This includes
303 299 things sent to me by email that are specifically not public. Even so,
304   -I find it useful to make reference to them in this list
  300 +I find it useful to make reference to them in this list.
  301 +
  302 + * If I do more with json, take a look at this C++ header-only JSON
  303 + library: https://github.com/nlohmann/json/releases
  304 +
  305 + * Flattening of form XObjects seems like something that would be
  306 + useful in the library. We are seeing more cases of completely valid
  307 + PDF files with form XObjects that cause problems in other software.
  308 + Flattening of form XObjects could be a useful way to work around
  309 + those issues or to prepare files for additional processing, making
  310 + it possible for users of the qpdf library to not be concerned about
  311 + form XObjects. This could be done recursively; i.e., we could have a
  312 + method to embed a form XObject into whatever contains it, whether
  313 + that is a form XObject or a page. This would require more
  314 + significant interpretation of the content stream. We would need a
  315 + test file in which the placement of the form XObject has to be in
  316 + the right place, e.g., the form XObject partially obscures earlier
  317 + code and is partially obscured by later code. Keys in the resource
  318 + dictionary may need to be changed -- create test cases with lots of
  319 + duplicated/overlapping keys.
305 320  
306 321 * Add support for writing name and number trees
307 322  
... ...