Commit 78c49824eb7ad969be59291d4d7e44314078e828
1 parent
d4d7630c
TODO updates
Showing
1 changed file
with
30 additions
and
15 deletions
TODO
| 1 | Candidates for upcoming release | 1 | Candidates for upcoming release |
| 2 | =============================== | 2 | =============================== |
| 3 | 3 | ||
| 4 | +* Enable discussions in github. See if any open issues should be there. | ||
| 5 | + | ||
| 4 | * Open "next" issues | 6 | * Open "next" issues |
| 5 | * bugs | 7 | * bugs |
| 6 | * #473: zsh completion with directories | 8 | * #473: zsh completion with directories |
| 9 | + * Investigate how serverless does completion | ||
| 7 | * Non-bugs | 10 | * Non-bugs |
| 8 | * #436: parsing of document with form xobject | 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 | * QPDFObjectHandle::pipeContentStreams calls finish() after each | 20 | * QPDFObjectHandle::pipeContentStreams calls finish() after each |
| 11 | stream. In some code paths, Pl_Concatenate is used, which suppresses | 21 | stream. In some code paths, Pl_Concatenate is used, which suppresses |
| @@ -45,20 +55,6 @@ Candidates for upcoming release | @@ -45,20 +55,6 @@ Candidates for upcoming release | ||
| 45 | images and page splitting as those operations become more | 55 | images and page splitting as those operations become more |
| 46 | elaborate, particularly with handling of form XObjects. | 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 | * See if the tokenizer is a performance bottleneck and, if so, | 58 | * See if the tokenizer is a performance bottleneck and, if so, |
| 63 | optimize it. We might end up with a high-performance tokenizer that | 59 | optimize it. We might end up with a high-performance tokenizer that |
| 64 | has a different interface but still ultimately creates the same | 60 | has a different interface but still ultimately creates the same |
| @@ -301,7 +297,26 @@ General | @@ -301,7 +297,26 @@ General | ||
| 301 | NOTE: Some items in this list refer to files in my personal home | 297 | NOTE: Some items in this list refer to files in my personal home |
| 302 | directory or that are otherwise not publicly accessible. This includes | 298 | directory or that are otherwise not publicly accessible. This includes |
| 303 | things sent to me by email that are specifically not public. Even so, | 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 | * Add support for writing name and number trees | 321 | * Add support for writing name and number trees |
| 307 | 322 |