Age | Commit message (Collapse) | Author |
|
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
|
|
These flags are unused in Chromium, but are needed for the Cloud Print
conversion process, which takes PDF and produces a raster for low-end
printers. Certain low-end printers (e.g., B&W laser printers) will
turn anti-aliased text into a mess. The existing printing flag isn't
sufficient, as other kinds of printers will still want some kinds of
anti-aliasing to occur for best results.
BUG=482253
TEST=none
R=vitalybuka@chromium.org
Review URL: https://codereview.chromium.org/1115513002
Patch from Scott Byer <scottbyer@chromium.org>.
|
|
This allows PDFium to work with current V8, so unpin v8 in the
pdfium DEPS file.
(I also re-ordered one field in CJS_Runtime, just to put two bools
together (may pack tighter), and to put all the v8 stuff together).
BUG=pdfium:146
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1118043002
|
|
Carry-on from https://codereview.chromium.org/1108903002/
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1103343002
|
|
This involves adding some explicit c_str() calls. Doing so flagged
PDF_EncodeText() and FindOptionValue() as having suboptimal signatures, in
that we are often throwing away a perfectly fine length and recomputing it.
There are still some platform-specific code that needs the operator.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1101933003
|
|
This reverts commit 15a62973b9b89c3e229cc0ab501c45967f91b325.
Reason for revert: broke build on windows, mac. I must have missed
some platform-specific conversions.
TBR=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1108883002
|
|
This involves adding some explicit c_str() calls. Doing so flagged
PDF_EncodeText() and FindOptionValue() as having suboptimal signatures, in
that we are often throwing away a perfectly fine length and recomputing it.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1101933003
|
|
The code to validate the number of parameters happens inside each particular
method, rather than prior to method dispatch. As such, there's no point in
having this number take up space in the table.
Add some test to cover at least some of the per-method validations, and
update error messages to be more useful.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1084183008
|
|
The red-flag here is the explicit invocation of things like
params[1].operator CFX_WideString()
rather than
static_cast<CFX_WideString>(params[1])
to invoke the conversion. Turns out the above won't compile due to
ambiguity given the number of implicit constructors for widestrings.
CJS_Value has both constructors and assignment operators for the
primitive types, which means that conversions can take place
unexpectedly in both directions, a second red flag.
We don't want the compiler invoking these at will since it may hide
bugs. In fact, when they are removed, three such places were
discovered.
Also rename ToJSValue to ToV8Value to match the other ToV8xxxxx
functions added.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1096813008
|
|
Also delete unused CFFL_Edit_UndoItem class.
BUG=https://code.google.com/p/pdfium/issues/detail?id=140
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1098043002
|
|
Also remove virtual methods, since this is neither subclassed nor a
subclass.
BUG=https://code.google.com/p/pdfium/issues/detail?id=140
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1097843003
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1084613006
|
|
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1089823004
|
|
CFX_Object is a type that implements its own new operators that return
NULL on error. There's no need for this given the |new (std::nothrow)|
syntax; in fact, the current code can only work if there is no activity
in the constructors. This may explain the pervasive lack of
constructors and reliance on Init() methods throughout the codebase.
The activity takes place in fx_memory.h, where FX_NEW is mapped onto
the std::nothrow syntax. The rest is just cleanup.
Down the road, we will simply throw and remove all the error-checking
paths for new objects. Landing this patch first will at least show a
simple path back to the old behaviour without having to re-introduce
CFX_Object should someone want to do so in their own fork.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1088733002
|
|
VS 2015 RC ships without afxres.h, so fpdfsdkdll.rc fails to
compile. afxres.h is really intended for MFC apps so depending on
it is a bad idea anyway, so I changed both references to
windows.h. See http://stackoverflow.com/questions/1575559 for
some other perspective on this.
R=tsepez@chromium.org
BUG=440500
Review URL: https://codereview.chromium.org/1078513002
|
|
It turns out that 'timezone' has been deprecated for a while. If
deprecation messages are enabled then VS 2013 says this when 'timezone'
is referenced:
warning C4996: 'timezone': This function or variable may be unsafe.
Consider using _get_timezone instead.
Sometimes features stay deprecated for decades, but in this case
'timezone' is now gone.
R=tsepez@chromium.org
BUG=440500
Review URL: https://codereview.chromium.org/1075673002
|
|
Original CL was accidentally based off of XFA. This CL is
off of master.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1069553002
|
|
TBR=tsepez@chromium.org
BUG=N/A
Review URL: https://codereview.chromium.org/1068513002
|
|
BUG=454595
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/1053373002
|
|
BUG=https://code.google.com/p/pdfium/issues/detail?id=137
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1039063002
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
BUG=pdfium:29
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/891113002
|
|
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
|
|
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
|
|
BUG=https://code.google.com/p/pdfium/issues/detail?id=113
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/880043004
|
|
BUG=452455
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/887063003
|
|
This removes some duplicated code from each individual test.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/885403002
|
|
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
|
|
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
|
|
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
|