pdf.js/test
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
..
features Uses editorconfig to maintain consistent coding styles 2015-11-14 07:32:18 +05:30
font Updates Jasmine version. 2016-03-29 09:34:13 -05:00
pdfs Attempt to combine text runs positioned with setTextMatrix 2016-05-18 17:21:58 +02:00
resources Remove 'use strict'; causing failure and unused prefs. 2016-01-14 13:23:48 -08:00
stats cleaned whitespace 2015-02-17 11:07:37 -05:00
ttx Update fonttools location and version (issue 6223) 2015-07-17 12:51:09 +02:00
unit [api-minor] Let LinkAnnotation/PDFLinkService_getDestinationHash return a stringified version of the destination array for explicit destinations 2016-05-21 14:14:07 +02:00
.gitignore Ignore test snapshots directory. 2013-03-15 11:24:08 -07:00
annotation_layer_test.css Merge pull request #6807 from timvandermeij/popup-annotation-hidden 2015-12-28 22:58:41 +01:00
downloadutils.js Uses editorconfig to maintain consistent coding styles 2015-11-14 07:32:18 +05:30
driver.js Remove combineUrl and replace it with new URL. 2016-04-15 21:33:10 +05:30
test_manifest.json Attempt to combine text runs positioned with setTextMatrix 2016-05-18 17:21:58 +02:00
test_slave.html Move all PDFJS.xxx settings into display/global. 2016-04-07 13:46:07 -05:00
test.js Allow unit-tests to use linked PDF files, by having the unittest command download unavailable ones (issue 7117) 2016-03-27 13:17:55 +02:00
testutils.js Uses editorconfig to maintain consistent coding styles 2015-11-14 07:32:18 +05:30
text_layer_test.css Better "text" testing. 2015-11-19 11:03:52 -06:00
webbrowser.js Uses editorconfig to maintain consistent coding styles 2015-11-14 07:32:18 +05:30
webserver.js Uses editorconfig to maintain consistent coding styles 2015-11-14 07:32:18 +05:30