mirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/mozilla/pdf.js.git synced 2025-04-26 01:58:06 +02:00
Code Activity
10092 commits 1 branch 93 tags 290 MiB
Commit graph

89 commits

Author SHA1 Message Date
Tim van der Meij
24d741d045
Convert src/core/annotation.js to ES6 syntax 2017-08-27 00:53:45 +02:00
Jonas Jenwald
3a20fd165f Refactor ObjectLoader to use Dicts correctly, rather than abusing their internal properties 
The `ObjectLoader` currently takes an Object as input, despite actually working with `Dict`s internally. This means that at the (two) existing call-sites, we're passing in the "private" `Dict.map` property directly.

Doing this seems like an anti-pattern, and we could (and even should) simply provide the actual `Dict` when creating an `ObjectLoader` instance.
Accessing properties stored in the `Dict` is now done using the intended methods instead, in particular `getRaw` which (as the name suggests) doesn't do any de-referencing, thus maintaining the current functionality of the code.

The only functional change in this patch is that `ObjectLoader.load` will now ignore empty nodes, such that `ObjectLoader._walk` only needs to deal with nodes that are known to contain data. (This lets us skip, among other checks, meaningless `addChildren` function calls.)
 2017-06-16 22:59:32 +02:00
Jonas Jenwald
a8c87f8019 Fix inconsistent spacing and trailing commas in objects in src/core/ files, so we can enable the comma-dangle and object-curly-spacing ESLint rules later on 
*Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.*

http://eslint.org/docs/rules/comma-dangle
http://eslint.org/docs/rules/object-curly-spacing

Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead.

Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch.

```diff
diff --git a/src/core/evaluator.js b/src/core/evaluator.js
index abab9027..dcd3594b 100644
--- a/src/core/evaluator.js
+++ b/src/core/evaluator.js
@@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() {
     t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, };
     t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, };
     t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, };
-    t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, };
+    t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1,
+                variableArgs: false, };
     t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, };
     t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, };
     t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, };
diff --git a/src/core/jbig2.js b/src/core/jbig2.js
index 5a17d482..71671541 100644
--- a/src/core/jbig2.js
+++ b/src/core/jbig2.js
@@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() {
      { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, },
      { x: -1, y: 0, }],
     [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, },
-     { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }]
+     { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, },
+     { x: -1, y: 0, }]
   ];

   var RefinementTemplates = [
     {
       coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }],
-      reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, },
-                  { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }],
+      reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, },
+                  { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, },
+                  { x: 0, y: 1, }, { x: 1, y: 1, }],
     },
     {
-      coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }],
-      reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, },
-                  { x: 0, y: 1, }, { x: 1, y: 1, }],
+      coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, },
+               { x: -1, y: 0, }],
+      reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, },
+                  { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }],
     }
   ];
```
 2017-06-02 11:20:19 +02:00
Jonas Jenwald
982b6aa65b Convert the files in the /src/core folder to ES6 modules 
Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
 2017-05-30 22:06:21 +02:00
Jonas Jenwald
3e20d30afc Change the signatures of the PartialEvaluator "constructor" and its getOperatorList/getTextContent methods to take parameter objects 
Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors.
Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones.
Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience).

Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome.

With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test.

*Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat.

---

[1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
 2017-05-03 12:10:20 +02:00
Jonas Jenwald
ebaa22478c Replace unnecessary bind(this) and var self = this statements with arrow functions in remaining src/core/ files 2017-05-02 15:47:43 +02:00
Jonas Jenwald
afc74b0178 Enable the object-shorthand ESLint rule in src/shared 
Please see http://eslint.org/docs/rules/object-shorthand.

For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
 2017-04-27 17:29:40 +02:00
Yury Delendik
c4c44c1bbe Merge pull request #8240 from Snuffleupagus/api-stopAtErrors 
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815)
 2017-04-13 10:58:49 -05:00
Tim van der Meij
e15a2ec523
Annotations: implement support for line annotations 
This patch implements support for line annotations. Other viewers only
show the popup annotation when hovering over the line, which may have
any orientation. To make this possible, we render an invisible line (SVG
element) over the line on the canvas that acts as the trigger for the
popup annotation. This invisible line has the same starting coordinates,
ending coordinates and width of the line on the canvas.
 2017-04-12 23:05:25 +02:00
