akira/pdfjs-dist - pdfjs-dist - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
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.	9 years ago
Jonas Jenwald	2b79782377	[api-minor] Add basic support for `Launch` actions (issue 1778, issue 3897, issue 6616) In general we neither want, nor can, support arbitrary `Launch` actions. But in practice, all the cases we've seen so far just contains relative URLs to other PDF files. Building on PR 7689, we can thus at least support basic `Launch` actions.	9 years ago
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.	9 years ago
Jonas Jenwald	42f07c6262	[api-minor] Use the `new URL` constructor when validating URLs in annotations and the outline, as a complement to only checking the protocol, and add a bit more validation to `Catalog_parseDestDictionary` Note that this will automatically reject any relative URL. To make the API more useful to consumers, URLs that are rejected will be available via the `unsafeUrl` property in the data object returned by `PDFPageProxy_getAnnotations`. The patch also adds a bit more validation of the data for `Named` actions.	9 years ago
Tim van der Meij	f85f3243b1	Choice widget annotations: unit and reference testing	9 years ago
Jonas Jenwald	93830032ac	Add a unit-test for annotations where the `URI` action has an incorrect encoding (bug 1122280, PR 5999)	9 years ago
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.	9 years ago
Tim van der Meij	6100ab4b18	Text widget annotations: implement comb support	9 years ago
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.	9 years ago
Tim van der Meij	323e86c442	Text widget annotations: implement unit testing and sanitize data values	9 years ago
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.	9 years ago
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.	9 years ago
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.	9 years ago
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	9 years ago
Jonas Jenwald	171f908b89	Add a couple of `LinkAnnotation` unit-tests We currently don't have any unit-tests for `LinkAnnotation`s, so it seemed a good idea to add a few. These tests are taken from various actual PDF files.	9 years ago
Prakash Palanisamy	a25c29d98d	Remove `combineUrl` and replace it with `new URL`.	9 years ago
Yury Delendik	0a700fa29d	Updates Jasmine version.	9 years ago
Tim van der Meij	10902fd882	Implement unit and reference testing for FileAttachment annotations	9 years ago
Tim van der Meij	0991c06395	Refactor annotation flags code This patch makes it possible to set and get all possible flags that the PDF specification defines. Even though we do not support all possible annotation types and not all possible annotation flags yet, this general framework makes it easy to access all flags for each annotation such that annotation type implementations can use this information. We add constants for all possible annotation flags such that we do not need to hardcode the flags in the code anymore. The `isViewable()` and `isPrintable()` methods are now easier to read. Additionally, unit tests have been added to ensure correct behavior. This is another part of #5218.	10 years ago
Manas	a2ba1b8189	Uses editorconfig to maintain consistent coding styles Removes the following as they unnecessary /* -- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -- / / vim: set shiftwidth=2 tabstop=2 autoindent cindent expandtab: */	10 years ago
Tim van der Meij	980aa10e04	Refactor annotation rectangle code and add unit tests This patch refactors the code responsible for setting the annotation's rectangle. Its goal is to: - Actually check that the input array is actually an array, and if so, that it contains exactly four elements. - Only call `normalizeRect` if the input array is valid, i.e., we do not call it for the default rectangle anymore. Unit tests are provided just like with the other patches in this series.	10 years ago
Tim van der Meij	465611a2ff	More cleanup regarding annotation border styles	10 years ago
Tim van der Meij	a2e9845093	Refactor annotation color handling and add unit tests	10 years ago
Tim van der Meij	6007a57291	Add tests and documentation for the annotation border style class This patch adds: - Unit tests for the annotation border style class - Regression test (self-made) for the annotation border style class - Documentation generation using JSDoc	10 years ago