OpenSystemsDevelopment / qpdf

Commit 16fe38b8e3b69e53a4c56b9de4fdae1daa0e0d50

Authored by m-holger
1 parent 9ce18e41

Update TODO.md with pages tree / fuzz discussions 

Also, remove closed fuzz cases.
Inline Side-by-side
Showing 1 changed file with 5 additions and 2 deletions
... ... @@ -201,8 +201,7 @@ Fuzz Errors
201 201  
202 202 * https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=<N>
203 203  
204   -* Ignoring these:
205   - * Out of memory in dct: 35001, 32516
  204 +* See also [discussion](https://github.com/qpdf/qpdf-dev/discussions/6).
206 205  
207 206 External Libraries
208 207 ==================
... ... @@ -396,6 +395,8 @@ so, I find it useful to make reference to them in this list.
396 395 API. Move as many of the test drivers from the qpdf directory into the latter category as long as
397 396 doing so isn't too troublesome from a coverage standpoint.
398 397  
  398 +* Refactor pages tree. See [discussion](https://github.com/qpdf/qpdf-dev/discussions/10).
  399 +
399 400 * Consider generating a non-flat pages tree before creating output to better handle files with lots
400 401 of pages. If there are more than 256 pages, add a second layer with the second layer nodes having
401 402 no more than 256 nodes and being as evenly sizes as possible. Don't worry about the case of more
... ... @@ -584,6 +585,8 @@ time but subsequent implementations of std::shared_ptr became much more efficien
584 585 QPDFPagesTree
585 586 =============
586 587  
  588 +See also [discussion](https://github.com/qpdf/qpdf-dev/discussions/10).
  589 +
587 590 On a few occasions, I have considered implementing a QPDFPagesTree object that would allow the
588 591 document's original page tree structure to be preserved. See comments at the top QPDF_pages.cc for
589 592 why this was abandoned.
... ...