Fix blank page issue caused by too strict correction on bpc

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

Committed: https://pdfium.googlesource.com/pdfium/+/3500e90e9e42fa84dd6f07da16cfcf197ec98283

[jun_fang, 2015-09-08 10:17:09]

jun_fang@foxitsoftware.com changed reviewers:
+ thestig@chromium.org, tsepez@chromium.org

[jun_fang, 2015-09-08 10:18:20]

On 2015/09/08 10:17:09, jun_fang wrote:
> mailto:jun_fang@foxitsoftware.com changed reviewers:
> + mailto:thestig@chromium.org, mailto:tsepez@chromium.org

Hi Tom and Lei,

Please start to review this CL. Thanks!

[Tom Sepez, 2015-09-08 15:47:19]

https://codereview.chromium.org/1328213002/diff/1/core/src/fpdfapi/fpdf_rende...
File core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp (right):

https://codereview.chromium.org/1328213002/diff/1/core/src/fpdfapi/fpdf_rende...
core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:960: if (filter ==
FX_BSTRC("RunLengthDecode") && m_bpc != 1) {
nit: I might write
   if (filter == FX_BSTRC("RunLengthDecode")) {
      if (m_bpc != 1) {
         m_bpc = 8;
      }
   } else if (filter == FX_BSTRC("DCTDecode) { ...

to avoid a second string comparison when when know the first one matched.

[Tom Sepez, 2015-09-08 15:48:29]

Test case?

[jun_fang, 2015-09-09 09:57:12]

https://codereview.chromium.org/1328213002/diff/1/core/src/fpdfapi/fpdf_rende...
File core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp (right):

https://codereview.chromium.org/1328213002/diff/1/core/src/fpdfapi/fpdf_rende...
core/src/fpdfapi/fpdf_render/fpdf_render_loadimage.cpp:960: if (filter ==
FX_BSTRC("RunLengthDecode") && m_bpc != 1) {
On 2015/09/08 15:47:19, Tom Sepez wrote:
> nit: I might write
>    if (filter == FX_BSTRC("RunLengthDecode")) {
>       if (m_bpc != 1) {
>          m_bpc = 8;
>       }
>    } else if (filter == FX_BSTRC("DCTDecode) { ...
> 
> to avoid a second string comparison when when know the first one matched.

Acknowledged.

[jun_fang, 2015-09-09 10:06:20]

On 2015/09/08 15:48:29, Tom Sepez wrote:
> Test case?

Hi Tom,

I suggest to add a corpus test case to cover this issue.
My idea is to add a folder named "regression" in testing/corpus/.
When we fix a wrong pixel output issue, we add a corpus test
in this folder to avoid the same issue happen in future. Please
let me know what your idea is. Do we need to add a sub-folder with
the name of issue number in the folder of regression?

[Tom Sepez, 2015-09-09 17:36:51]

On 2015/09/09 10:06:20, jun_fang wrote:
> On 2015/09/08 15:48:29, Tom Sepez wrote:
> > Test case?
> 
> Hi Tom,
> 
> I suggest to add a corpus test case to cover this issue.
> My idea is to add a folder named "regression" in testing/corpus/.
> When we fix a wrong pixel output issue, we add a corpus test
> in this folder to avoid the same issue happen in future. Please
> let me know what your idea is. Do we need to add a sub-folder with
> the name of issue number in the folder of regression?

Just because someone has filed an example .pdf with us doesn't mean that 
we can add it to the corpus.  Instead, if we distill the key parts of the
example into our own (typically hand-written) minimal reproducible example,
then we are free to add this as testing/resources/pixel/bug_999999.pdf.

[jun_fang, 2015-09-28 08:14:44]

On 2015/09/09 17:36:51, Tom Sepez wrote:
> On 2015/09/09 10:06:20, jun_fang wrote:
> > On 2015/09/08 15:48:29, Tom Sepez wrote:
> > > Test case?
> > 
> > Hi Tom,
> > 
> > I suggest to add a corpus test case to cover this issue.
> > My idea is to add a folder named "regression" in testing/corpus/.
> > When we fix a wrong pixel output issue, we add a corpus test
> > in this folder to avoid the same issue happen in future. Please
> > let me know what your idea is. Do we need to add a sub-folder with
> > the name of issue number in the folder of regression?
> 
> Just because someone has filed an example .pdf with us doesn't mean that 
> we can add it to the corpus.  Instead, if we distill the key parts of the
> example into our own (typically hand-written) minimal reproducible example,
> then we are free to add this as testing/resources/pixel/bug_999999.pdf.

Hi Tom,

I created a stream with the filter 'RunLengthDecode' manually and added it in
the test file. Using this file,
I can reproduce 512557.

[Tom Sepez, 2015-09-28 16:01:07]

lgtm

[jun_fang, 2015-09-29 02:25:24]

Committed patchset #4 (id:60001) manually as
3500e90e9e42fa84dd6f07da16cfcf197ec98283 (presubmit successful).

[Lei Zhang, 2015-09-29 02:50:09]

BTW, this was merged to XFA without a code review as
3d494aff5ee1d0d313ccdce0aaf4ae44078bcd52