Jonas Jenwald
a39d636eb8 [api-minor] Always allow e.g. rendering to continue even if there are errors, and add a stopAtErrors parameter to getDocument to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) 
Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present.
Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead.

NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully.
In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`.

Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
 2017-04-11 08:59:22 +02:00
Tim van der Meij
30d63b0c50
Annotations: move container border removal to the display layer 
The display layer is responsible for creating the HTML elements for the
annotations from the core layer. If we need to ignore border styling for
the containers of certain elements, the display layer should do so and
not the core layer. I noticed this during the implementation of line
annotations, for which we actually need the original border width in the
display layer, even though we ignore it for the container. If we set the
border style to zero in the core layer, this becomes impossible.

To prevent this, this patch moves the container border removal code from
the core layer to the display layer. This makes the core layer output
the unchanged annotation data and lets the display layer remove any
border styling if necessary.
 2017-04-09 19:01:38 +02:00
Tim van der Meij
936d3c0698
Widget annotations: do not crash if Parent is not a dictionary 
during field name construction (issue 8143)
 2017-03-09 23:51:52 +01:00
Tim van der Meij
4e201d3787 Merge pull request #8072 from timvandermeij/annotation-append-operator-list 
Annotations: move operator list addition logic to `src/core/document.js`
 2017-02-27 22:50:57 +01:00
Tim van der Meij
0739f90707
Annotations: move operator list addition logic to src/core/document.js 
Ideally, the `Annotation` class should not have anything to do with the
page's operator list. How annotations are added to the page's operator
list is logic that belongs in `src/core/document.js` instead where the
operator list is constructed.

Moreover, some comments have been added to clarify the intent of the
code.
 2017-02-27 22:17:49 +01:00
Tim van der Meij
9db4240b85 Merge pull request #8110 from timvandermeij/interactive-forms-choice-inherit-options 
Interactive forms: make choice widget options inheritable (issue 8094)
 2017-02-27 22:14:25 +01:00
Tim van der Meij
8990de8614
Interactive forms: make choice widget options inheritable (issue 8094) 
Even though the PDF specification does not state that `Opt` fields are
inheritable, in practice there are PDF generators that let annotations
inherit the options from a parent.
 2017-02-25 23:34:26 +01:00
Tim van der Meij
26fc79d51d
Annotations: refactor setting the normal appearance stream 
Previously, we had a function called `getDefaultAppearance`. This name,
however, is misleading as the method gets the normal appearance (in the
`N` entry) and not the default appearance (in the `DA` entry). Moreover,
it was not entirely clear how it works just from reading the code. It
primarily lacks comments and explicit error case handling.

This patch improves the situation by fixing the issues mentioned above
and making this function a proper method of the `Annotation` class, just
like e.g., `setColor` and `setBorderStyle`.
 2017-02-15 22:42:17 +01:00
vkuryakov
4e181e59ef Interactive forms: values for radio buttons (issue #6995) 2017-02-07 23:42:40 +01:00
Jonas Jenwald
52e0f51917 Enable the no-unused-vars ESLint rule 
Please see http://eslint.org/docs/rules/no-unused-vars; note that this patch purposely uses the same rule options as in `mozilla-central`, such that it fixes part of issue 7957.

It wasn't, in my opinion, entirely straightforward to enable this rule compared to the already existing rules. In many cases a `var descriptiveName = ...` format was used (more or less) to document the code, and I choose to place the old variable name in a trailing comment to not lose that information.

I welcome feedback on these changes, since it wasn't always entirely easy to know what changes made the most sense in every situation.
 2017-01-29 23:23:17 +01:00
Jonas Jenwald
642d8621ef Replace direct lookup of uniquePrefix/idCounters, in Page instances, with an idFactory containing an createObjId method instead 
We're currently making use of `uniquePrefix`/`idCounters` in multiple files, to create unique object id's, and adding a new occurrence of them requires some care to ensure that an object id isn't accidentally reused.
Furthermore, having to pass around multiple parameters as we currently do seem like something you want to avoid.

Instead, this patch adds a factory which means that there's only *one* thing that needs to be passed around. And since it's now only necessary to call a method in order to obtain a unique object id, the details are thus abstracted away at the call-sites which avoids accidental reuse of object id's.

To test that this works as expected a very simple `Page` unit-test is added, and the existing `Annotation layer` tests are also adjusted slightly.
 2017-01-09 23:16:25 +01:00
Tim van der Meij
a428899b3c Button widget annotations: improve unit tests, simplify code and remove labels 
Modern browsers support styling radio buttons and checkboxes with CSS.
This makes the implementation much easier, and the fallback for older
browsers is still decent.
 2016-12-17 20:38:48 +01:00
Tim van der Meij
77148c7880 Button widget annotations: implement radio button value fetching according to the specification 2016-12-17 20:34:32 +01:00
benweet
ba012c7a68 Button widget annotations: implement checkboxes and radio buttons 2016-12-17 20:31:30 +01:00
Jonas Jenwald
bd91f34513 Ensure that we handle indirect objects in all types of Opt entries in ChoiceWidget annotation dictionaries 
I haven't got an example where the current code breaks, but given all the previous cases we've seen where PDF generators use indirect objects in Arrays it makes sense to fix this pro-actively.
I've modified the relevant unit-tests slightly, and they would *not* pass without the code changes in this patch.

*Note:* `Dict_getArray` only dereferences Array elements on the "top-level", to avoid recursion issues. Furthermore if you have to loop through the Array at the call-site anyway, then using `Dict_get` in combination with `XRef_fetchIfRef` is a tiny bit more efficient.
 2016-12-17 13:44:20 +01:00
Jonas Jenwald
ad915f8af1 Fix errors reported by the comma-spacing ESLint rule 
http://eslint.org/docs/rules/comma-spacing
 2016-12-12 20:35:53 +01:00
Tim van der Meij
1d96854019 Widget annotation: implement field name according to the specification 
The original code is difficult to read and, more importantly, performs
actions that are not described in the specification. It replaces empty
names with a backtick and an index, but this behavior is not described
in the specification. While the specification is not entirely clear
about what should happen in this case, it does specify that the `T`
field is optional and that multiple field dictionaries may have the same
fully qualified name, so to achieve this it makes the most sense to
ignore missing `T` fields during construction of the field name. This is
the most specification-compliant solution and, judging by opened issue #6623, also the required and expected behavior.
 2016-11-02 21:44:44 +01:00
Jonas Jenwald
d284cfd5eb [api-minor] Add support for relative URLs, in both annotations and the outline, by adding a docBaseUrl parameter to PDFJS.getDocument (bug 766086) 
Note that in `FIREFOX/MOZCENTRAL/CHROME` builds of the standard viewer the `docBaseUrl` parameter will be set by default, since in that case it makes sense to use the current URL as a base.
For the `GENERIC` viewer, or the API itself, it doesn't make sense to try and set the `docBaseUrl` by default. However, custom deployments/implementations may still find the parameter useful.
 2016-10-19 22:20:24 +02:00
Jonas Jenwald
e64bc1fd13 Move parsing of destination dictionaries to a helper function 
This not only reduces code duplication, but it also allow us to easily support the same kind of URLs we currently do for Link annotations in the Outline as well.
 2016-10-18 16:14:07 +02:00
Tim van der Meij
d5d9f362aa Choice widget annotations: core and display layer implementation 2016-10-05 21:25:29 +02:00
Jonas Jenwald
6c263c1994 Merge pull request #7649 from timvandermeij/interactive-forms-tx-comb 
Text widget annotations: implement comb support
 2016-09-22 11:36:30 +02:00
Tim van der Meij
375229d6b9 Widget annotations: simplify field flag handling 
Directly use the hexadecimal representation, just like the
`AnnotationFlags`, to avoid calculations and to improve readability.
This allows us to simplify the unit tests for text widget annotations as
well.
 2016-09-21 21:11:37 +02:00
Jonas Jenwald
ded01356c7 Pass in the renderInteractiveForms parameter to Annotation_appendToOperatorList, in Page_getOperatorList, instead of to the Annotation constructor (PR 7633 follow-up) 
When debugging issue 7643, I noticed that the `forms` tests currently doesn't look like the rendering in the viewer (with `renderInteractiveForms = true` set).
After scratching my head for a little while, I realized that PR 7633 make the implicit assumption that `Page_getOperatorList` (in `core/document.js`) is called *before* fetching the annotation with `PDFPageProxy_getAnnotations` (in `display/api.js`).

Hence this patch, that changes it so that we instead pass in the `renderInteractiveForms` parameter to `Annotation_appendToOperatorList` to ensure that it's always correctly set.
 2016-09-21 12:21:20 +02:00
Tim van der Meij
6100ab4b18 Text widget annotations: implement comb support 2016-09-20 22:31:10 +02:00
Tim van der Meij
dbea302a6e Text widget annotations: do not render on canvas as well 
If interactive forms are enabled, then the display layer takes care of
rendering the form elements. There is no need to draw them on the canvas
as well. This also leads to issues when values are prefilled, because
the text fields are transparent, so the contents that have been rendered
onto the canvas will be visible too.

We address this issue by passing the `renderInteractiveForms` parameter
to the render task and handling it when the page is rendered (i.e., when
the canvas is rendered).
 2016-09-17 15:24:48 +02:00
Tim van der Meij
adf0972ca5 Text widget annotations: improve unit and reference tests 
This patch improves the unit tests by testing the support for read-only
and multiline fields. Moreover, we add a reference test to ensure that
the text widgets are not only rendered, but also that their contents are
styled properly.

Finally, we perform minor improvements in `src/core/annotation.js`, for
example adding missing comments.
 2016-09-17 15:24:48 +02:00
Tim van der Meij
f6965fadc0 Text widget annotations: support multiline and read-only fields 
Moreover, this patch provides us with a framework for handling field
flags in general for all types of widget annotations.
 2016-09-17 15:24:47 +02:00
Tim van der Meij
323e86c442 Text widget annotations: implement unit testing and sanitize data values 2016-09-13 14:57:11 +02:00
Tim van der Meij
576f742047 Improve the structure for widget annotations 
Currently, we only support text widget annotations (field type 'Tx')
partially. However, the current code does not make this entirely clear
and does not provide a warning when an unsupported field type is
encountered, making it harder to determine why rendering fails.

Moreover, in the display layer we make no distinction between the
various types of widget annotations, causing the code for text widget
annotations to also be executed for other types of widget annotations in
a fallback situation.

This patch improves the structure of the widget annotation code. In the
core layer, we use the same structure we use for non-widget annotations
in the factory and provide a clear warning when an unsupported type is
encountered. In the display layer, we do the same and split the
`WidgetAnnotationElement` class into two classes, namely
`TextWidgetAnnotationElement` for text widget annotations and
`WidgetAnnotationElement` for other unsupported annotations as a
fallback. From this it clear that we only support text widget
annotations and nothing else.
 2016-09-06 00:26:05 +02:00
Jonas Jenwald
78889646c8 Create a fallback annotation id for entries in Annots dictionaries that are not indirect objects (issue 7569) 
According to the PDF specification, see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#page=86, entries in `Annots` dictionaries should be indirect objects, but obviously there're PDF generators that ignore this.

Fixes 7569.
 2016-08-27 10:56:16 +02:00
Jonas Jenwald
83ce6f0b6d Adjust the (applicable) existing isName callsites to use the new isName(v, name) version of the function 2016-08-10 11:15:08 +02:00
Jonas Jenwald
558a22cd02 Prevent errors when parsing Annotations with missing (or invalid) /Subtype entries (issue 7446) 
Note that I used a separate warning message for this case, instead of utilizing the same one as in the unsupported subtype case, to more clearly indicate that the PDF file itself is to blame rather than PDF.js.

Fixes 7446.
 2016-07-25 13:59:26 +02:00
Simon Cornelius P. Umacob
d872fc90b9 Expose the text widget's maximum length. 2016-06-29 17:04:33 +08:00
Tim van der Meij
f97d52182a Merge pull request #7341 from Snuffleupagus/getDestinationHash-Array 
[api-minor] Improve handling of links that are using explicit destination arrays
 2016-06-09 00:29:10 +02:00
Jonas Jenwald
98fe094d18 Let non-viewable Popup Annotations inherit the parent's Annotation Flags if the parent is viewable 
Fixes http://www.pdf-archive.com/2013/09/30/file2/file2.pdf.

Note how it's not possible to show the various Popup Annotations in the above document.
To fix that, this patch lets the Popup inherit the flags of the parent, in the special case where the parent is `viewable` *and* the Popup is not.
In general, I don't think that a Popup must have the same flags set as the parent. However, it seems very strange to have a `viewable` parent annotation, and then not being able to view the Popup.

Annoyingly the PDF specification doesn't, as far as I can find, mention anything about how this case should be handled, but this patch seem consistent with the actual behaviour in Adobe Reader.
 2016-05-25 23:00:26 +02:00
Jonas Jenwald
b354682dd6 [api-minor] Let LinkAnnotation/PDFLinkService_getDestinationHash return a stringified version of the destination array for explicit destinations 
Currently for explicit destinations, compared to named destinations, we manually try to build a hash that often times is a quite poor representation of the *actual* destination. (Currently this only, kind of, works for `\XYZ` destinations.)
For PDF files using explicit destinations, this can make it difficult/impossible to obtain a link to a specific section of the document through the URL.

Note that in practice most PDF files, especially newer ones, use named destinations and these are thus unnaffected by this patch.
This patch also fixes an existing issue in `PDFLinkService_getDestinationHash`, where a named destination consisting of only a number would not be handled correctly.

With the added, and already existing, type checks in place for destinations, I really don't think that this patch exposes any "sensitive" internal destination code not already accessible through normal hash parameters.

*Please note:* Just trying to improve the algorithm that generates the hash is unfortunately not possible in general, since there are a number of cases where it will simply never work well.

 - First of all, note that `getDestinationHash` currently relies on the `_pagesRefCache`, hence it's possible that the hash returned is empty during e.g. ranged/streamed loading of a PDF file.

 - Second of all, the currently computed hash is actually dependent on the document rotation. With named destinations, the fetched internal destination array is rotational invariant (as it should be), but this will not hold in general for the hash. We can easily avoid this issue by using a stringified destination array.

 - Third of all, note that according to the PDF specification[1], `GoToR` destinations may actually contain explicit destination arrays. Since we cannot really construct a hash in `annotation.js`, we currently have no good way to support those. Even though this case seems *very* rare in practice (I've not actually seen such a PDF file), it's in the specification, and this patch allows us to support that for "free".

---
[1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.1951685
 2016-05-21 14:14:07 +02:00
Jonas Jenwald
6111c17c8a Use Dict_getArray in more places in src/core/ to avoid issues when Arrays contain indirect objects 
As evident from e.g. PRs 6485 and 7118, some bad PDF generators unfortunately create Arrays where *some* elements are indirect objects (i.e. `Ref`s). This seems to mostly affect Arrays that contain numbers, such as e.g. `Matrix/FontMatrix/BBox/FontBBox/Rect/Color/...`, and has manifested itself in PDF files that fail to render correctly (some elements are missing).

The problem in both the cases above, besides broken rendering, was that there were *no* errors/warnings that indicated what the problem was, making it difficult to pinpoint the issue.
Hence this patch, where I've audited all usages of `Dict_get` in `src/core/` files, and replaced it with `Dict_getArray` where appropriate to try and prevent unnecessary future bugs.
 2016-05-05 19:42:57 +02:00
Jonas Jenwald
f3f825cc71 Various improvements for GoToR actions 
- Add support for the 'NewWindow' property.

 - Ensure that destinations are applied to the *remote* document, instead of the current one.

 - Handle the `F` entry being a standard string, instead of a dictionary.
 2016-04-15 22:55:05 +02:00
Jonas Jenwald
b63ef7a8b6 Refactor LinkAnnotation slightly to add data.url/data.dest at the end 
This patch also makes sure that all URLs are converted to the correct encoding.
 2016-04-15 22:55:05 +02:00
Jonas Jenwald
13d7a5070e Prevent failures in the Annotation code if the Rect array contains indirect objects (issue 7115) 
Note that in the PDF files provided by the reporter, this issue was limited to `Rect` arrays in AcroForm entries (which we currently don't support).
However, since a bad PDF generator could create this problem in *any* kind of annotation, the reduced test-case included here uses a simple LinkAnnotation instead.

Fixes 7115.
 2016-03-26 20:55:16 +01:00
Tim van der Meij
ad31e52a26 Group popup creation code and apply it to more annotation types 2016-02-25 00:35:45 +01:00