Age | Commit message (Collapse) | Author |
|
Also clean up while we're here.
BUG=557223
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1512833008 .
|
|
BUG=pdfium:298
R=weili@chromium.org
Review URL: https://codereview.chromium.org/1496703005 .
|
|
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 .
|
|
RebuildCrossRef function returns false when we can not find file trailer
or any indirect object. This serves as a basic file format checking.
BUG=pdfium:215
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1476163002 .
|
|
- add DrMemoryWrapper in common.py to adjust Dr. Memory wrapper
- add --wrapper option to run_*_tests.py for Dr. Mempry wrapper
- update run_*_tests.py to handle Dr. Memory wrapper
- add TestPDFiumTest in pdfium_tests.py to support run_*_tests.py
- remove ValgrindTool in valgrind_tests.py
R=thestig@chromium.org
BUG=pdfium:238
Review URL: https://codereview.chromium.org/1464453003 .
|
|
This matches the type of the corresponding |CFX_DIBSource::m_Pitch|,
where integer overflow is checked for FX_DWORD. This change is
propagated to many other places.
Also, check for integer overflow in |CCodec_RLScanlineDecoder::Create|
during the calculation of |m_Pitch| since it aligns to 4 bytes while
overflow was was previously checked without this alignment.
R=tsepez@chromium.org, thestig@chromium.org
BUG=555784
Review URL: https://codereview.chromium.org/1460033002 .
|
|
BUG=none
R=thestig@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1462313002 .
|
|
During decoding, when an image decoder is encountered, any
subsequent decoders are ignored, but remain in the array. However,
later on CPDF_DIBSource::ValidateDictParam expects the image
decoder to be the last in the array, causing issues.
A check is also added in CPDF_DIBSource::GetScanline to ensure
that the calculated pitch value is <= the (4-aligned) pitch value in the
cached bitmap to prevent future issues.
Also cleans up some NULL usages.
BUG=552046
R=jun_fang@foxitsoftware.com, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1406943005 .
|
|
CPDF_DIBSource::DownSampleScanline32Bit
Previously, if |m_bpc| was < 8 (e.g. 4), this function may still try to
access the source components as if |m_bpc| == 8. Even when it fell into
the codepath that tried to do the right thing in this case, it was
wrong.
BUG=554151
R=tsepez@chromium.org, thestig@chromium.org
Committed: https://pdfium.googlesource.com/pdfium/+/9b99615806e358fdb396d1cb162ee2e69c2a20ec
Review URL: https://codereview.chromium.org/1433423002 .
|
|
CPDF_DIBSource::DownSampleScanline32Bit"
This reverts commit 9b99615806e358fdb396d1cb162ee2e69c2a20ec.
Broke Windows build.
TBR=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1437963003 .
|
|
Previously, if |m_bpc| was < 8 (e.g. 4), this function may still try to
access the source components as if |m_bpc| == 8. Even when it fell into
the codepath that tried to do the right thing in this case, it was
wrong.
BUG=554151
R=tsepez@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1433423002 .
|
|
run from any directory.
Previously the tests which read test files assume the current directory is under pdfium. Running from any other directory will break the build.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1408003014 .
|
|
Do some IWYU to fix build errors due to files that have no #includes but
just happened to work previously because the #includes were in the right
order.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1407423004 .
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1415803007 .
|
|
- In non-standalone builds, use the provided jpeg library.
- Run gn format over all the GN files.
- Also roll DEPS for buildtools to c2f2598.
BUG=541704
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1425153006 .
|
|
This tests whether RebuildCrossRef could handle well-formatted pdf file.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1409013005 .
|
|
Do not store raw wide string pointers.
BUG=551248
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1411043008 .
|
|
This regressed in commit 794c9b6.
BUG=551248
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1424743006 .
|
|
Also cleans up some places in the relevant functions since we're here.
BUG=551460
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1421783004 .
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1419373005 .
|
|
This reverts commit a1215ba51a235fb7abcb995f0e768ea0176d9275.
Revert "Return result of the test runner."
This reverts commit d1579c9b92b7f9c1d9e0fac1ecb8e3cb23875fca.
Reverting the new test_runner code as there appears to be something string
happening on the non-Linux boxes on XFA.
It looks like it ran the font_size test twice, once with the .in and once with
the .pdf. The .in was suppressed, the .pdf faild and wasn't suppressed.
Rendering PDF file /Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/gen/pdfium/testing/pixel/font_size.pdf.
Rendered 1 pages.
Skipped 0 bad pages.
Checking /Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/gen/pdfium/testing/pixel/font_size.pdf.0.png
FAILURE: font_size.in; Command '['/Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/pdfium_diff', '/Volumes/data/b/build/slave/mac_xfa/build/pdfium/testing/resources/pixel/font_size_expected.pdf.0.png', '/Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/gen/pdfium/testing/pixel/font_size.pdf.0.png']' returned non-zero exit status 1
font_size.in is suppressed, found in SUPPRESSIONS_mac file
Rendering PDF file /Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/gen/pdfium/testing/pixel/font_size.pdf.
Rendered 1 pages.
Skipped 0 bad pages.
Checking /Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/gen/pdfium/testing/pixel/font_size.pdf.0.png
FAILURE: font_size.pdf; Command '['/Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/pdfium_diff', '/Volumes/data/b/build/slave/mac_xfa/build/pdfium/testing/resources/pixel/font_size_expected.pdf.0.png', '/Volumes/data/b/build/slave/mac_xfa/build/pdfium/out/Debug/gen/pdfium/testing/pixel/font_size.pdf.0.png']' returned non-zero exit status 1
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1410743008 .
|
|
We need to actually return the result of the test runner....
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1413863011 .
|
|
This CL takes the three test runners (corpus, javascript, pixel) and combines
the code into a single test_runner file. Each of the individual runners still
exists and calls the test runner with their data directory.
With this change, the pixel and javascript test will now run in parallel if
multiple processors are available.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1430623006 .
|
|
BUG=446715
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1353093003 .
|
|
This CL adds the ability to run a given test from the corpus, javascript and
pixel test runners. The filename to provide is relative to the testing
directory in question.
Because the directories for javascript and pixel are flat you just provide the filename (it will rewrite the .pdf to .in if .pdf is provided). For corpus tests you have to provide the path from the corpus directory.
Development/pdfium/pdfium % ./testing/tools/run_javascript_tests.py apply.pdf
Rendering PDF file /Development/pdfium/pdfium/out/Debug/gen/pdfium/testing/javascript/apply.pdf.
Non-linearized path...
Rendered 1 pages.
Skipped 0 bad pages.
Development/pdfium/pdfium % ./testing/tools/run_pixel_tests.py bug_524043_1.pdf
Rendering PDF file /Development/pdfium/pdfium/out/Debug/gen/pdfium/testing/pixel/bug_524043_1.pdf.
Linearized path...
Rendered 1 pages.
Skipped 0 bad pages.
Checking /Development/pdfium/pdfium/out/Debug/gen/pdfium/testing/pixel/bug_524043_1.pdf.0.png
diff: 0.00% passed
Development/pdfium/pdfium % ./testing/tools/run_corpus_tests.py third_party/tcpdf/example_065.pdf
Rendering PDF file /Development/pdfium/pdfium/out/Debug/gen/pdfium/testing/corpus/example_065.pdf.
Non-linearized path...
Rendered 1 pages.
Skipped 0 bad pages.
Checking /Development/pdfium/pdfium/out/Debug/gen/pdfium/testing/corpus/example_065.pdf.0.png
diff: 0.14% failed
FAILURE: example_065.pdf; Command '['/Development/pdfium/pdfium/out/Debug/pdfium_diff', '/Development/pdfium/pdfium/testing/corpus/third_party/tcpdf/example_065_expected.pdf.0.png', '/Development/pdfium/pdfium/out/Debug/gen/pdfium/testing/corpus/example_065.pdf.0.png']' returned non-zero exit status 1
Summary of Failures:
/Development/pdfium/pdfium/testing/corpus/third_party/tcpdf/example_065.pdf
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1407913005 .
|
|
When we call OpenDocument we fail to check if the document was actually opened.
Currently we return true in all cases (assuming we read the file). This CL
updates the code to check if the document was opened and return false if not.
I've updated several tests to check for FALSE instead of TRUE. I verified the
documents in fact don't open with my local (non-PDFium) PDF reader.
BUG=pdfium:223
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1417893007 .
|
|
The m_pShadingObj can be a stream or a dictionary depending on how it's used.
This CL adds some simple type checking to make sure that the type of the
object matches what we expect.
BUG=chromium:547706
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1421973004 .
|
|
There appear to be a bunch of corpus tests which fail with this change such
as FAILURE: shading1.pdf
This reverts commit 85361b227ad6786d2aeef8409b79a8d077a26ee9.
Make m_pShadingObj a CPDF_Stream instead of CPDF_Object.
This object is required to be a stream and was being converted as such. With
the new type checking this caused us to pass a nullptr where previously we'd
have, incorrectly, cast a CPDF_Dictionary to a CPDF_Stream.
This CL changes the m_pShadingObj to always be a CPDF_Stream. Then, we never
go down the bad code path because we check if m_pShadingObj is nullptr earlier
and bail out.
BUG=chromium:547706
TBR=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1414283003 .
|
|
This object is required to be a stream and was being converted as such. With
the new type checking this caused us to pass a nullptr where previously we'd
have, incorrectly, cast a CPDF_Dictionary to a CPDF_Stream.
This CL changes the m_pShadingObj to always be a CPDF_Stream. Then, we never
go down the bad code path because we check if m_pShadingObj is nullptr earlier
and bail out.
BUG=chromium:547706
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1426713002 .
|
|
This limit mirrors FX_MAX_PAGE_LEVEL in fpdf_parser_document.cpp
R=thestig@chromium.org, tsepez@chromium.org
BUG=544880
Review URL: https://codereview.chromium.org/1421743003 .
|
|
Thanks Stack Overflow!
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1421623002 .
|
|
Removes duplication between pdfium_test and pdfium_embeddertest
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1416713002 .
|
|
Adds the following new violations:
ERROR in core/include/fpdfapi/fpdf_parser.h
Illegal include: "public/fpdfview.h"
ERROR in core/include/fpdfapi/fpdf_render.h
Illegal include: "public/fpdf_progressive.h"
ERROR in core/src/fpdfapi/fpdf_parser/fpdf_parser_decode_embeddertest.cpp
Illegal include: "public/fpdfview.h"
BUG=pdfium:217
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1411493002 .
|
|
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 .
|
|
Null FPDF_BOOKMARK represents the "root" bookmark, and must
not segv when asking about titles or children.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1404723002 .
|
|
- Use the number of cores as the default -j value
- Fall back to old code for -j 1
R=nparker@chromium.org
Review URL: https://codereview.chromium.org/1398793003 .
|
|
Original patch from issue 1391843004 at patchset 1
(http://crrev.com/1391843004#ps1)
Introduce a pdf_enable_v8 GYP variable, which controls a
corresponding PDF_ENABLE_V8 #define, and bring in the real
JS library when set. Otherwise, link against a stub JS
runtime.
BUG=pdfium:211
R=dml@google.com, jochen@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1395733006 .
|
|
Start to back-fill some tests for the recent isolate work.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1377293004 .
|
|
Original patch by chamalsl.
Trailer size in bug_507316 was wrong.
embedder_test.cpp's GetPageTrampoline passed null parameter.
It will affect future test cases even if it does not affect
this.
BUG=507316
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1377403003 .
|
|
BUG=chromium:529012
R=jochen@chromium.org, krasin@google.com
Review URL: https://codereview.chromium.org/1353193004 .
|
|
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 .
|
|
Also changes DEPS to specify a specific v8 version, this will
require us to manually update this version from time to time,
but also solves a longstanding problem where going back to an
older version (say for bisecting) wouldn't always work.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1372963003 .
|
|
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 .
|
|
The API is the same as the Foxit version, except the encoding is
specified as UTF-8 instead of local encoding.
Also remove CPDF_LWinParam since it's unused.
BUG=chromium:517713
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1335373002 .
|
|
Replace multiple #defines of the same strings with externs.
Fix strings mangled by interaction of # and clang-format.
Remove macros as possible.
Make more JS_ functions void and simplify.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1342433002 .
|
|
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 .
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1314443007 .
|