Age | Commit message (Collapse) | Author |
|
Removal of fpdfapi_ suffix can be part of a future CL.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1186113005.
|
|
Second CL to apply less restrictive flags to third party.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1181943008.
|
|
Creates a separate library so we can apply less-strict warnings to
the code we can't change from upstream vs. the code we can change,
reducing noise in the standalone build.
Remove needless foo.{cpp,h} files that merely perform indirection
via #include "some_other_path/foo.{cpp,h}".
BUG=pdfium:166
R=brucedawson@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1152743007.
|
|
Small bit of OCD here, since this file is included cross-library
(i.e. from fpdfsk), it can't be in src/. In other words, the
following should be empty:
grep -R 'include.*core/src/' fpdfsdk
Fix some IWYU in it at the same time.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1147353006
|
|
Reproducing this bug requires the embedder to fire timers, something the
single-pass pdfium-test binary doesn't do properly at the present. So
we modify the embedder test delegate to allow the immediate triggering
of the same.
Perform some cleanup along the way by removing EmbedderTestDefaultDelegate
-- it buys us nothing over the the no-op one.
And, of course, v8 initialization is busted again, and we need v8 here.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1153213004
|
|
R=vogelheim@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1146933002
|
|
Add a FX_TryAlloc() for those few cases where we might need to continue
in face of OOM.
Remove FX_AllocNL() (the context of its use would suggest that NL
means "No Limit"). This is used for some big allocations, so replace
it with TryAlloc(). Large allocations may be worth trying to continue
from, since there are few and they have a large chance of failing.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1128043009
|
|
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
|
|
... rather than redundantly declaring them in several .cpp files, and
hoping that the linker lines things up for you.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1128193004
|
|
As part of the migration from GYP->GN, we want to make sure that we
can track when new targets are added to either the GYP or GN builds
and that we are building everything we expect to build.
In GN, unlike GYP, if a build file gets referenced from other files,
building 'all' will cause every target to be built in it. This means in
particular, that we can end up trying to build targets that are not
necessarily intended to be visible to the rest of the build. To get
around this, any target that is defined but hidden (like 'pdfium_unittests',
) should still be visible to a top-level target called
"//:gn_visibility".
R=tsepez@chromium.org, brettw@chromium.org
BUG=461019
Review URL: https://codereview.chromium.org/1120183002
|
|
The initialization sequence becomes more complicated as v8 evolves
and when we move to XFA (where pdfium_unittests are currently broken).
Centralize this initialization in a few places, like the embedder_test
framework and the pdfium_test binary, and convert tests that require
it into embedder_tests rather than unit_tests.
Change on master first before moving to XFA.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1071343002
|
|
Move some typedefs for v8 types into fxjs_v8.h wrapper to
avoid circular inclusions. Also delete JS_Module.h, as no
other file includes it.
BUG=https://code.google.com/p/pdfium/issues/detail?id=66
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1060133002
|
|
When there is a wrong keyword like '??ze' in the dictionary
of the trailer, PDFium can't recognize it and aborts further
parsing. After this change, PDFium continues even it can't
get the right size at this moment. It will rebuild the cross
reference table later since the size of the table is missing.
BUG=459580
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1055323003
|
|
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
|
|
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
|
|
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
|
|
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
|
|
R=jam@chromium.org
BUG=344767
Review URL: https://codereview.chromium.org/945723004
|
|
Clean in standalone pdfium, but this would block a pdfium
roll into chromium.
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/903903003
|
|
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
|
|
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 giving duplicate symbols for main when linking PDFium into Chromium.
BUG=453844
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/897463003
|
|
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 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 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
|
|
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
|
|
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
|
|
on behalf of qsr@
TBR=qsr@chromium.org
Review URL: https://codereview.chromium.org/852983003
|
|
Brings GN build up to sync with GYP build for this test binary.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/840343005
|
|
Buildbot fails with the recent changes.
Review URL: https://codereview.chromium.org/796243003
|
|
PDFium has not yet had a unit-tests binary, so introduce one based on
the typical gtest framework. Also provide a small initial test fragment
for fxcrt strings for instructional purposes.
Naturally, doing so kicked out one corner case that isn't handled, we'll
fix that in a separate patch.
This is a small part of the testing strategy tracking bug.
BUG=https://code.google.com/p/pdfium/issues/detail?id=62
R=brucedawson@chromium.org, palmer@chromium.org
Review URL: https://codereview.chromium.org/831653002
|
|
Put freetype into third_party directory, cleaning up header files.
Previously freetype header files are in core/src/fxge/freetype and core/include/thirdparties. There were also multiple fx_freetype.h.
This patch removes the additional Foxit wrapper to make further update easier.
Notice, for original freetype source code, the following files are modified and need to be updated accordingly in future update:
third_party/freetype/include/config/ftmodule.h
third_party/freetype/include/config/ftoption.h
BUG=407341
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/815103002
|
|
TBR=tsepez
Review URL: https://codereview.chromium.org/804463003
|
|
-remove parameter from FPDF_InitLibrary
-remove a bunch of ifdefs that are unused
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/801913002
|
|
This patch follows https://pdfium.googlesource.com/pdfium/+/44047c3300d07192a67b1714084cc2d43b1e9bd9
Modify the library to resolve compile error,
add copyright notice and change pdfium.gyp and BUILD.gn
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/754743003
|
|
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/695183005
|
|
forward_dependent_configs_from => public_deps
direct_dependent_configs => public_configs
R=jam@chromium.org
Review URL: https://codereview.chromium.org/598093002
|
|
Not required since: https://code.google.com/p/pdfium/issues/detail?id=28
R=jam@chromium.org
BUG=chromium:335824
Review URL: https://codereview.chromium.org/567393004
|
|
GN visibility currently allows either string or list types, but this is causing
some problems for some templates. I'm going to require it to be lists, so am
changing all callers before pushing the new binary.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/555523002
|
|
This is required for the call to v8::platform::CreateDefaultPlatform.
R=jam@chromium.org
Review URL: https://codereview.chromium.org/540133002
|
|
This reverts commit 4923e3cfbc2b617614858c427fa87a8c67aca784.
Since exceptions are in the process of being removed,
and the code currently isn't rollable into pdfium (for other
reasons) I'm going to revert this for now, so that this CL
doesn't become blocking-for-rolls if the other min/max problem
is addressed.
And, hopefully by the time I get back to this it won't be
necessary anyway.
BUG=pdfium:28,pdfium:31,chromium:354261
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/432243002
|
|
Goes with https://codereview.chromium.org/431803003/
R=jam@chromium.org
BUG=chromium:354261
Review URL: https://codereview.chromium.org/426153007
|
|
It remains to call the PumpMessageLoop() method at a regular interval,
however, since nothing posts to the loop yet, that shouldn't be a
problem.
BUG=25
R=jam@chromium.org
Review URL: https://codereview.chromium.org/374123002
|
|
TBR=palmer@chromium.org
Review URL: https://codereview.chromium.org/378073002
|