Age | Commit message (Collapse) | Author |
|
Needed to fix the failed pdfium_unittests on windows. Ironically,
I created these constants so I wouldn't mix up size_t's and off_t's
in these tests, but I didn't apply them consistently.
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1036743005
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
BUG=chromium:445408
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/952423002
|
|
BUG=457493
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/960183004
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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 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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Orignal CL at https://codereview.chromium.org/852493002/
TBR=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/849603003
|
|
BUG=445475
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/837093002
|
|
This is done by explicitly adding a virtual dtor to interface classes,
since the cost is small given that there are already virtual functions.
The exceptions are for classes that have a Release() or Delete() method,
in which case it is non-virtual and protected to indicate that the virtual
class is never the deletion point.
BUG=
R=brucedawson@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/810883005
|
|
patch from issue 680873002 at patchset 40001 (http://crrev.com/680873002#ps40001)
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/841943003
|
|
This fixes a few cut-n-paste errors in the previous version, plus
adds more corner cases. The implementation is fixed to handle a
few of these that failed.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/808553013
|
|
This allows integration with the gtest EXPECT_* macros.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/837843002
|
|
pdfium builds on Win32 have about 85 warnings (250 in the XFA
branch, totaling over 480 lines!), mostly from four lines in
a header file and a warning that should be disabled. This
change resolves all but two of them and turns on
warning-as-errors. Bugs have been filed for the two
remaining warnings:
https://code.google.com/p/pdfium/issues/detail?id=100
the 64-bit warnings:
https://code.google.com/p/pdfium/issues/detail?id=101
and the Linux warnings:
https://code.google.com/p/pdfium/issues/detail?id=102
The fix to the double->float truncation bugs will also
improve code-generation.
R=bo_xu@foxitsoftware.com, scottmg@chromium.org, tsepez@chromium.org
Review URL: https://codereview.chromium.org/792953005
|
|
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/837533003
|
|
This is a follow-up to f9640495.
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/825983004
|
|
The g_UnicodeData_Normalization_Map2 array is initialized with a size of
1724 in core\src\fpdftext\unicodenormalizationdata.cpp but its size is
1734 (+10) in core\src\fpdftext\unicodenormalization.cpp, 1724 seems to be
the real size (i.e. there's 1724 values in the initialization list).
BUG=446057
Original Author: sebmarchand@chromium.org
Original CL: https://codereview.chromium.org/837523002/
Review URL: https://codereview.chromium.org/812843004
|
|
Remove CPDF_Dictionary*() operator in CPDF_Bookmark class.
Unify naming conventions and coding styles.
Change some functions to const.
Change the name of function argument to |pDict| for FPDF_xxx type variable.
This makes the code more clear and gives better variable naming
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/828203002
|