Age | Commit message (Collapse) | Author |
|
- add FPDFAvail_Destroy(pdf_avail) on the early return path in RenderPdf
R=thestig@chromium.org
BUG=pdfium:236
Review URL: https://codereview.chromium.org/1410333007 .
|
|
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 .
|
|
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 .
|
|
Move the external isolate and embedder slot from the
IPDF_JSPlatforms struct supplied at the
FPDFDOC_InitFormFillEnvironment() call time to arguments to
the FPDF_InitLibraryWithConfig() call.
This has several benefits:
-- Avoids the crash that could happen if multiple
FPDFDOC_InitFormFillEnvironmen() calls should happen to be
made by an embedder with different slot values.
-- Down the road, for XFA, there may be XFA but no FormFill
environment.
We support both forms for the time being, until the chrome
side catches up, at which point we will deprecate the old
way.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1367033002 .
|
|
Also merge a check for failed document loads from XFA.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1362143002 .
|
|
Fix lint issues / git cl format.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1357423006 .
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1287863002 .
|
|
R=thestig@chromium.org
Committed: https://pdfium.googlesource.com/pdfium/+/d8b5e73d8609b74e6a995ee1768d20d47bd4b089
Review URL: https://codereview.chromium.org/1268323004 .
|
|
This reverts commit d8b5e73d8609b74e6a995ee1768d20d47bd4b089.
Broke corpus tests
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1292153002 .
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1268323004 .
|
|
Luckily, it's just one file.
BUG=none
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1281923004 .
|
|
No behavior change.
Generated by:
find . -name '*.cpp' -o -name '*.h' | \
grep -E -v 'third_party|thirdparties|lpng_v163' | \
xargs ../../buildtools/mac/clang-format -i
See thread "tabs vs spaces" on pdfium@googlegroups.com for discussion.
BUG=none
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1265503005 .
|
|
But use platform freetype for library itself according to the rules
for the platform.
This should greatly reduce per-platform diffs in the corpus tests, but
requires that the corpus be rolled at the same time.
When this rolls into chromium, its src/BUILD.gn will need to be updated
to say third_party:fx_freetype instead of third_party:freetype.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/1267493005 .
|
|
This matches the Chromium PDF plugin changes in
https://codereview.chromium.org/1230313006/
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1237233006 .
|
|
This reverts commit 304578020122cc4d2a4a8c1598694ef2b9be92b5.
Turns out that in both cases v8 is already destructed at those points,
and we can't pump the message loops.
TBR=tsepez@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1236603003 .
|
|
In Chrome, all Isolates must be created by gin
R=tsepez@chromium.org, ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1234053003 .
|
|
R=tsepez@chromium.org, ulan@chromium.org
BUG=none
Review URL: https://codereview.chromium.org/1230393006 .
|
|
Allows the following command to return only legitimate
warnings:
buildtools/checkdeps/checkdeps.py --resolve-dotdot
The remaining warnings consist of:
- fx_parser_filters.cpp, due to inclusion of
third_party/zlib_v128/zlib.h, showing the lack
of a header and some prototypes in that .cpp file.
- third_party/*, due to inclusion of fx_system.h and
the like, indicating adulterated libraries that should
be restored to their pristine state.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1233583004 .
|
|
Clang warns if there are missing braces around a subobject
initializer. The most common idiom that triggers this is:
STRUCT s = {0};
if the first field of STRUCT is itself a struct. This can
be more simply written as:
STRUCT s = {};
which also prevents the warning from firing.
Other instances of the warning have been fixed by adding
braces where appropriate.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1213523004.
|
|
Removed several header files that simply proxy other headers.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1199553002.
|
|
As indicated by:
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_rel_ng/builds/63417/steps/compile%20%28with%20patch%29/logs/stdio
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1160293003
|
|
This won't post tasks to the background threads
BUG=none
R=kcc@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/1157123003
|
|
Also change EmbedderTest::TearDown() to match the destruction order in
Chromium's PDF code.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1138143003
|
|
This involves adding some missing extern "C" { } declarations,
using FPDF_ types instead of C++ types, and converting pass
by reference arguments into pointers.
Test this using fpdfview_embedertest for simplicity.
BUG=pdfium:158
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1130843003
|
|
These are the only files that embedders of PDFium should be including.
They are entirely self-contained, and compile cleanly against -Wall so
as to not offend the code that may include them.
Having done this, we can see that chromium is pulling in two additional
files from the fpdfsdk/include/pdfwindow directory, which is not guaranteed
to work.
A few files are renamed, adding an "_" to make the names consistent.
The exception is fpdfview, which is doc'd as such in the doc.
Naturally, paths will need updating in a handful of files in chrome
when this rolls in.
BUG=pdfium:154
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1135913002
|
|
BUG=pdfium:114
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1124423006
|
|
The source files required to use the NEON function are not
included so we should not try to reference those symbols.
BUG=477162
TEST=ninja -C out_arm/Release/ pdfium_diff
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1085023003
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Original Review URL: https://codereview.chromium.org/861203003
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/889733002
|
|
Needed to land https://codereview.chromium.org/826083004/.
BUG=421063, 439661
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/848443002
Patch from Ross McIlroy <rmcilroy@chromium.org>.
|
|
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/817753002
|
|
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/814903002
Review URL: https://codereview.chromium.org/816743002
|
|
BUG=439793
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/810793004
Review URL: https://codereview.chromium.org/808293002
|
|
-remove parameter from FPDF_InitLibrary
-remove a bunch of ifdefs that are unused
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/801913002
|
|
As of the 2013 version VC++ still doesn't support the 'z' size specifier. This makes portable printing of size_t types frustrating. The simplest general solution is to use %u and cast to unsigned. If there was any possibility of the numbers getting larger than 32-bit then we would need better alternatives, but there is not.
This was found through code inspection, through /analyze, and through pdfium_test print this non-helpful message:
Loaded, parsed and rendered zu pages.
Skipped zu bad pages.
I can confirm that the fix works on Windows and it should work identically on mac. This is a follow-on to change 02e6ca4c4f.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/738433003
|
|
Change 2c021e0 fixed spelling errors in a couple of functions, but didn't
update the test code leading to two compilation errors. Fixed in this
change.
Original patch from Bruce Dawson(brucedawson@chromium.org)
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/727243002
|
|
This is the first side of a two-sided patch;
the dependency on //third_party/pdfium/samples will be included from //pdf/BUILD.gn in the chrome repo.
BUG=https://code.google.com/p/pdfium/issues/detail?id=77
R=dpranke@chromium.org
Review URL: https://codereview.chromium.org/720193004
|
|
See http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg/builds/9542/steps/compile%20%28with%20patch%29/logs/stdio
TBR=jun_fang@foxitsoftware.com,
Review URL: https://codereview.chromium.org/506053003
|
|
Pdfium reads the page number from the field of '/Count' but it can't
load the number assigned by this field due to the damaged data. Add a
check to ensure that the required page should be one of loaded pages.
BUG=406090
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/477873003
|
|
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/477173003
|
|
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/492523002
|