Age | Commit message (Collapse) | Author |
|
Error is "converting to non-pointer type 'FX_DWORD'".
TBR=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/726033002
|
|
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
|
|
Context: DEPS was originally added to pdfium to allow its recipe to
automatically check out its dependencies. The recipe used absolute
paths, and so the checkout directory's name ('pdfium') had to be
prefixed to the directory checkout of every dependency, as gclient in
the recipe worked one level above the pdfium checkout itself.
After change fe4537269fc7133320a5131638757f2ffa6bd854, the recipe no
longer worked. To fix this, I'm making DEPS use relative paths.
BUG=375773
R=jam@chromium.org
Review URL: https://codereview.chromium.org/724113003
|
|
BUG=401988
R=vitalybuka@chromium.org
Review URL: https://codereview.chromium.org/618073003
|
|
The flag variable is conditionally initialized but unconditionally read.
Warning was:
src\fpdfapi\fpdf_page\fpdf_page_pattern.cpp(274) : warning C6001:
Using uninitialized memory 'flag'.
BUG=427616
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/703213004
|
|
found by /analyze on some error paths
Warning from /analyze was:
src\third_party\pdfium\fpdfsdk\include\fsdk_mgr.h(96) : warning C6001: Using uninitialized memory 'fxtime'.
Other error paths can also lead to reading from an uninitialized _FX_SYSTEMTIME object.
Code-gen for the constructor is small enough (four writes of zeroed EAX with VC++, less with gcc) to make putting the constructor in a .cc file unnecessary.
Approval of in-class member initialization would make this fix simpler but that has not quite been approved yet.
BUG=https://code.google.com/p/pdfium/issues/detail?id=70
BUG=427616
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/692533005
|
|
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/695183005
|
|
BUG=418582
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/680833006
|
|
BUG=425129
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/688303003
|
|
BUG=414036, 425151
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/688633003
|
|
Add a check for zero-length keys to avoid hitting the equivalent of |""[1]|.
BUG=https://code.google.com/p/pdfium/issues/detail?id=58
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/665223003
|
|
BUG=418976, 425150, 414525
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/671943002
|
|
pTransfer function is released in pDocRender cleanup but is still being accessed in
~CPDF_GeneralStateData in pDocPage cleanup.
BUG=419320
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/662063003
|
|
BUG=414089, 414310, 414606
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/670813002
|
|
This patch is supplementary to issue 418881
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/645793007
|
|
You can get warning when using FXARGB_GETDIB() with & operation in
the same statement like: FXARGB_GETDIB(src_scan) & 0xffffff in
fx_dib_composite.cpp:
../../third_party/pdfium/core/src/fxge/dib/fx_dib_composite.cpp:737:205:
error: '&' within '|' [-Werror,-Wbitwise-op-parentheses]
Original patch from jiangj@opera.com
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/578253002
|
|
This makes gclient config and gclient sync work.
BUG=423896
TBR=aneeshm@chromium.org
Review URL: https://codereview.chromium.org/656353002
|
|
BUG=423883
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/663633002
|
|
This is a re-landing of the changes in https://pdfium.googlesource.com/pdfium/+/6387aff
which were lost during a libopenjpeg library roll.
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/661463003
|
|
CPDF_Pattern objects are counted and maintained in m_PatternedMap.
When a CPDF_Pattern object "pattern" is deleted, it's address is marked as NULL in m_PatternMap.
This patch stores the address of CPDF_Pattern's adderss in all objects that references "pattern",
to ensure valid referencing after deletion.
BUG=416319, 419976, 418392
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/656753002
|
|
CPDF_StreamContentParser::Parse.
This is just a bit of defensive programming; I'm not sure the situation can
occur in the current code, but the following code is likely to set off a red
flag to anyone who reads it:
CPDF_StreamParser syntax(pData, dwSize);
m_pSyntax = &syntax;
since the extent of the local |syntax| is far less than the pointer member
|m_pSyntax|. NULL it out before syntax goes out of scope.
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/652063002
|
|
Glyph index shall be less than number of glyphs.
BUG=418585
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/652363002
|
|
BUG=421196
R=bo_xu@foxitsoftware.com
Review URL: https://codereview.chromium.org/656463006
|
|
BUG=418881
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/648823002
|
|
BUG=pdfium-52
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/623893003
|
|
BUG=413375
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/624023003
|
|
Openjpeg removed the definition of OPJ_STATIC in openjpeg.h.
This change is merged in https://pdfium.googlesource.com/pdfium/+/d53e6fdb0a86ca1ddb12876a60f7f2d7508b5349
So need to add OPJ_STATIC to pdfium.gyp
BUG=None
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/624043002
|
|
BUG=407964, 414182, 413447
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/589243004
|
|
BUG=none
TEST=none
R=jam@chromium.org
Review URL: https://codereview.chromium.org/605273004
|
|
forward_dependent_configs_from => public_deps
direct_dependent_configs => public_configs
R=jam@chromium.org
Review URL: https://codereview.chromium.org/598093002
|
|
BUG=410326
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/594403003
|
|
BUG=none
R=jam@chromium.org
Review URL: https://codereview.chromium.org/581413002
|
|
Security handler revision number is needed to interpret file permission.
BUG=None
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/589813002
|
|
BUG=408532
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/524443002
|
|
Images are basic resource and are referred or used by other objects in some cases. Images should be released after the objects who uses these objects. In this case, an image object is accessed in the process of CPDF_TilingPattern's destroy. Unlikely, this image has been destroyed before.
BUG=414046
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/582993002
|
|
This was introduced at PDFium revision 12a9940. There was a subtle logic
change for null |parray|.
BUG=415438
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/579363002
|
|
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
|
|
pattern
BUG=414661
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/572853006
|
|
Before this fix, only |gindex < face->num_locations| is checked. However, the pointer, p, will be moved to next location in the first FT_NEXT_ULONG or FT_NEXT_USHORT. It may cause a crashier. So a boundary check is needed before the second FT_NEXT_ULONG or FT_NEXT_USHORT.
BUG=412457
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/571833002
|
|
BUG=414155
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/574463002
|
|
There is an image object and text objects in this document, but the character in each text object is reversed.
When rendering, the image object is shown.
However, when highlighting, the text object is selected, resulting in text index issue.
Moreover, the character in the document is in reading order, which is different from normal document.
BUG=pdfium:43
R=jbreiden@google.com
Review URL: https://codereview.chromium.org/484503002
|
|
BUG=387970
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/551503003
|
|
m_pDocument in CPDF_Color
If not forced clear, the counter of CPDF_Pattern will take care the count of referenced instance.
When forced clear, clear color first to make sure pattern still exists when referencing it.
BUG=411154
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/554913003
|
|
BUG=411161
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/560673002
|
|
of https://codereview.chromium.org/547863002/)
Reason for revert:
The initialized member variable is wrong. Needs to undo this.
Original issue's description:
> Fix uninitialized value in CPDF_ColorStateData
>
> BUG=411161
> R=tsepez@chromium.org
>
> Committed: https://pdfium.googlesource.com/pdfium/+/a38d4c3572b566f8e64b9ca4f725cbbc581e85ab
TBR=tsepez@chromium.org,jun_fang@foxitsoftware.com
NOTREECHECKS=true
NOTRY=true
BUG=411161
Review URL: https://codereview.chromium.org/558803004
|
|
BUG=411161
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/547863002
|
|
BUG=411163
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/551513005
|
|
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
|
|
BUG=
R=jun_fang@foxitsoftware.com
Review URL: https://codereview.chromium.org/534363002
|
|
but no its direct object '112 0 object' in the test pdf file. Without checking the validity, it causes a null pointer when trying to get the direct object by an indirect object.
BUG=390781
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/553613003
|