summaryrefslogtreecommitdiff
path: root/fpdfsdk/src/javascript/JS_Runtime.cpp
diff options
context:
space:
mode:
authorLei Zhang <thestig@chromium.org>2015-09-29 12:26:30 -0700
committerLei Zhang <thestig@chromium.org>2015-09-29 12:26:30 -0700
commit0b8f2fee646c53b3e6eb1fbbf13211f286e8cb82 (patch)
tree5c8e9dc6eb0d16be81c5d7e82ad204233faffebb /fpdfsdk/src/javascript/JS_Runtime.cpp
parent472f1f75111f57c28eebd869af459f2662f32122 (diff)
downloadpdfium-0b8f2fee646c53b3e6eb1fbbf13211f286e8cb82.tar.xz
Merge to M46: Fix blank page issue caused by too strict correction on bpc
For bit per component (bpc), PDF spec mentions that a RunLengthDecode or DCTDecode filter shall always deliver 8-bit samples. However, some PDF files don't follow this rule. We can find that filter is RunLengthDecode but bpc is 1 in the provided test file. In this case, pdfium will correct bpc to 8 but the actual bpc is 1. It causes a failure because the data is much more than the expected. To handle this case, pdfium doesn't correct bpc to 8 when the original bpc is 1. BUG=512557 R=tsepez@chromium.org TBR=tsepez@chromium.org Review URL: https://codereview.chromium.org/1328213002 . (cherry picked from commit 3500e90e9e42fa84dd6f07da16cfcf197ec98283) Review URL: https://codereview.chromium.org/1377943002 .
Diffstat (limited to 'fpdfsdk/src/javascript/JS_Runtime.cpp')
0 files changed, 0 insertions, 0 deletions