| Age | Commit message (Collapse) | Author |
|---|
|
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
|
