Age | Commit message (Collapse) | Author |
|
See http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gn_rel/builds/5674
Testing this is a two-step process: land CL to pdfium, then try DEPS roll
in chromium against this version on the win8 trybots.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1004733006
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1023383003
|
|
Next attempt to get GN build to work. Once this lands, doing a DEPS
roll against the win8_chromium_gn_dbg trybot seems to catch the issue.
Restore image_diff_png.cc to its previous state.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1024243003
|
|
Build broken on trybot at
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel/builds/66012/steps/compile%20%28with%20patch%29/logs/stdio
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1026843002
|
|
Failures from last roll need diagnosis.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1023913002
|
|
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1020093002
|
|
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1021003002
|
|
There are two reasons for doing this. The first is that adding files
to this repository doesn't trigger a rebuild on the bot, so the next
unrelated pdfium change will be the one to hit any issues with the
unversioned corpus.
The second is that we may need a specific version of the expected output
files (.pngs) to go with a specific pdfium build.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1019783003
|
|
Follow on to https://codereview.chromium.org/990683002/.
This more closely mimics what fseek() actually does, so as
to avoid subtle bugs down the road.
Move the DecodeData struct into a header so the test can
use it, and provide a constructor for it.
Along the way, I added include guards, removed the p_
prefix from some non-pointer vars, fixed some IWYU, and
resolved some signed/unsigned comparison warnings with
careful casting.
BUG=452671
R=jun_fang@foxitsoftware.com, thestig@chromium.org
Review URL: https://codereview.chromium.org/1016203002
|
|
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
|
|
Consequently, some of the tests may diff but the waterfall remains green.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1014083003
|
|
space is used"
This reverts commit 5a0e504d53195892458d819e52c62bea0c710bd5.
Original review URL https://codereview.chromium.org/1009513003
Reason for revert: New "corpus" tests show that this is no longer rendering some images. See, e.g. http://chromegw/i/client.pdfium/builders/linux/builds/144/steps/corpus%20tests/logs/stdio for those that diff'd.
TBR=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/1016823003
|
|
Add a run_corpus_tests.py script to run pdfium_test against
the corpus tree.
Note that this differs from the run_pixel_tests.py script,
since pre-processing is not required. I'll work on unifying
these in a subsequent CL.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1010833003
|
|
Speculative because we still don't have pdfium buildbots for mac/win
on the pdfium waterfall. Nonetheless, the two build errors reported
in https://codereview.chromium.org/989213003/ seem to be a default
statement in a switch fully covering all of an enum constant, and
the use of <cstdint> instead of <stdint.h> on mac.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1011803003
|
|
There are two issues in this bug.
One is that JP2 image is not displayed because it aborts loading Jpx bitmap when the number of components in color space is different with that one in JPX images. I found that the number of components in color space isn't updated after it's initialized. For index color space, the component shall inherit from its base color space.
The second issue is that displayed color is not correct after I fixed the first issue. The root cause is that sRGB is used in JPX image, it doesn't need to map from index to RGB again.
BUG=464215
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1009513003
|
|
In the process of opj_end_decompress, it will return fail when the end of coding stream is reached. However it returns true in the same scenario implemented in openJPEG. So the final solution is from openJPEG. Return true when the end of coding stream is reached.
BUG=452671
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/990683002
|
|
BUG=382661
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1007643002
|
|
This reverts commit 090d683489bfa3f36f1e2624c310ff9ca5836038.
Symbol appears in files that are not compiled anywhere, it would seem.
Reverting to remove these first.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1001023003
|
|
It's unused, and when the time comes, we'll want to put
pdfium onto a hardened allocator like partitionAlloc anyways.
Along the way, merge adjacent #ifdef __cplusplus blocks,
remove a pointless check for __cplusplus inside a .cpp file,
and remove a redundant cast.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1008483002
|
|
I thought I had done this already, apart from the third-party
libraries, but there were a couple remaining (the third-party
libraries will still call this, they should be tweaked
upstream as needed).
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/999543002
|
|
Speculative fix since the issue doesn't reproduce locally.
TBR=brettw@chromium.org
Review URL: https://codereview.chromium.org/988883002
|
|
Precursor to taking a second shot at cleaning up the FPDF_*
APIs. A FPDF_LINK is a CPDF_Dictionary, and a CPDF_Link
is a structure holding a FPDF_LINK. This goes against the
convention that FPDF_ types get cast to CPDF_* types, so we
want to make it clear where objects are getting constructed.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/985503005
|
|
It has a component with no object files in it. When compiled as a shared library, this fails.
This changes the target to a source set which can handle empty sources. It also changes the other static libraries in pdfium to source_sets (it should be very rare to need real static libraries).
Runs "gn format" over the BUILD files.
Renames the arg bundle_freetype to pdfium_bundle_freetype which makes more sense in the context of a larger build like Chrome.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/985543002
|
|
Precursor to taking a second shot at cleaning up the FPDF_*
APIs. A FPDF_Dest is a CPDF_Array, and a CPDF_Dest
is a structure holding a FPDF_Dest. This goes against the
convention that FPDF_ types get cast to CPDF_* types, so we
want to make it clear where objects are getting constructed,
etc.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/984703004
|
|
This is an attempt to fix git rebase-update, which complains
about uncommitted changes.
TBR=halyavin@chromium.org
Review URL: https://codereview.chromium.org/985833002
|
|
Precursor to taking a second shot at cleaning up the FPDF_*
APIs. A FPDF_Action is a CPDF_Dictionary, and a CPDF_Action
is a structure holding a FPDF_Action. This goes against the
convention that FPDF_ types get cast to CPDF_* types, so we
want to make it clear where objects are getting constructed,
etc.
Also tidy fpdf_actionhandler.cpp because it bugs me.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/984773002
|
|
Original Review URL: https://codereview.chromium.org/965423004
TBR=thestig@chromium.org
TBR=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/976033005
|
|
This provides no benefit, and reduces transparency.
Along the way:
Kill off some unused/commented-out code.
Return void where a bool return doesn't make sense.
Remove a pointless template type.
Remove now unused constants and types.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/971033002
|
|
This implements the previously unimplemented JS_Error() function.
Along the way:
- fix some IWYU when the include order in global.cpp was perturbed.
- remove some uses of JS_ErrorString, to increase transparency.
- use vp.IsSetting() in place of !vp.IsGetting() for clarity.
- specify an error string on several error return paths.
- add an error string for writing readonly properties.
- rename an error string constant to reflect the actual message.
- replace calls to variadic Format() with a function doing string appends.
- remove unused JS_GetClassName()
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/963193003
|
|
BUG=chromium:445408
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/952423002
|
|
Along the way, I noticed that one of these is used in a header file
that isn't included anywhere and describes no actual code (JS_Console.h).
Also add missing header guards, and IWYU to resources.h
Also move a static function from a header to the new resources.cpp file.
Also fix the grammar on some of the error messages. Most of these
appear to be JS error messages destined for a JS error handler or (someday)
a console (which can remain in english), and oddly, some appear to be about
failed form validation, which smells user-facing.
Also check that the message makes sense for the point the C++ code
wants to use it, and reword accordingly.
As it turns out, these currently don't make it back to JS due to the
unimplemented JS_Error() function; this is an enabling step towards
implementing it.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/955273003
|
|
For chromium checkouts, the top-level gmock is used instead.
Verify build with a simple test that ensures neither mock
method is fired.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/955513009
|
|
BUG=457493
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/960183004
|
|
This is the first step in allowing an embedder test to
someday gMock its callbacks, so that it can check that they
fired as expected. gMock wants a class, not a C-style
function-based API, and EmbedderTest is made to bridge
between the two.
The EmbedderTest class itself is modified to inherit from
the C JS API classes themselves, to make finding the
delegate easier.
For example, a future embedder test might send a keystroke
to a page, which would then trigger JS, which would then
trigger an Alert(). Mocking the Alert() callback would
allow the test to check that the alert happened as
expected.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/960663002
|
|
Re-work of original CL at:
https://codereview.chromium.org/933043002/
Much of the IFXJS interface appears completely unused, so
Kill off unused IFXJS interface methods. The code itself
appears incomplete against all of the objects present
in the paths that actually do register objects with JS.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/954923004
|
|
The build fails due to implicit double to integer conversion warning on width *= scale line
and warnings being treated as errors.
TEST= ninja
BUG= none
R=jam@chromium.org
Review URL: https://codereview.chromium.org/935663003
|
|
As we remove flate encoded sections from test cases (to
promote clarity), we should first have a simple unit test
for the underlying functionality.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/845313006
|
|
No functional changes, just tidying some stray characters,
plus kill trailing whitespace while we're at it.
TBR=thestig@chromium.org
BUG=https://code.google.com/p/pdfium/issues/detail?id=123
Review URL: https://codereview.chromium.org/953143002
|
|
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
|
|
Follow-on from https://codereview.chromium.org/950113002.
This would block a pdfium roll until corrected.
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/948233002
|
|
The pdfium library itself does not support the format, but the test utility
can convert to this output format.
GN build can't be tested standalone, so push this out to the next CL.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/950113002
|
|
Continuation of effort now that a test case is present on origin/master.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/945623002
|
|
R=jam@chromium.org
BUG=344767
Review URL: https://codereview.chromium.org/945723004
|
|
Exercises a separate code path that stores some JS objects
outside of JS. Needed before re-writing some other portions
of the JS_Defines.h code.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/943783002
|
|
This allows us to step through the JS bindings code with the
debugger, which I could not do (but wanted to) the other day.
In the process, get rid of some else after returns, and one
unreachable code path.
I also get rid of some tracing macros that we would never
use for the sake of clarity, and some plain unused
definitions.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/908033002
|
|
This is a purely mechanical change, no new functionality.
- Expand some macros which were merely a short-cut to save
typing but reduced transparency.
- Put GET_VALUE_TYPE() implementation into a .cpp file.
This is a portion of the patch from issue 908033002 at
patchset 40001 (http://crrev.com/908033002#ps40001)
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/927263003
|
|
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
|
|
The top-level directory name isn't part of the repository, and we
can't count on it always being "pdfium" (though many people will
choose to do it this way).
R=jam@chromium.org
Review URL: https://codereview.chromium.org/921043005
|
|
Along the way, I rename some functions in pdfium_test.cc to
match the style guide's FunctionName() syntax, adding
"Example" to make them obviously different from the PDF
internal code with similar name fragments.
The purpose is to at least have some coverage for the
setter/getter macros from JS_Define.h
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/928573002
|