Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
dd4620530d
pdf.js/web/default_preferences.json

26 lines
652 B
JSON
Raw Normal View History

Moves DEFAULT_PREFENCES into JSON format.
2016-05-12 07:58:17 +09:00
{
"showPreviousViewOnLoad": true,
"defaultZoomValue": "",
"sidebarViewOnLoad": 0,
Unify handling of various cursor tools, e.g. the current Hand Tool and a possible future Zoom Tool, in a new `PDFCursorTools` module With the current way that the `HandTool` is implemented, if someone would try to also add a Zoom tool (as issue 1260 asks for) that probably wouldn't work very well given that you'd then have two cursor tools which may not play nice together. Hence this patch, which attempts to refactor things so that it should be simpler to add e.g. a Zoom tool as well (given that that issue is marked as "good-beginner-bug", and I'm not sure if that really applies considering the current state of the code). Note that I personally have no interest in implementing a Zoom tool (similar to Adobe Reader) since I wouldn't use it, but I figured that it can't hurt to make this code a bit more future proof.
2016-09-07 20:30:26 +09:00
"cursorToolOnLoad": 0,
Moves DEFAULT_PREFENCES into JSON format.
2016-05-12 07:58:17 +09:00
"enableWebGL": false,
Add general support for re-dispatching events, on `EventBus` instances, to the DOM This patch is the first step to be able to eventually get rid of the `attachDOMEventsToEventBus` function, by allowing `EventBus` instances to simply re-dispatch most[1] events to the DOM. Note that the re-dispatching is purposely implemented to occur *after* all registered `EventBus` listeners have been serviced, to prevent the ordering issues that necessitated the duplicated page/scale-change events. The DOM events are currently necessary for the `mozilla-central` tests, see https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/test, and perhaps also for custom deployments of the PDF.js default viewer. Once this have landed, and been successfully uplifted to `mozilla-central`, I intent to submit a patch to update the test-code to utilize the new preference. This will thus, eventually, make it possible to remove the `attachDOMEventsToEventBus` functionality. *Please note:* I've successfully ran all `mozilla-central` tests locally, with these patches applied. --- [1] The exception being events that originated on the `window` or `document`, since those are already globally available anyway.
2018-08-28 17:26:18 +09:00
"eventBusDispatchToDOM": false,
Moves DEFAULT_PREFENCES into JSON format.
2016-05-12 07:58:17 +09:00
"pdfBugEnabled": false,
"disableRange": false,
"disableStream": false,
"disableAutoFetch": false,
"disableFontFace": false,
Replace the `disableTextLayer` and `enhanceTextSelection` options/preferences with a single `textLayerMode` option/preference Rather than having two different (but connected) options for the textLayer, I think that it makes sense to try and unify this. For example: currently if `disableTextLayer === true`, then the value of `enhanceTextSelection` is simply ignored. Since PDF.js version `2.0` already won't be backwards compatible in lots of ways, I don't think that we need to worry about migrating existing preferences here.
2018-02-13 23:01:55 +09:00
"textLayerMode": 1,
Moves DEFAULT_PREFENCES into JSON format.
2016-05-12 07:58:17 +09:00
"useOnlyCssZoom": false,
Render interactive form (AcroForm) text widget annotations This patch is the first step towards implementing support for interactive forms (AcroForms). It makes it possible to render text widget annotations exactly like Adobe Reader/Acrobat. Everything we implement for AcroForms is disabled by default using a preference, mainly because it is not ready to use yet, but has to implemented in many steps to avoid complexity. The preference allows us to work with the code while not exposing the behavior by default. Mainly storing entered values and printing them is still absent, which would be minimal requirements for enabling this by default.
2016-09-07 05:26:57 +09:00
"externalLinkTarget": 0,
Adds SVG rendering capabilities to the PDFViewer.
2016-11-19 04:03:49 +09:00
"renderer": "canvas",
Add support for PageLabels in the viewer This patch implements the page label functionality in a similar way as Adobe Reader. For documents with page labels, if a non-existent page label is entered we'll try to fallback to the page number instead. The patch also includes a preference (`disablePageLabels`), to make it easy to opt-out of using page labels if the user/implementor so wishes. The way that `get/set currentPageLabel` is implemented in `PDFViewer`, is as wrappers for the corresponding `get/set currentPageNumber` functions, since that seemed like the cleanest solution. The page labels are purposely *only* added to the page controls in the viewer UI, and not stored in e.g. the `ViewHistory`. Since doing so would mean adding unnecessary code complexity, without any real added value, and would also mean delaying the inital loading of PDF documents. Note that this patch will ignore page labels if they are identical to standard page numbering, since in this case displaying the page labels adds no value (but only UI noise). The reason for handling this case specially, is that in practice a surprising number of PDF files include "pointless" page labels.
2016-01-23 21:56:56 +09:00
"renderInteractiveForms": false,
Allow automatic print rotation via enablePrintAutoRotate
2017-02-08 08:15:09 +09:00
"enablePrintAutoRotate": false,
Add OpenAction destination support, off by default, to the viewer Given that it's really not clear to me if this is actually desired functionality in the default viewer, and considering that it doesn't fit in *great* with the way that `PDFHistory` is initialized, this feature is currently off by default[1]. --- [1] It's controlled with the `disableOpenActionDestination` Preference/AppOption.
2018-12-07 02:32:41 +09:00
"disableOpenActionDestination": true,
Add support for, the API property, PageMode in the viewer (issue 8657) Note that the PageMode, as specified in the API, will only be honoured when either: the user hasn't set the `sidebarViewOnLoad` preference to a non-default value, or a non-default `sidebarView` entry doesn't exist in the view history, or the "pagemode" hash parameter is included in the URL. Since this is new functionality, the patch also includes a preference (`disablePageMode`), to make it easy to opt-out of this functionality if the user/implementor so wishes.
2017-07-19 23:26:17 +09:00
"disablePageMode": false,
Add preferences for default scroll/spread modes This commit adds `scrollModeOnLoad` and `spreadModeOnLoad` preferences that control the default viewer state when opening a new document for the first time. This commit also contains a minor refactoring of some of the option UI rendering code in extensions/chromium/options/options.js, as I couldn't bear creating two more functions nearly identical to the four that already existed.
2018-05-15 12:10:33 +09:00
"disablePageLabels": false,
Add support for updating the document hash, off by default, when the browser history is updated (issue 5753) This is *really* the best that we can do here, since other proposed solutions would interfere with (and break) the painstakingly implemented browsing history that's present in the default viewer. I'm still not convinced that this is a good idea in general, but this patch implements it in a way where it is possible to toggle[1] for users that wish to have this feature. In particular, there's a couple of reasons why I'm not finding this feature necessary/great: - It's already possible to easily obtain the current hash, by simply clicking on the `viewBookmark` button at any time. - Hash changes requires a bit of special handling[2], i.e. extra code, to prevent issues when the browser history is traversed (see `PDFHistory._popState`). Currently this is only necessary when the user has manually changed the hash, with this patch it will always be the case (assuming the feature is active). - It's not always possible to change the URL when updating the browser history. For example: In the Firefox built-in viewer, the URL cannot be modified for local files (i.e. those using the `file://` protocol). This leads to inconsistent behaviour, and may in some cases even result in errors being thrown and the history thus not updating, if the browser prevents changes to the URL during `pushState`/`replaceState` calls. --- [1] Using the `historyUpdateUrl` viewer preference. [2] This depends, to a great extent, on browsers always firing `popstate` events *before* `hashchange` events, which may or may not actually be guaranteed.
2019-01-03 23:45:33 +09:00
"historyUpdateUrl": false,
Add preferences for default scroll/spread modes This commit adds `scrollModeOnLoad` and `spreadModeOnLoad` preferences that control the default viewer state when opening a new document for the first time. This commit also contains a minor refactoring of some of the option UI rendering code in extensions/chromium/options/options.js, as I couldn't bear creating two more functions nearly identical to the four that already existed.
2018-05-15 12:10:33 +09:00
"scrollModeOnLoad": 0,
"spreadModeOnLoad": 0
Revert "Add a `enhanceTextSelection` preference to the viewer" This reverts commit 15e45d772f181e735713dcf077d03e2fc87e3a45.
2016-09-04 03:26:46 +09:00
}
Reference in New Issue Copy Permalink