Age | Commit message (Collapse) | Author |
|
Current behavior:
Our CPVT_GenerateAP::Generate*AP() functions do not get called as
long as the annotation dictionary has an "AP" entry.
Problem:
We always need the "N" entry in AP dictionary to display an
annotation. Even though the spec requires "AP" dictionary to have an
"N" entry for normal mode appearance, in case of a malformed pdf
with "AP" but without "N" in "AP", we won't be able to display the
annotation at all.
Fix:
Always check if "AP" has "N" entry to decide whether AP needs to be
generated. If not, then we still need to generate AP, and add to the
AP dictionary under the key "N".
Bug=pdfium:778
Change-Id: Icf0c6a681b3c8c22b0b67bf8d16ce6fefdc2c45b
Reviewed-on: https://pdfium-review.googlesource.com/6692
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Jane Liu <janeliulwq@google.com>
|
|
At least one nonnull entry needs to be in OCGs for it to be considered
present. See "OCGs" in table 4.49 in the PDF 1.7 spec.
Bug: pdfium:491.
Change-Id: I7eae65ba1fabff9cf1d5cea50d059a04814a3fec
Reviewed-on: https://pdfium-review.googlesource.com/6751
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
The test should be reenabled by this change. Also updated the
expected .png, as it's slightly displaced since it was run a year ago.
Change-Id: I2e7003f8b353212804d3fd7af08c41476351f575
Reviewed-on: https://pdfium-review.googlesource.com/6813
Reviewed-by: Nicolás Peña <npm@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
|
|
There are three comboboxes:
1) Normal combobox with pre-selected value.
2) User editable combobox.
3) Read-only combobox, which is actually invisible.
Change-Id: I6bc7955459a11bf043ace7002393c2d7ee8471e9
Reviewed-on: https://pdfium-review.googlesource.com/6770
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
|
|
BUG=chromium:733245
Change-Id: Ic9347e2cc245831c0b71fac1d531c33c5646ab3f
Reviewed-on: https://pdfium-review.googlesource.com/6671
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nicolás Peña <npm@chromium.org>
|
|
It's possible to create a stream of length 0 in a PDF document.
Currently the code will early exit and return a nullptr. This causes
issues when you want to print the given PDF as the FPDF_ImportPages code
ends up only generating up to the zero length object.
This CL allows creating streams with length 0 and updates the PDF saving
code to output a blank stream.
Bug: chromium:732380
Change-Id: I44182ba4aaac7c51284b002ba01bbc34b6bcf9e0
Reviewed-on: https://pdfium-review.googlesource.com/6490
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
1. Added API for extracting annotation properties:
* Added testing flag "--annot" that outputs the annotation properties
into a .txt file.
* Added two embedder tests covering all the API functions.
Bug=pdfium:737
Change-Id: I95943a9b2b3d5d431bc8a74a31b27b4f4b521026
Reviewed-on: https://pdfium-review.googlesource.com/6092
Commit-Queue: Jane Liu <janeliulwq@google.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
Calling ToLocalChecked() will crash otherwise.
Bug: 707673
Change-Id: I66a5b36d8cf1710a725e30c2d14a195d08ef25a4
Reviewed-on: https://pdfium-review.googlesource.com/6130
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
BUG=pdfium:717
R=dsinclair@chromium.org,thestig@chromium.org
Change-Id: I7e0e6fd301d40f9b5341d40cf11167b7748af243
Reviewed-on: https://pdfium-review.googlesource.com/6071
Reviewed-by: dsinclair <dsinclair@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
Bug: chromium:113910
Change-Id: I52d712828a0adde02b1e867421ee06f1ca8be1e2
Reviewed-on: https://pdfium-review.googlesource.com/5636
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
This Cl adds the basis of the test framework to execute the javascript
produced by CXFA_FM2JSContext and verify the results are correct.
Change-Id: Ie46625b7e27ca0808e9cc41fdc00b7c0a212837d
Reviewed-on: https://pdfium-review.googlesource.com/5651
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Bug: chromium:528103
Change-Id: I990c829af8c6a9f481a34fc0e25de6814bbab34a
Reviewed-on: https://pdfium-review.googlesource.com/5633
Reviewed-by: dsinclair <dsinclair@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
This regressed in commit e21fe98. When the image's bpc is a multiple of
8, there exists a colorspace, and there is a Decode parameter, the image
data source was incorrectly pointing to a data structure that only
contained black pixels.
BUG=chromium:718762
Change-Id: I5d3fa739e41726b4ed1ebc16465e17f83fff9f8d
Reviewed-on: https://pdfium-review.googlesource.com/5333
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
The ToUnicode map should not be ignored when it exists. Doing so can cause a
charcode to be assigned an incorrect glyph index, and will result in garbled
text.
Previously, some bots failed with 'unable to open' the .png file.
Bug: chromium:665467
Change-Id: I435a73647eadcc3ba37bb0120f3b5cee381ae7a3
Reviewed-on: https://pdfium-review.googlesource.com/5610
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
This reverts commit dde95d8be9bc2817e34429fc38ee6d89d6d5ab75.
Reason for revert: the test added is flaky
Original change's description:
> Small fix in CPDF_TrueTypeFont load
>
> The ToUnicode map should not be ignored when it exists. Doing so can cause a
> charcode to be assigned an incorrect glyph index, and will result in garbled
> text.
>
> Bug: chromium:665467
> Change-Id: I21c1bf560a0731d974191d4189ea730ef9868334
> Reviewed-on: https://pdfium-review.googlesource.com/5512
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Commit-Queue: Nicolás Peña <npm@chromium.org>
>
TBR=thestig@chromium.org,tsepez@chromium.org,dsinclair@chromium.org,npm@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Bug: chromium:665467
Change-Id: I704a34f326d31018061bcfd857fb25f7e4ee4cc2
Reviewed-on: https://pdfium-review.googlesource.com/5493
Reviewed-by: Nicolás Peña <npm@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
The ToUnicode map should not be ignored when it exists. Doing so can cause a
charcode to be assigned an incorrect glyph index, and will result in garbled
text.
Bug: chromium:665467
Change-Id: I21c1bf560a0731d974191d4189ea730ef9868334
Reviewed-on: https://pdfium-review.googlesource.com/5512
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>
|
|
The FPDF_LoadDocument call was missing the CheckUnSupportedError so, if
the document contained unsuppoted information the user would not be
notified. This brings the method in line with the other loading methods.
Change-Id: I308b25335a228eb02c51562f9caf91cda9193b73
Reviewed-on: https://pdfium-review.googlesource.com/5336
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
|
|
Normalize rotations read from PDF documents. Make FPDFPage_GetRotation
always return a value 0 to 3 as specified in fpdf_edit.h instead of
returning the page rotation / 90 (page rotation may be negative for some
PDFs).
BUG=chromium:713197
Change-Id: Ie477803f7d298b777a3ace89b21cfda8b7f6808b
Reviewed-on: https://pdfium-review.googlesource.com/4532
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
|
|
This CL adds a minimized test case for https://crbug.com/714187 in order
to keep it from regressing in the future.
Bug: chromium:714187
Change-Id: I913f380c85a57621424d82165393b1616c2f6a9a
Reviewed-on: https://pdfium-review.googlesource.com/4491
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
|
|
Doing so trips an assert in the debug build but is harmless otherwise.
This appears to be wrong since the beginning of time.
Bug: 709793
Change-Id: I179f6944a3f7b2a89efa65a16078f6f58448ba4b
Reviewed-on: https://pdfium-review.googlesource.com/4390
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
This CL adds an embeddertest that adds text to a textfield and saves it. It
also adds a new 'charcode' option for .evt files in pdfium_test.
Change-Id: I14fbf50e2b1d5ae0bdc68d1dd25dc4f889c49bfb
Reviewed-on: https://pdfium-review.googlesource.com/4150
Commit-Queue: Nicolás Peña <npm@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
BUG=pdfium:601
Change-Id: I07756cd208cd2221802ff2d331f316b6618a41e0
Reviewed-on: https://pdfium-review.googlesource.com/3120
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
Bug: pdfium:626
Change-Id: I93a0d02c26d1a44c0fca666cfd09df32ecc1a23d
Reviewed-on: https://pdfium-review.googlesource.com/3222
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
CloneNonCycle() tries to detect cyclic object references without copying
them. There are two issues:
-- for elements in an array or a dictionary, they should be able to
refer to the same object, which are not cyclic;
-- for cyclic referenced elements in an array or a dictionary, do not
clone the element at all. Having nullptr or <key, nullptr> as an element,
like we did before, might cause crash when the element being accessed.
BUG=chromium:701860
Change-Id: Id0304accde76ed06fa5ce640994c7628359600fb
Reviewed-on: https://pdfium-review.googlesource.com/3156
Commit-Queue: dsinclair <dsinclair@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
|
|
When a web link has a hyphen at the end of line, we consider it to
be continued to the next line. For example, "http://www.abc.com/my-\r\ntest"
should be extracted as "http://www.abc.com/my-test".
BUG=pdfium:650
Change-Id: I64a93d9c66faf2be0abdaf8cfe8ee496c435d0ca
Reviewed-on: https://pdfium-review.googlesource.com/3092
Commit-Queue: Wei Li <weili@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
|
|
JS Array Buffers are the first candidate to be allocated from
PartitionAlloc when it becomes available, so add test first.
Presently, we will return as large an array buffer as the system
can handle; this is generally a bad idea so limit them to 256MB
and test that we handle failure.
Change-Id: I205745a7938d69eb32ac883b90824f2f9e584ec7
Reviewed-on: https://pdfium-review.googlesource.com/3065
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
The expected way to create native PDFium objects for JS is via
the NewFxDynamicObject() call in C++, but that doesn't mean that the
corresponding constructors won't be called from JS. In that case,
the internal fields will be uninitialized, and subsequent method
calls may try to use them.
Add a constructor callback for all PDFium objects that nulls out
these fields (shame that v8 doesn't do this by default, but probably
saves some cycles). Then ensure that we check for this possibility
in all the places it might turn up.
Conversely, if we've just gotten a successful return from
NewFxDynamicObject(), we know the CJS_Object/EmbedObj are good,
so avoid checking there.
BUG=695826
Change-Id: Iadad644c4af937def967ddc83daac1dad7544d69
Reviewed-on: https://pdfium-review.googlesource.com/2839
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Tom Sepez <tsepez@chromium.org>
|
|
Moving to std::vector from the more forgiving CFX_ArrayTemplate
revealed the dubious page tree traversal, which depends on the
correctness of the /Count entries to properly summarize the total
descendants under a given node.
The only "correct" thing to do is to throw away these counts as parsed,
and re-compute them, perhaps in CountPages(). But I'm not willing to do
that since it may break unknown documents in the wild.
Pass out-params as pointers while we're at it.
BUG=680376
Review-Url: https://codereview.chromium.org/2636403003
|
|
A return of ID == 0 from the embedder means the timer was not
created (see public/fpdf_formfill.h), although few embedders
actually conform to this convention.
Firing a timer with ID == 0 will thus do nothing since there can't
be such a timer in the map.
BUG=679649
Review-Url: https://codereview.chromium.org/2626863003
|
|
In this case, we observe the destruction of the object, but have
unfortunately saved a pointer to it in a local variable.
BUG=679643
Review-Url: https://codereview.chromium.org/2628233002
|
|
Widgets as returned from GetWidgets() can pop out of existence
unexpectedly, so always return observed pointers. This extends
the same pattern used elsewhere in the file to all occurrences.
BUG=679642
Review-Url: https://codereview.chromium.org/2624933002
|
|
BUG=pdfium:644
Review-Url: https://codereview.chromium.org/2581873002
|
|
BUG=pdfium:568
Review-Url: https://codereview.chromium.org/2519343002
|
|
BUG=pdfium:479
Review-Url: https://codereview.chromium.org/2521843003
|
|
BUG=chromium:667012
Review-Url: https://codereview.chromium.org/2508203007
|
|
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
|
|
This is a generic API function to retrieve any viewer preference of type
name.
BUG=pdfium:414
Review-Url: https://codereview.chromium.org/2475923003
|
|
The expectation is set incorrectly to allow the test to pass.
BUG=chromium:494057
Review-Url: https://codereview.chromium.org/2430583002
|
|
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
|
|
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
|
|
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
|
|
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
|
|
As per the PDF specification in [1], page 103, the
'info' property of the Document object is readonly.
[1] http://partners.adobe.com/public/developer/en/acrobat/sdk/5186AcroJS.pdf
Review-Url: https://codereview.chromium.org/2235883003
|
|
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
|
|
As per the PDF specification at [1]
"
This property specifies the document's URL.
".
IE/Acrobat supports it, and getting it implemented
would be one step forward in order to support Acrobat JS
script as the one in [2].
[1] http://partners.adobe.com/public/developer/en/acrobat/sdk/5186AcroJS.pdf
[2] https://bugs.chromium.org/p/pdfium/issues/detail?id=492
BUG=492
Review-Url: https://codereview.chromium.org/2219183002
|
|
Fix memory ownership model for PDFium timers.
The |app| class owns the CJS_Timer as part of its vector<unique_ptr>
to them.
The CJS_Timer "owns" its slot in the global ID to timer map, and
removes itself when it is destroyed. Nothing else deletes
from the global map. Deleting from the global map is
accompanied by a callback to the embedder to clear its
resources.
Next, the proper way to remove a CJS_Timer is by going
through the app, and having the app erase its unique ptr,
which then deletes the CJS_Timer, which in turn cleans up the
global map. Provide a CJS_Timer::Cancel static method to
do this conveniently.
There is a alternate path to the CJS_timer via JS and its
CJS_TimerObj. CJS_TimerObj owns a TimerObj that currently
points to the CJS_Timer. If the timer fires, and cleans
itself up, this can go stale.
Make the TimerObj maintain a weak reference via global
timer ID rather than a direct pointer to the CJS_Timer, so
that if the timer fires and is destroyed, future attempts
to cancel find nothing.
There is another path, where if the JS timer object is GC'd, then we
just clean up its CJS_TimerObj without touching
the actual CJS_Timers. We could make this match the spec
by calling into the new cancel routine as described above,
but it seems weird to have a timer depend on whether a gc
happened or not.
A subsequent CL will rename these objects to more closely
match the conventions used by the other JS wrappers.
BUG=634716
Review-Url: https://codereview.chromium.org/2221513002
|
|
We must look the timer up a second time since the callback
may have released it.
BUG=634394
Review-Url: https://codereview.chromium.org/2214003003
|