| Age | Commit message (Collapse) | Author |
|---|
|
Test-only CL.
Change-Id: Ica1613c42075adb5fedfef6d66d99095cef08655
Reviewed-on: https://pdfium-review.googlesource.com/c/44410
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
Adjust expected results accordingly.
Order functions to match platform member order.
Change-Id: I3d5f8e3ef8f532af0891b7fbbc1a8305d1922a75
Reviewed-on: https://pdfium-review.googlesource.com/c/44311
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
Use ExpandKeywordParams() rather than ad-hoc processing.
Add test case for {} argument.
Change-Id: I1f60a87b3995d62f4bead79245a1f58fd31b102e
Reviewed-on: https://pdfium-review.googlesource.com/c/44290
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
The only way to theoretically get one is via doc.getPrintParams(),
and it always returns in error.
Even if one were returend to JS, there aren't any methods/callbacks
to change its properties.
Even if there were methods to change its properties, the information
it stores doesn't align with what is in the JS spec for this object.
Even if it were aligned with the JS spec, the way we check for its
presence as the ninth parameter in CJS_Document::print() doesn't
match the way its use is documented in the spec as the sole
first parameter.
Instead implement the older, simpler behaviour as spec'd prior to
6.0, and toss this enhancement altogether.
Move function to check the result of ExpandKeywordParams() to
js_define.h so other files can use it. Update comment in that
file to remove reference to deprecated enum.
Expand test for API and introduce callback to log parameters.
Change-Id: I047e2be0d2afbad91d6b58c6c74bbea083fed330
Reviewed-on: https://pdfium-review.googlesource.com/c/44271
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
Also alphabetize mailDoc method position in .cpp file.
Change-Id: Ifb53e9a6f5f165bb41b865d51dae15e3bc84c4c7
Reviewed-on: https://pdfium-review.googlesource.com/c/43972
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
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
|
|
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
|
|
CL implements the first step in order to support
Annotations manipulation in PDFium: Document::getAnnot.
The method takes two arguments, an integer (page number)
and a string (annotation name).
When called, it iterates over the annotations on
the given page number, searching for the one whose name
matches the string in the second parameter.
If found, then an Annot instance (see Annot.cpp/g added by this
CL), is bound to a Javascript object and returned.
With the use cases described in bug [1] as an initial test case,
CL adds support to the following Annotation object properties:
- hidden
- name
- type
Idea is to keep evolving the implementation with more methods
and properties in follow up CLs.
[1] https://bugs.chromium.org/p/pdfium/issues/detail?id=492
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2260663002
|
|
Patch implements the Document's API gotoNamedDest, which is
part of the PDF specification [1], page 129, with the following
(short) description:
"Use this method to go to a named destination within the
PDF document".
[1] http://partners.adobe.com/public/developer/en/acrobat/sdk/5186AcroJS.pdf
"Named destination" is a common concept in the PDF world.
It can be used together with PDF's Links, Annotations, Bookmarks
and OpenActions, as well as an action per se, in case "this.gotoNamedDest"
is called directly.
Note that the implementation makes use of the existing hook
CPDFDoc_Environment::FFI_DoGoToAction, which ends up calling
out the embedder to actually handle it.
In case of Chromium, for instance, it calls PDFiumEngine::Form_DoGoToAction
which only handles for now the "page" property of the "destination".
Other properties, including zoom level, and scroll position
are ignored for the moment.
BUG=pdfium:492
Review-Url: https://codereview.chromium.org/2221823003
|
|
TBR=dsinclair@chromium.org
Review URL: https://codereview.chromium.org/1430663003 .
|
|
(cherry picked from commit 6e369c2ebb4769a42736b32154c0de12b73df45d)
Original Review URL: https://codereview.chromium.org/1327473002 .
BUG=489995
R=thestig@chromium.org
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1325743002 .
|
|
Original Review URL: https://codereview.chromium.org/1084183008
TBR=thestig@chromium.org
Review URL: https://codereview.chromium.org/1105813002
|
