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:40:24 +0800 |
| commit | 3d494aff5ee1d0d313ccdce0aaf4ae44078bcd52 (patch) | |
| tree | 7517d97a778a489d947ea25ef6d75b5ca66ed4c3 /core/src/fpdfapi | |
| parent | 1e87d8a58b638bb3fd5f9683f06b74e13e9533a2 (diff) | |
| download | pdfium-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 'core/src/fpdfapi')
| -rw-r--r-- | core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp | 7 |
1 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) { |