Age | Commit message (Collapse) | Author |
|
BUG=chromium:667012
Review-Url: https://codereview.chromium.org/2508203007
|
|
Review-Url: https://codereview.chromium.org/2514173002
|
|
It passes on Linux bots.
Review-Url: https://codereview.chromium.org/2516133003
|
|
This picks up many Mac expectation files, though not all Macs render
them the same way. This also adds a new "jetman_std" test case.
All the failures on Mac are suppressed.
BUG=pdfium:626
TBR=npm@chromium.org
NOTRY=true
Review-Url: https://codereview.chromium.org/2516133002
|
|
Some changes were required to match underlying ctors
as invoked by the templated methods.
Many release() calls go away, a few WrapUniques() are
introduced to avoid going deeper into other code.
Review-Url: https://codereview.chromium.org/2510223002
|
|
BUG=
Review-Url: https://codereview.chromium.org/2498223005
|
|
There's a path out that deletes a pointer whose ownership
was passed off earlier. This will get simpler once more
APIs take unique_ptr.
BUG=664284
Review-Url: https://codereview.chromium.org/2495003006
|
|
- Add a template for fuzzers to remove redundancy.
- Sort fuzzers in alphabetical order.
Previous attempt: https://codereview.chromium.org/2480043002/
Review-Url: https://codereview.chromium.org/2481933003
|
|
TBR=tsepez@chromium.org
Review-Url: https://codereview.chromium.org/2477323004
|
|
My OCD insists that classes be named after nouns, and "linearized"
feels like an adjective.
Remove a redundant "if" while at it.
Review-Url: https://codereview.chromium.org/2482973002
|
|
Unify some code
Move parsing of linearized header into separate CPDF_Linearized class.
Original review:
https://codereview.chromium.org/2466023002/
Revert review:
https://codereview.chromium.org/2474283005/
Revert reason was:
Breaking the chrome roll.
See https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/331856
___
Added Fix for fuzzers.
Review-Url: https://codereview.chromium.org/2477213003
|
|
of https://codereview.chromium.org/2480043002/ )
Reason for revert:
Breaking the tree:
https://build.chromium.org/p/client.pdfium/builders/windows_xfa_32/builds/619/steps/compile%20with%20ninja/logs/stdio
Original issue's description:
> Compile fuzzer sources in standalone builds.
>
> - Add a template for fuzzers to remove redundancy.
> - Sort fuzzers in alphabetical order.
>
> Committed: https://pdfium.googlesource.com/pdfium/+/470b5fa8f8dbfd2aa702d9d8cfdc03a7b486b374
TBR=dsinclair@chromium.org,thestig@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2480323002
|
|
- Add a template for fuzzers to remove redundancy.
- Sort fuzzers in alphabetical order.
Review-Url: https://codereview.chromium.org/2480043002
|
|
This is a generic API function to retrieve any viewer preference of type
name.
BUG=pdfium:414
Review-Url: https://codereview.chromium.org/2475923003
|
|
This reverts commit f0d5b6c35fa343108a3ab7a25bc2cc2b3cf105b3.
Review-Url: https://codereview.chromium.org/2478303002
|
|
TBR=tsepez@chromium.org
Review-Url: https://codereview.chromium.org/2471253004
|
|
FX_BOOL was a type just like a regular C++ bool, except that it
took 4x the space and frequently was used to hold values besides
true or false.
Review-Url: https://codereview.chromium.org/2471353002
|
|
BUG=661291
TBR=dsinclair@chromium.org
Review-Url: https://codereview.chromium.org/2469923002
|
|
BUG=660015
TBR=npm@chromium.org
Review-Url: https://codereview.chromium.org/2452523005
|
|
It's been troubling for some time that an IFX_FileStream might
actually be an in-memory buffer with no backing file.
Review-Url: https://codereview.chromium.org/2443723002
|
|
The expectation is set incorrectly to allow the test to pass.
BUG=chromium:494057
Review-Url: https://codereview.chromium.org/2430583002
|
|
The embeddertests were closing the document before the formfill environment.
This caused a use-after-free as we try to use the document during formfill
destruction.
This Cl fixes the destruction order in the embedder tests. As well, a few guards
are put in place to keep the system from crashing if the wrong destruction
order is called.
R=tsepez@chromium.org
Review URL: https://codereview.chromium.org/2398063002 .
|
|
Missed these again. Scripting fail.
BUG=pdfium:603
Review-Url: https://codereview.chromium.org/2393433003
|
|
When fuzzing the image formats, its possible to get a read request which
would go negative. Handle the request and return FALSE for the read.
BUG=chromium:621836
Review-Url: https://codereview.chromium.org/2386343002
|
|
Review-Url: https://codereview.chromium.org/2387333002
|
|
Review-Url: https://codereview.chromium.org/2386273004
|
|
Note: pdfium bots don't seem to touch these files.
Review-Url: https://codereview.chromium.org/2379973005
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2380713005
|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2382723003
|
|
And fix a typo.
TBR=tsepez@chromium.org
Review-Url: https://codereview.chromium.org/2382443004
|
|
Review-Url: https://codereview.chromium.org/2370943004
|
|
Review-Url: https://codereview.chromium.org/2357173005
|
|
Review-Url: https://codereview.chromium.org/2365143002
|
|
BUG=648935,649436
Review-Url: https://codereview.chromium.org/2360283004
|
|
Review-Url: https://codereview.chromium.org/2362623002
|
|
CFXJS_Engine class should always be constructed with an isolate, except
for its subclasses which may need to create an isolate by themselves.
Move SetIsolate() function to be protected so that only subclasses can
access it.
Review-Url: https://codereview.chromium.org/2354353002
|
|
Review-Url: https://codereview.chromium.org/2342203006
|
|
On Acrobat, if "/AP" is present on a text markup definition,
the coordinates used to draw the annotation come from "/Rect
values, whereas if "/AP" is not defined, the array defined
in /QuadPoints is used to grab the annotation coordinates from.
PDFium, on the other hand, uses "/Rect" regardless of
presence or absence of "/AP".
CL fixes PDFium to work similarly to Acrobat, in this case.
TEST=testing/resources/pixel/bug_585_*.in
BUG=pdfium:585
Review-Url: https://codereview.chromium.org/2289293005
|
|
CPDF_Font::UnicodeFromCharcode returns 0 only if ToUnicode map maps the
charcode to 0. CPDF_SimpleFont::UnicodeFromCharcode and CPDF_CID_Font::
UnicodeFromCharCode return 0 only if the call to CPDF_Font returns 0.
In other cases, these methods return an empty string. So when
processing text, a 0 return from the method should not be replaced
with the charcode.
BUG=pdfium:583
Review-Url: https://codereview.chromium.org/2342073002
|
|
When unloading a page in the embedder tests we need to cleanup the internal
page map so if we load the page a second time we don't get a previously unloaded
page.
Review-Url: https://codereview.chromium.org/2322523002
|
|
Also roll:
buildtools to adb8bf4e.
skia to 3ee255f2.
v8 to 3d96d7ee.
And make tweaks to get it all working.
Review-Url: https://codereview.chromium.org/2283883002
|
|
Each annotation has its contents, and users should be able to see the
contents. In this patch, PDFium creates a Popup annotation for each
annotation and stores the author and the content. When a user mouse
hover on the annotation, PDFium draws the corresponding Popup annotation
and displays the content.
Also, roll DEPS for testing/corpus to 5867fa6.
BUG=62625
Review-Url: https://codereview.chromium.org/2273893002
|
|
In [1], it was made a mistake in the way the test case
testing/resources/pixel/bug_492.pdf was generated.
This CL aims at fixing this mistake by:
1- keep making use of the new pdfium_test capability
introduced by [1],
2- add a proper .in file for the test case to generate
its respective .pdf file.
[1] https://codereview.chromium.org/2277063003/
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2286023002
|
|
Although notably, the parameters handling support is not
complete, CL intends to be the first step towards a more
complete implementation of this API.
TEST=testing/resources/javascript/bug_492_1.in
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2281273002
|
|
BUG=pdfium:559
Review-Url: https://codereview.chromium.org/2286653002
|
|
In [1], the lack of support of pdfium_test to some application
level hooks was felt.
More specifically, the lack of implementation of the hook FFI_GetPage,
called when 'this.getAnnot()' is executed in an Acrobar JS context,
makes it non-trivial to JS texts that manipulate PDF annotations.
[1] https://codereview.chromium.org/2265313002/
Here is the failing call stack in pdfium_test:
0 ::RenderPdf (samples/pdfium_test.cc)
1 ::FORM_DoDocumentOpenAction (fpdfsdk/fpdfformfill.cpp)
2 CPDFSDK_Document::ProcOpenAction (fpdfsdk/fsdk_mgr.cpp)
3 CPDFSDK_ActionHandler::DoAction_DocOpen (fpdfsdk/fsdk_actionhandler.cpp)
<----v8---->
4 Document::getAnnot (fpdfsdk/javascript/Document.cpp)
5 CPDFSDK_Document::GetPageView (fpdfsdk/fsdk_mgr.cpp)
6 CPDFDoc_Environment::FFI_GetPage (fpdfsdk/include/fsdk_mgr.h)
(frame 6 returns nullptr, and getAnnot call in frame 4 bails)
CL extends pdfium_test app with a FFI_GetPage hook implementation.
Basically what FFI_GetPage does is returning a FPDF_PAGE instance.
In case of pdfium_test, FPDF_PAGE instances were only created on demand
when the page was going to get rendered, and then discarded.
Since FFI_GetPage can be called by JS before pages are rendered,
CL moved the page creation code into a helper function, and cached
the FPDF_PAGE instances created in a map, so it does not recreate
them needlessly.
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2277063003
|
|
Embedder test's delegate function GetPage() calls FPDF_LoadPage() to
load a page which may be already loaded by embedder test itself.
Thus the page's ref count is increased unnecessarily.
This causes the page to be leaked. Fix this by putting the page map in
embedder test class and guarantee the page is loaded only once.
Also, fix leaks in this embedder tests by unloading the loaded pages to
properly release the resource.
BUG=pdfium:242
Review-Url: https://codereview.chromium.org/2258333002
|
|
Review-Url: https://codereview.chromium.org/2262703003
|
|
BUG=636559
Review-Url: https://codereview.chromium.org/2255083004
|
|
The PDF specification [1] says:
"
syncAnnotScan guarantees that all annotations will be scanned
by the time this method returns.
(..)
Normally a background task runs that examine every page and
looks for annotations during idle times.
"
The statement details specifically how Acrobat implements
this method.
Although, neither the method itself nor the background scanner
task are implemented in PDFium (as of today, Ago/2016),
not having ::syncAnnotScan at least stubbed out can be considered
harmfull since its absence makes JS acrobat scripts silently
fail when it has a call to it.
Given that, and following a stub-out pattern present in other
methods including ::addAnnot and ::addField, CL provides
a stubbed out implementation of Document::syncAnnotScan.
[1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_api_reference.pdf
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2265553002
|