diff options
author | Jay Berkenbilt <ejb@ql.org> | 2020-10-23 22:28:05 +0200 |
---|---|---|
committer | Jay Berkenbilt <ejb@ql.org> | 2020-10-23 22:53:58 +0200 |
commit | fd13fe74ef9ec7ae4a02ac59e2cd0414958adfb1 (patch) | |
tree | f33a3e7c3510bcca82ddc2141efa7ec59e59af21 /TODO | |
parent | f8e4b6161cce4d851222dababb2c8c96e4b1c864 (diff) | |
download | qpdf-fd13fe74ef9ec7ae4a02ac59e2cd0414958adfb1.tar.zst |
TODO and comments item for pipeContentStreams
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 17 |
1 files changed, 17 insertions, 0 deletions
@@ -10,6 +10,23 @@ Candidates for upcoming release * See if we can work in Windows Build/External Libraries (below) +* QPDFObjectHandle::pipeContentStreams calls finish() after each + stream. In some code paths, Pl_Concatenate is used, which suppresses + that, but in other code paths, it's not used, and the library relies + on the behavior of finish() being called. Then there's the issue of + nested Pl_Concatenate pipelines -- calling manualFinish() on the top + one doesn't call manualFinish() on the lower ones, and there are no + exposed methods that allow us to apply things down the pipeline + stack, so it's hard to fix this without changing the API (at least + making Pipeline::getNext() public, which may be undesirable). To see + this problem in action, stick a Pl_Concatenate in front of the + pipeline in pipeContentStreams and observe the test failure. One + solution might be to add an additional argument indicating whether + or not to delay calling finish() until the end. See comments on + QPDFPageObjectHelper::filterPageContents, + QPDFObjectHandle::filterPageContents, and + QPDFObjectHandle::pipeContentStreams + * Remember to check work `qpdf` project for private issues * file with very slow page extraction * big page even with --remove-unreferenced-resources=yes, even with --empty |