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 .

3 files changed, 5 insertions, 2 deletions

diff --git a/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp b/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp
index 0362ff2e90..9497943fbd 100644
--- a/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp
+++ b/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp
@@ -957,8 +957,11 @@ void CPDF_DIBSource::ValidateDictParam() {
         m_bpc = 1;
         m_nComponents = 1;
       }
-      if (filter == FX_BSTRC("RunLengthDecode") ||
-          filter == FX_BSTRC("DCTDecode")) {
+      if (filter == FX_BSTRC("RunLengthDecode")) {
+        if (m_bpc != 1) {
+          m_bpc = 8;
+        }
+      } else if (filter == FX_BSTRC("DCTDecode")) {
         m_bpc = 8;
       }
     } else if (pFilter->GetType() == PDFOBJ_ARRAY) {
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
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