summaryrefslogtreecommitdiff
path: root/testing/resources/pixel
diff options
context:
space:
mode:
authorJun Fang <jun_fang@foxitsoftware.com>2015-09-29 10:24:54 +0800
committerJun Fang <jun_fang@foxitsoftware.com>2015-09-29 10:40:24 +0800
commit3d494aff5ee1d0d313ccdce0aaf4ae44078bcd52 (patch)
tree7517d97a778a489d947ea25ef6d75b5ca66ed4c3 /testing/resources/pixel
parent1e87d8a58b638bb3fd5f9683f06b74e13e9533a2 (diff)
downloadpdfium-3d494aff5ee1d0d313ccdce0aaf4ae44078bcd52.tar.xz
Merge to XFA: 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 Review URL: https://codereview.chromium.org/1328213002 .
Diffstat (limited to 'testing/resources/pixel')
-rw-r--r--testing/resources/pixel/bug_512557.inbin0 -> 1329 bytes
-rw-r--r--testing/resources/pixel/bug_512557_expected.pdf.0.pngbin0 -> 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
new file mode 100644
index 0000000000..5f353341d5
--- /dev/null
+++ b/testing/resources/pixel/bug_512557.in
Binary files differ
diff --git a/testing/resources/pixel/bug_512557_expected.pdf.0.png b/testing/resources/pixel/bug_512557_expected.pdf.0.png
new file mode 100644
index 0000000000..66c73aebea
--- /dev/null
+++ b/testing/resources/pixel/bug_512557_expected.pdf.0.png
Binary files differ