Age | Commit message (Collapse) | Author |
|
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
|
|
BUG=453723
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/892553002
|
|
This issue was introduced in https://codereview.chromium.org/886953002/.
BUG=454280
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/869343008
|
|
Top level script driver for testing/resources/javascript.
Converts each input template file in that directory to a
.pdf file in the working directory (typically
out/Debug/gen/pdfium/testing/resources/javascript), invokes
pdfium_test on it to generate , and crudely diffs the
expected output.
We can now remove generated .pdfs from source control,
keeping only the hand-editable .in templates.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/912803004
|
|
Follow-on from https://codereview.chromium.org/911293002/
Currently, all the subclass constructors are reaching up
into the parent class to do this. Fix this, just because.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/880233005
|
|
BUG=449845
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/911293002
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/908023003
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/885223004
|
|
BUG=pdfium:29
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/891113002
|
|
- Add functions to do pitch calculation.
- Delete dead code.
- Don't bother checking pointers before deleting them.
- Don't bother setting pointers to NULL in dtors.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/890883006
|
|
This is a plan for testing JS inside of pdf files under pdfium:
Communication of results will be done via app.alert(), rather than
console.println(), since the latter is not hooked up to any API
callbacks.
pdfium_test.cc is modified to be more careful about use of stdout/stderr,
so that only the app.alert() and the unsupported feature callback use
stdout. Diffing stdout against ..._expected.txt files gives the result.
I added a /javascript directory to separate these from the embeddertest
resources.
The alert callback is backported from XFA. This was an omission.
BUG=https://code.google.com/p/pdfium/issues/detail?id=62
R=jam@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/872103003
|
|
Clean in standalone pdfium, but this would block a pdfium
roll into chromium.
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/903903003
|
|
The bstring's read from file is unused.
The load from file paths aren't taken.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/902943003
|
|
Note that this work was done opposite the usual branch order, because I
didn't want to kill things in master that turned out to be in use in XFA.
Original Review URL: https://codereview.chromium.org/883393007
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/903893002
|
|
Handles the case of this malformed PDF without crashing. Note that to
get a reproducible test case, a small fix is applied to our .py script
which results in some whitespace/numbering difs across the resources
(down the road, we ought to generate them on the fly in an intermediate
directory).
BUG=454695
R=jun_fang@foxitsoftware.com, thestig@chromium.org
Review URL: https://codereview.chromium.org/895933003
|
|
Any projects DEPS'd into chromium and requiring a /base
subset should have a local copy of that subset in a
separate namespace. This will avoid future naming conflicts.
Re-arrange the directory structure to better identify what
came from chromium's base, and to make drop-in replacement
easier for files that contain hard-coded "base/" in their
#include directives.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/900753002
|
|
TBR=tsepez@chromium.org
BUG=455399
Review URL: https://codereview.chromium.org/902753002
|
|
This is similar to how we initialize ICU for V8 inside PDFium.
BUG=455399
R=wfh@chromium.org
Review URL: https://codereview.chromium.org/897973002
|
|
Headers in /include directories should be free of implementation details
from third_party. Put the types into a new header outside of /include.
Requires https://codereview.chromium.org/902443003/ before a version containing this patch is rolled into chromium.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/896023003
|
|
This is part of the project to kill off C-style casts in the code base.
Remove implict T* cast operator, and replace potentially unsafe C-style
casts with Get() method.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/889673003
|
|
BUG=https://code.google.com/p/pdfium/issues/detail?id=113
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/880043004
|
|
This is giving duplicate symbols for main when linking PDFium into Chromium.
BUG=453844
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/897463003
|
|
BUG=452455
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/887063003
|
|
The problem was FT_INTERNAL_DEBUG_H wasn't being defined because FT2_BUILD_LIBRARY wasn't set. So even if PDFium isn't using bundled FreeType, the FreeType target needs FT2_BUILD_LIBRARY defined. The GYP build was already correct.
BUG=453844
TBR=brettw
Review URL: https://codereview.chromium.org/891993003
|
|
The problem with trying to use the system headers sometimes is that we'll need to use pkg-config which is pretty slow.
BUG=453844
TBR=brettw
Review URL: https://codereview.chromium.org/865333003
|
|
This issue was caused by integer overflow in CPDF_SampledFunc::v_Call.
The root cause of this issue is that the content in the test pdf file
was damaged. The solution is to check whether an integer is overflow
before using it.
BUG=452455
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/886953002
|
|
It's only used internally. This also avoids errors from the verify_order script when linking PDFium into Chromium
BUG=453844
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/887193002
|
|
This saves 406KB in the binary size of the plugin. More importantly, it gets rid of the linker flag preventing bundling PDFium into the Chromium binary.
BUG=453844
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/826613004
|
|
This removes some duplicated code from each individual test.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/885403002
|
|
Introduce a local static to track the recursion depth, thereby removing
the burden for callers to track and pass a level parameter correctly through
all call paths. Also increase the depth tolerated, since we know there
were paths that were under-counting this value.
BUG=451265
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/868253009
|
|
These reproduce under pdfium_test with a scale factor < 1.0. Add
them to the repository now for the sake of posterity, even if we
are not automatically testing them.
BUG=451265
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/869923003
|
|
Original Review URL: https://codereview.chromium.org/861203003
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/889733002
|
|
Original Review URL: https://codereview.chromium.org/878333003
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/884873002
|
|
This was fixed by https://codereview.chromium.org/743263002, but the
bug remained open due to confusion.
BUG=https://code.google.com/p/pdfium/issues/detail?id=57
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/878523003
|
|
While we're at it, avoid an indirection through a pointer, and
use a name that isn't reserved for the compiler (leading _ CAP).
This is a small portion of the associated bug:
BUG=https://code.google.com/p/pdfium/issues/detail?id=112
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/880663003
|
|
A suitably corrupted file can cause the parser(s) to repeatedly re-read
sections of the file at increasing parser recursion depth until the
stack is exhausted. There is supposed to be a check for this based upon
the parser "level", but not all call paths pass or update the level as
required.
Much as I hate per-class statics, this introduces one to track the depth
so that the check is enforced no matter how screwy the call path might be
that leads the parser to re-enter itself. This is more palatable than trying
to find all these paths and fix them. We know this is OK since there is
only one thread in here modifying the static.
BUG=451830
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/875263002
|
|
The embeddertests binary should have source files ending in
_embeddertest, not _unittest.
TBR=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/871093004
|
|
We are making checks in the incorrect order. Also adds two test
cases, one for the this crash, and another for the original issue
that motivated the patch.
Original Patch by Bo at https://codereview.chromium.org/866003003/
BUG=450871
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/872563002
|
|
This brings BUILD.gn into equivalence with pdfium.gyp.
Blocked on https://codereview.chromium.org/851283006/
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/871453004
|
|
Currently, this is a difference between the standalone pdfium environment
vs. pdfium as part of a chromium checkout.
Locating the external data files is a nusiance when you don't have the
binary's argv[0] line, so we create a new main that preserves this for
us.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/851283006
|
|
Currently, no callers go through the Interface, which makes having a
separate interface class kind of pointless. After converting callers
away from using the CPDF_DataAvail concrete class, it can be moved
from the header to the .cpp file.
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/873523002
|
|
This also adds a fpdfdoc_embeddertest.cpp to keep the test
file name matching with the API call under test.
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/812933004
|
|
Follow-on work from patch at https://codereview.chromium.org/845643008. This
incorporates that patch, plus adds tests for it and similar conditions. A few
changes are introduced to correct expected behaviour.
This also incoprorates Deepak's fix in https://codereview.chromium.org/845643008/
This incorporates a formerly unlanded tool to generate small valid PDF
files from template input, which is needed to cover all the error cases
here. See https://codereview.chromium.org/791993006/
BUG=450133
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/837723009
|
|
Need to have return value -1 indicating insufficient buffer.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/862163002
|
|
Previously, UTF16LE_Encode take an optional flag to indicate
if the returned byte string has trailing zeros. In fact, no where
needs the flag to be false. So just get rid of it so callers won't
misuse.
The bug is found by https://codereview.chromium.org/837723009
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/860973002
|
|
This was somehow lost along the way to creating embedder tests. Presumably
this silently leaks in origin/master, but triggers an assert under XFA. Fixing
this on master is a pre-requisite for merging all the embedder test code onto
XFA.
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/856773003
|