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

23 lines
572 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,
"enableHandToolOnLoad": false,
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,
"pdfBugEnabled": false,
"disableRange": false,
"disableStream": false,
"disableAutoFetch": false,
"disableFontFace": false,
"disableTextLayer": false,
"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,
Add a `enhanceTextSelection` preference Please note that this is a hack, but I think that it should be OK for now to atleast get the preference landed. Refer to the code comment for further information. Re: issue 7584 and PR 7586.
2016-09-07 21:52:52 +09:00
"enhanceTextSelection": false,
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 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 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
"disablePageLabels": false
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