OpenSystemsDevelopment / qpdf

Commit b3ab5cd216fb6b210a17f19c9ad4cd1f0046362f

Authored by m-holger
Committed by GitHub
2 parents 9ce18e41 16fe38b8

Merge pull request #1248 from m-holger/hk 

Update TODO.md
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.
... ...