Age | Commit message (Collapse) | Author |
|
Loosen a check for earlier version of PDF files. When the bytes with
specified length are followed by 'endstream' keyword, even if there is
no EOL marker before the keyword, it signals the end of stream.
BUG=551258
R=jun_fang@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1499433002 .
|
|
PDF specs say that end of line markers shall follow the
keyword "stream". But a white space before end of line
markers follows this keyword in the test pdf files.
BUG=543018
R=thestig@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1401923005 .
|
|
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 .
|
|
The font is slightly different from Linux/Windows.
BUG=524043
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1366363002 .
|
|
files""
This reverts commit fa9756f77ad6145940d3dc697814b84f5755ae17.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1307353005/
|
|
This reverts commit 9bd18183ba8210c91d71c3060146235750a4c71c.
|
|
Pdfium swallows 'fi' or 'ff' in some tested files because it doesn't load the embedded font file correctly. The root cause is that there is incorrect keyword like 'ngendstream' in the stream of the embedded font file. Pdfium tries to find another correct keyword but uses wrong offset rather than accumulated offset.
BUG=524043
R=thestig@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1307353005 .
|
|
Credit to karl at skomski.com for the initial version of the CL.
BUG=527174
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1305033006 .
|
|
They were lost in commit d53e6fd.
BUG=pdfium:168
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1196523002 .
|
|
This reverts commit 5bd88ec07e79215400777f3095c6843e0627cade.
|
|
There is no assurance that the expected result files are consistent
with other readers. Jun will have to verify that after making his
parser changes for bug 493126.
BUG=493126
R=thestig@chromium.org, jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1232803005 .
|
|
This reverts commit de00893874a9d5ecae497e00511e2395fc2f02e8.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1017793003
|
|
This will be immediately reverted, but I need to be sure that the
previous change actually detects failures.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1008873005
|
|
Required to save space vs. raw bitmap. Land prior to adding
substantial number of tests.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/953723004
|
|
On origin/master, we only have .ppm format support, so the
expected output files would take up a lot of space. Hence,
this may not get going until XFA hits with its .png
support.
Nor is there a good way to diff these; XFA provides this
for .png as well.
But this will provide at least one automated test to ensure
that we've got non-blank output, at least for one trivially
simple case.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/926173002
|