diff options
| author | Jun Fang <jun_fang@foxitsoftware.com> | 2015-09-29 10:24:54 +0800 |
|---|---|---|
| committer | Jun Fang <jun_fang@foxitsoftware.com> | 2015-09-29 10:24:54 +0800 |
| commit | 3500e90e9e42fa84dd6f07da16cfcf197ec98283 (patch) | |
| tree | d319a6a35e2a92793169bd0d3fb86a2e2d283a7a /testing/resources/pixel | |
| parent | 39cd934a4705f69c30e1bbf13eab347f66999020 (diff) | |
| download | pdfium-3500e90e9e42fa84dd6f07da16cfcf197ec98283.tar.xz | |
Fix blank page issue caused by too strict correction on bpcchromium/2523
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
Review URL: https://codereview.chromium.org/1328213002 .
Diffstat (limited to 'testing/resources/pixel')
| -rw-r--r-- | testing/resources/pixel/bug_512557.in | bin | 0 -> 1329 bytes |
| -rw-r--r-- | testing/resources/pixel/bug_512557_expected.pdf.0.png | bin | 0 -> 185 bytes |
2 files changed, 0 insertions, 0 deletions
diff --git a/testing/resources/pixel/bug_512557.in b/testing/resources/pixel/bug_512557.in Binary files differnew file mode 100644 index 0000000000..5f353341d5 --- /dev/null +++ b/testing/resources/pixel/bug_512557.in diff --git a/testing/resources/pixel/bug_512557_expected.pdf.0.png b/testing/resources/pixel/bug_512557_expected.pdf.0.png Binary files differnew file mode 100644 index 0000000000..66c73aebea --- /dev/null +++ b/testing/resources/pixel/bug_512557_expected.pdf.0.png |
