Fallback to an exhaustive search, in corrupt PDF files, for NameTrees/NumberTrees that are not correctly ordered (issue 10272) #10274
Conversation
Snuffleupagus
force-pushed
the
out-of-order-trees
branch
from
e684e12 to
3b042cc
Compare
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/38bbe2a12c7fe80/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/17bb13e9c46086e/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/17bb13e9c46086e/output.txt Total script time: 3.88 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/38bbe2a12c7fe80/output.txt Total script time: 5.63 mins
|
…/NumberTrees that are not correctly ordered (issue 10272) According to the specification, see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G6.2384179, the keys of NameTree/NumberTree should be ordered. For corrupt PDF files, which violate this assumption, we thus need to fallback to an exhaustive search in order to e.g. find all destinations. *Please note:* Given that this only implements a fallback for the "final" node of the Tree, there's obviously a risk that the patch isn't sufficient for dealing with all kinds of out-of-order corruption. However, this kind of problem should be rare in practice, and without a real-world test-case it's difficult to implement a completely general solution (and there's obviously a question if you'd even want to).
Snuffleupagus
force-pushed
the
out-of-order-trees
branch
from
3b042cc to
fdad0a0
Compare
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/8182bb2c5952c18/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/be8b58ded7f79b3/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/8182bb2c5952c18/output.txt Total script time: 3.92 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/be8b58ded7f79b3/output.txt Total script time: 5.56 mins
|
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/d2ae176f6ca104f/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.215.176.217:8877/cfcc0641223ae44/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/d2ae176f6ca104f/output.txt Total script time: 19.19 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/cfcc0641223ae44/output.txt Total script time: 24.69 mins
|
|
Thank you! |
According to the specification, see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G6.2384179, the keys of NameTree/NumberTree should be ordered.
For corrupt PDF files, which violate this assumption, we thus need to fallback to an exhaustive search in order to e.g. find all destinations.
Please note: Given that this only implements a fallback for the "final" node of the Tree, there's obviously a risk that the patch isn't sufficient for dealing with all kinds of out-of-order corruption. However, this kind of problem should be rare in practice, and without a real-world test-case it's difficult to implement a completely general solution (and there's obviously a question if you'd even want to).
Fixes #10272.