2014-07-25 06:19:17 +09:00
{
"type" : "object" ,
"properties" : {
2023-11-19 02:18:36 +09:00
"viewerCssTheme" : {
"title" : "Theme" ,
"description" : "The theme to use.\n0 = Use system theme.\n1 = Light theme.\n2 = Dark theme." ,
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ 0 , 1 , 2 ] ,
2023-11-19 02:18:36 +09:00
"default" : 2
} ,
2014-07-25 06:19:17 +09:00
"showPreviousViewOnLoad" : {
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"description" : "DEPRECATED. Set viewOnLoad to 1 to disable showing the last page/position on load." ,
2014-07-25 06:19:17 +09:00
"type" : "boolean" ,
"default" : true
} ,
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"viewOnLoad" : {
"title" : "View position on load" ,
"description" : "The position in the document upon load.\n -1 = Default (uses OpenAction if available, otherwise equal to `viewOnLoad = 0`).\n 0 = The last viewed page/position.\n 1 = The initial page/position." ,
2019-02-11 18:43:08 +09:00
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ -1 , 0 , 1 ] ,
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"default" : 0
} ,
2022-12-12 22:24:27 +09:00
"defaultZoomDelay" : {
"title" : "Default zoom delay" ,
"description" : "Delay (in ms) to wait before redrawing the canvas." ,
"type" : "integer" ,
"default" : 400
} ,
2014-07-25 06:19:17 +09:00
"defaultZoomValue" : {
"title" : "Default zoom level" ,
"description" : "Default zoom level of the viewer. Accepted values: 'auto', 'page-actual', 'page-width', 'page-height', 'page-fit', or a zoom level in percents." ,
"type" : "string" ,
"pattern" : "|auto|page-actual|page-width|page-height|page-fit|[0-9]+\\.?[0-9]*(,[0-9]+\\.?[0-9]*){0,2}" ,
"default" : ""
} ,
"sidebarViewOnLoad" : {
"title" : "Sidebar state on load" ,
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"description" : "Controls the state of the sidebar upon load.\n -1 = Default (uses PageMode if available, otherwise the last position if available/enabled).\n 0 = Do not show sidebar.\n 1 = Show thumbnails in sidebar.\n 2 = Show document outline in sidebar.\n 3 = Show attachments in sidebar." ,
2014-07-25 06:19:17 +09:00
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ -1 , 0 , 1 , 2 , 3 ] ,
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"default" : -1
2014-07-25 06:19:17 +09:00
} ,
2018-02-17 01:34:34 +09:00
"enableHandToolOnLoad" : {
"description" : "DEPRECATED. Set cursorToolOnLoad to 1 to enable the hand tool by default." ,
"type" : "boolean" ,
"default" : false
} ,
2016-09-07 20:30:26 +09:00
"cursorToolOnLoad" : {
"title" : "Cursor tool on load" ,
"description" : "The cursor tool that is enabled upon load.\n 0 = Text selection tool.\n 1 = Hand tool." ,
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ 0 , 1 ] ,
2016-09-07 20:30:26 +09:00
"default" : 0
} ,
2014-09-20 17:24:04 +09:00
"pdfBugEnabled" : {
"title" : "Enable debugging tools" ,
"description" : "Whether to enable debugging tools." ,
"type" : "boolean" ,
"default" : false
} ,
2021-09-12 08:04:11 +09:00
"enableScripting" : {
"title" : "Enable active content (JavaScript) in PDFs" ,
"type" : "boolean" ,
"description" : "Whether to allow execution of active content (JavaScript) by PDF files." ,
"default" : false
} ,
2023-11-23 03:02:42 +09:00
"enableHighlightEditor" : {
"type" : "boolean" ,
"default" : false
} ,
2023-12-01 00:21:13 +09:00
"highlightEditorColors" : {
"type" : "string" ,
"default" : "yellow=#FFFF98,green=#53FFBC,blue=#80EBFF,pink=#FFCBE6,red=#FF4F5F"
} ,
2014-07-25 06:19:17 +09:00
"disableRange" : {
"title" : "Disable range requests" ,
"description" : "Whether to disable range requests (not recommended)." ,
"type" : "boolean" ,
"default" : false
} ,
2014-09-06 10:02:54 +09:00
"disableStream" : {
"title" : "Disable streaming for requests" ,
"description" : "Whether to disable streaming for requests (not recommended)." ,
"type" : "boolean" ,
"default" : false
} ,
2014-07-25 06:19:17 +09:00
"disableAutoFetch" : {
"type" : "boolean" ,
"default" : false
} ,
"disableFontFace" : {
"title" : "Disable @font-face" ,
"description" : "Whether to disable @font-face and fall back to canvas rendering (this is more resource-intensive)." ,
"type" : "boolean" ,
"default" : false
} ,
[CRX] Make textLayerMode pref visible and add migration logic
In a1cfa5f4d7c8fcf55e9f3b51a23885dca8782915, the textLayerMode
preference was introduced, to replace the disableTextLayer and
enhanceTextSelection preferences.
As a result, the text selection preference was no longer visible
in Chrome (because preferences are only rendered by default for
boolean preferences, not for enumerations).
This commit adds the necessary bits to
extensions/chromium/options/options.{html,js}
so that the textLayerMode preference can be changed again.
Also, migration logic has been added to move over preferences
from the old to the new names:
- In web/chromecom.js, the logic is added to translate
preferences that were set by an administrator (it is read-only,
so this layer is unavoidable).
- In extensions/chromium/options/migration.js, similar logic is
added, except in this case the preference storage is writable,
so this migration logic happens only once.
The "enhanced text selection" mode is still experimental, so it
has been marked as experimental to signal that there may be bugs.
The list of tasks that block promotion to stable is at #7584.
2018-02-17 02:02:05 +09:00
"disableTextLayer" : {
"description" : "DEPRECATED. Set textLayerMode to 0 to disable the text selection layer by default." ,
"type" : "boolean" ,
"default" : false
} ,
2018-02-13 23:01:55 +09:00
"textLayerMode" : {
"title" : "Text layer mode" ,
2022-01-19 02:09:12 +09:00
"description" : "Controls if the text layer is enabled, and the selection mode that is used.\n 0 = Disabled.\n 1 = Enabled." ,
2018-02-13 23:01:55 +09:00
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ 0 , 1 ] ,
2018-02-13 23:01:55 +09:00
"default" : 1
2014-07-25 06:19:17 +09:00
} ,
2016-05-12 07:58:17 +09:00
"externalLinkTarget" : {
"title" : "External links target window" ,
"description" : "Controls how external links will be opened.\n 0 = default.\n 1 = replaces current window.\n 2 = new window/tab.\n 3 = parent.\n 4 = in top window." ,
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ 0 , 1 , 2 , 3 , 4 ] ,
2016-05-12 07:58:17 +09:00
"default" : 0
2016-05-29 23:44:50 +09:00
} ,
2016-01-23 21:56:56 +09:00
"disablePageLabels" : {
"type" : "boolean" ,
"default" : false
} ,
2017-07-19 23:26:17 +09:00
"disablePageMode" : {
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"description" : "DEPRECATED." ,
2017-07-19 23:26:17 +09:00
"type" : "boolean" ,
"default" : false
} ,
2016-05-29 23:44:50 +09:00
"disableTelemetry" : {
"title" : "Disable telemetry" ,
"type" : "boolean" ,
"description" : "Whether to prevent the extension from reporting the extension and browser version to the extension developers." ,
"default" : false
2016-09-07 05:26:57 +09:00
} ,
[api-minor] Introduce a new `annotationMode`-option, in `PDFPageProxy.{render, getOperatorList}`
*This is a follow-up to PRs 13867 and 13899.*
This patch is tagged `api-minor` for the following reasons:
- It replaces the `renderInteractiveForms`/`includeAnnotationStorage`-options, in the `PDFPageProxy.render`-method, with the single `annotationMode`-option that controls which annotations are being rendered and how. Note that the old options were mutually exclusive, and setting both to `true` would result in undefined behaviour.
- For improved consistency in the API, the `annotationMode`-option will also work together with the `PDFPageProxy.getOperatorList`-method.
- It's now also possible to disable *all* annotation rendering in both the API and the Viewer, since the other changes meant that this could now be supported with a single added line on the worker-thread[1]; fixes 7282.
---
[1] Please note that in order to simplify the overall implementation, we'll purposely only support disabling of *all* annotations and that the option is being shared between the API and the Viewer. For any more "specialized" use-cases, where e.g. only some annotation-types are being rendered and/or the API and Viewer render different sets of annotations, that'll have to be handled in third-party implementations/forks of the PDF.js code-base.
2021-08-08 21:36:28 +09:00
"annotationMode" : {
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ 0 , 1 , 2 , 3 ] ,
[api-minor] Introduce a new `annotationMode`-option, in `PDFPageProxy.{render, getOperatorList}`
*This is a follow-up to PRs 13867 and 13899.*
This patch is tagged `api-minor` for the following reasons:
- It replaces the `renderInteractiveForms`/`includeAnnotationStorage`-options, in the `PDFPageProxy.render`-method, with the single `annotationMode`-option that controls which annotations are being rendered and how. Note that the old options were mutually exclusive, and setting both to `true` would result in undefined behaviour.
- For improved consistency in the API, the `annotationMode`-option will also work together with the `PDFPageProxy.getOperatorList`-method.
- It's now also possible to disable *all* annotation rendering in both the API and the Viewer, since the other changes meant that this could now be supported with a single added line on the worker-thread[1]; fixes 7282.
---
[1] Please note that in order to simplify the overall implementation, we'll purposely only support disabling of *all* annotations and that the option is being shared between the API and the Viewer. For any more "specialized" use-cases, where e.g. only some annotation-types are being rendered and/or the API and Viewer render different sets of annotations, that'll have to be handled in third-party implementations/forks of the PDF.js code-base.
2021-08-08 21:36:28 +09:00
"default" : 2
2017-02-08 08:15:09 +09:00
} ,
2022-06-29 18:13:03 +09:00
"annotationEditorMode" : {
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ -1 , 0 , 3 , 15 ] ,
2022-08-21 20:48:48 +09:00
"default" : 0
2022-06-01 17:38:08 +09:00
} ,
Add a new `pdfjs.enablePermissions` preference, off by default, to allow the PDF documents to disable copying in the viewer (bug 792816)
*Please note:* Most of the necessary API work was done in PR 10033, and the only remaining thing to do here was to implement it in the viewer.
The new preference should thus allow e.g. enterprise users to disable copying in the viewer, for PDF documents whose permissions specify that.
In order to simplify things the "copy"-permission was implemented using CSS, as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=792816#c55, which should hopefully suffice.[1]
The advantage of this approach, as opposed to e.g. disabling the `textLayer` completely, is first of all that it ensures that searching still works correctly even in copy-protected documents. Secondly this also greatly simplifies the overall implementation, since it doesn't require a lot of code for something that's disabled by default.
---
[1] As the discussion in the bug shows, this kind of copy-protection is not very strong and is also generally easy to remove/circumvent in various ways. Hence a simple solution, targeting "regular"-users rather than "power"-users is hopefully deemed acceptable here.
2020-04-08 23:53:31 +09:00
"enablePermissions" : {
"type" : "boolean" ,
"default" : false
} ,
2021-05-07 21:37:47 +09:00
"enableXfa" : {
"type" : "boolean" ,
2021-09-08 19:33:59 +09:00
"default" : true
2021-05-07 21:37:47 +09:00
} ,
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" : {
"type" : "boolean" ,
"default" : false
} ,
2020-02-17 22:04:55 +09:00
"ignoreDestinationZoom" : {
"title" : "Ignore the zoom argument in destinations" ,
"description" : "When enabled it will maintain the currently active zoom level, rather than letting the PDF document modify it, when navigating to internal destinations." ,
"type" : "boolean" ,
"default" : false
} ,
2017-02-08 08:15:09 +09:00
"enablePrintAutoRotate" : {
"title" : "Automatically rotate printed pages" ,
2020-06-25 08:04:42 +09:00
"description" : "When enabled, landscape pages are rotated when printed." ,
2017-02-08 08:15:09 +09:00
"type" : "boolean" ,
2021-03-19 20:27:23 +09:00
"default" : true
2018-05-15 12:10:33 +09:00
} ,
"scrollModeOnLoad" : {
"title" : "Scroll mode on load" ,
2021-11-08 18:18:25 +09:00
"description" : "Controls how the viewer scrolls upon load.\n -1 = Default (uses the last position if available/enabled).\n 3 = Page scrolling.\n 0 = Vertical scrolling.\n 1 = Horizontal scrolling.\n 2 = Wrapped scrolling." ,
2018-05-15 12:10:33 +09:00
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ -1 , 0 , 1 , 2 , 3 ] ,
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"default" : -1
2018-05-15 12:10:33 +09:00
} ,
"spreadModeOnLoad" : {
"title" : "Spread mode on load" ,
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"description" : "Whether the viewer should join pages into spreads upon load.\n -1 = Default (uses the last position if available/enabled).\n 0 = No spreads.\n 1 = Odd spreads.\n 2 = Even spreads." ,
2018-05-15 12:10:33 +09:00
"type" : "integer" ,
2024-01-17 03:40:25 +09:00
"enum" : [ -1 , 0 , 1 , 2 ] ,
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history
The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
"default" : -1
2022-05-04 22:37:13 +09:00
} ,
2022-07-06 20:50:45 +09:00
"forcePageColors" : {
"description" : "When enabled, the pdf rendering will use the high contrast mode colors" ,
"type" : "boolean" ,
"default" : false
} ,
2022-05-08 17:51:59 +09:00
"pageColorsBackground" : {
2022-05-04 22:37:13 +09:00
"description" : "The color is a string as defined in CSS. Its goal is to help improve readability in high contrast mode" ,
"type" : "string" ,
"default" : "Canvas"
} ,
2022-05-08 17:51:59 +09:00
"pageColorsForeground" : {
2022-05-04 22:37:13 +09:00
"description" : "The color is a string as defined in CSS. Its goal is to help improve readability in high contrast mode" ,
"type" : "string" ,
"default" : "CanvasText"
2014-07-25 06:19:17 +09:00
}
}
}
