summaryrefslogtreecommitdiff
path: root/core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp
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:24:54 +0800
commit3500e90e9e42fa84dd6f07da16cfcf197ec98283 (patch)
treed319a6a35e2a92793169bd0d3fb86a2e2d283a7a /core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp
parent39cd934a4705f69c30e1bbf13eab347f66999020 (diff)
downloadpdfium-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 'core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp')
-rw-r--r--core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp7
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) {