2014-09-13 11:27:45 +09:00
|
|
|
/* Copyright 2014 Mozilla Foundation
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
2021-12-15 07:59:17 +09:00
|
|
|
/** @typedef {import("../src/display/api").PDFDocumentProxy} PDFDocumentProxy */
|
|
|
|
/** @typedef {import("../src/display/api").PDFPageProxy} PDFPageProxy */
|
|
|
|
// eslint-disable-next-line max-len
|
|
|
|
/** @typedef {import("../src/display/display_utils").PageViewport} PageViewport */
|
2022-09-04 16:57:59 +09:00
|
|
|
// eslint-disable-next-line max-len
|
|
|
|
/** @typedef {import("../src/display/optional_content_config").OptionalContentConfig} OptionalContentConfig */
|
2021-12-15 21:54:29 +09:00
|
|
|
/** @typedef {import("./event_utils").EventBus} EventBus */
|
2021-12-15 07:59:17 +09:00
|
|
|
/** @typedef {import("./interfaces").IDownloadManager} IDownloadManager */
|
|
|
|
/** @typedef {import("./interfaces").IL10n} IL10n */
|
|
|
|
/** @typedef {import("./interfaces").IPDFLinkService} IPDFLinkService */
|
|
|
|
|
2017-03-28 08:07:27 +09:00
|
|
|
import {
|
2022-06-01 17:38:08 +09:00
|
|
|
AnnotationEditorType,
|
|
|
|
AnnotationEditorUIManager,
|
2021-09-20 17:10:57 +09:00
|
|
|
AnnotationMode,
|
|
|
|
createPromiseCapability,
|
2021-12-12 00:23:29 +09:00
|
|
|
PermissionFlag,
|
2021-09-20 17:10:57 +09:00
|
|
|
PixelsPerInch,
|
|
|
|
version,
|
|
|
|
} from "pdfjs-lib";
|
|
|
|
import {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
DEFAULT_SCALE,
|
2021-09-19 18:54:57 +09:00
|
|
|
DEFAULT_SCALE_DELTA,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
DEFAULT_SCALE_VALUE,
|
2022-05-23 01:00:57 +09:00
|
|
|
docStyle,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
getVisibleElements,
|
|
|
|
isPortraitOrientation,
|
|
|
|
isValidRotation,
|
|
|
|
isValidScrollMode,
|
|
|
|
isValidSpreadMode,
|
|
|
|
MAX_AUTO_SCALE,
|
2021-09-19 18:54:57 +09:00
|
|
|
MAX_SCALE,
|
|
|
|
MIN_SCALE,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
PresentationModeState,
|
|
|
|
RendererType,
|
2021-12-15 21:54:29 +09:00
|
|
|
RenderingStates,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
SCROLLBAR_PADDING,
|
|
|
|
scrollIntoView,
|
|
|
|
ScrollMode,
|
|
|
|
SpreadMode,
|
|
|
|
TextLayerMode,
|
|
|
|
UNKNOWN_SCALE,
|
|
|
|
VERTICAL_PADDING,
|
|
|
|
watchScroll,
|
2020-01-02 20:00:16 +09:00
|
|
|
} from "./ui_utils.js";
|
2021-02-22 20:43:16 +09:00
|
|
|
import { NullL10n } from "./l10n_utils.js";
|
2020-01-02 20:00:16 +09:00
|
|
|
import { PDFPageView } from "./pdf_page_view.js";
|
2021-12-15 21:54:29 +09:00
|
|
|
import { PDFRenderingQueue } from "./pdf_rendering_queue.js";
|
2020-01-02 20:00:16 +09:00
|
|
|
import { SimpleLinkService } from "./pdf_link_service.js";
|
2016-04-09 02:34:27 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
const DEFAULT_CACHE_SIZE = 10;
|
2021-12-12 00:23:29 +09:00
|
|
|
const ENABLE_PERMISSIONS_CLASS = "enablePermissions";
|
2014-09-16 05:46:01 +09:00
|
|
|
|
Enforce PAGE-scrolling for *very* large/long documents (bug 1588435, PR 11263 follow-up)
This patch is essentially a continuation of PR 11263, which tried to improve loading/initialization performance of *very* large/long documents.
Note that browsers, in general, don't handle a huge amount of DOM-elements very well, with really poor (e.g. sluggish scrolling) performance once the number gets "large". Furthermore, at least in Firefox, it seems that DOM-elements towards the bottom of a HTML-page can effectively be ignored; for the PDF.js viewer that means that pages at the end of the document can become impossible to access.
Hence, in order to improve things for these *very* large/long documents, this patch will now enforce usage of the (recently added) PAGE-scrolling mode for these documents. As implemented, this will only happen once the number of pages *exceed* 15000 (which is hopefully rare in practice).
While this might feel a bit jarring to users being *forced* to use PAGE-scrolling, it seems all things considered like a better idea to ensure that the entire document actually remains accessible and with (hopefully) more acceptable performance.
Fixes [bug 1588435](https://bugzilla.mozilla.org/show_bug.cgi?id=1588435), to the extent that doing so is possible since the document contains 25560 pages (and is 197 MB large).
2021-11-29 02:43:30 +09:00
|
|
|
const PagesCountLimit = {
|
|
|
|
FORCE_SCROLL_MODE_PAGE: 15000,
|
|
|
|
FORCE_LAZY_PAGE_INIT: 7500,
|
[api-minor] Convert `Catalog.getPageDict` to an asynchronous method
Besides converting `Catalog.getPageDict` to an `async` method, thus simplifying the code, this patch also allows us to pro-actively fix a existing issue.
Note how we're looking up References in such a way that `MissingDataException`s won't cause trouble, however it's *technically possible* that the entries (i.e. /Count, /Kids, and /Type) in a /Pages Dictionary could actually be indirect objects as well. In the existing code this could lead to *some*, or even all, pages failing to load/render as intended.
In practice that doesn't *appear* to happen in real-world PDF documents, but given all the weird things that PDF software do I'd prefer to fix this pro-actively (rather than waiting for a bug report).
With `Catalog.getPageDict` being `async` this is now really simple to address, however I didn't want to introduce a bunch more *unconditional* asynchronicity in this method if it could be avoided (since that could slow things down). Hence we'll *synchronously* lookup the *raw* data in a /Pages Dictionary, and only fallback to asynchronous data lookup when a Reference was encountered.
In addition to the above, this patch also makes the following notable changes:
- Let `Catalog.getPageDict` *consistently* reject with the actual error, regardless of what data we're fetching. Previously we'd "swallow" the actual errors except when looking up Dictionary entries, which is inconsistent and thus seem unfortunate. As can be seen from the updated unit-tests this change is API-observable, hence why the patch is tagged `[api-minor]`.
- Improve the consistency of the Dictionary /Type-checks in both the `Catalog.getPageDict` and `Catalog.getAllPageDicts` methods.
In `Catalog.getPageDict` there's a fallback code-path where we're *incorrectly* checking the /Page Dictionary for a /Contents-entry, which is wrong since a /Page Dictionary doesn't need to have a /Contents-entry in order to be valid.
For consistency the `Catalog.getAllPageDicts` method is also updated to handle errors in the /Type-lookup correctly.
- Reduce the `PagesCountLimit.PAUSE_EAGER_PAGE_INIT` viewer constant, to further improve loading/rendering performance of the *second* page during initialization of very long documents; PR 14359 follow-up.
2021-12-24 21:46:35 +09:00
|
|
|
PAUSE_EAGER_PAGE_INIT: 250,
|
Enforce PAGE-scrolling for *very* large/long documents (bug 1588435, PR 11263 follow-up)
This patch is essentially a continuation of PR 11263, which tried to improve loading/initialization performance of *very* large/long documents.
Note that browsers, in general, don't handle a huge amount of DOM-elements very well, with really poor (e.g. sluggish scrolling) performance once the number gets "large". Furthermore, at least in Firefox, it seems that DOM-elements towards the bottom of a HTML-page can effectively be ignored; for the PDF.js viewer that means that pages at the end of the document can become impossible to access.
Hence, in order to improve things for these *very* large/long documents, this patch will now enforce usage of the (recently added) PAGE-scrolling mode for these documents. As implemented, this will only happen once the number of pages *exceed* 15000 (which is hopefully rare in practice).
While this might feel a bit jarring to users being *forced* to use PAGE-scrolling, it seems all things considered like a better idea to ensure that the entire document actually remains accessible and with (hopefully) more acceptable performance.
Fixes [bug 1588435](https://bugzilla.mozilla.org/show_bug.cgi?id=1588435), to the extent that doing so is possible since the document contains 25560 pages (and is 197 MB large).
2021-11-29 02:43:30 +09:00
|
|
|
};
|
|
|
|
|
2022-06-05 04:32:27 +09:00
|
|
|
function isValidAnnotationEditorMode(mode) {
|
2022-06-29 18:13:03 +09:00
|
|
|
return (
|
|
|
|
Object.values(AnnotationEditorType).includes(mode) &&
|
|
|
|
mode !== AnnotationEditorType.DISABLE
|
|
|
|
);
|
2022-06-05 04:32:27 +09:00
|
|
|
}
|
|
|
|
|
2014-09-21 02:21:49 +09:00
|
|
|
/**
|
|
|
|
* @typedef {Object} PDFViewerOptions
|
|
|
|
* @property {HTMLDivElement} container - The container for the viewer element.
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {HTMLDivElement} [viewer] - The viewer element.
|
2016-04-26 07:57:15 +09:00
|
|
|
* @property {EventBus} eventBus - The application event bus.
|
2014-09-21 02:21:49 +09:00
|
|
|
* @property {IPDFLinkService} linkService - The navigation/linking service.
|
2021-12-15 07:59:17 +09:00
|
|
|
* @property {IDownloadManager} [downloadManager] - The download manager
|
2019-10-12 23:30:32 +09:00
|
|
|
* component.
|
|
|
|
* @property {PDFFindController} [findController] - The find controller
|
|
|
|
* component.
|
[api-minor] Move the viewer scripting initialization/handling into a new `PDFScriptingManager` class
The *main* purpose of this patch is to allow scripting to be used together with the viewer components, note the updated "simpleviewer"/"singlepageviewer" examples, in addition to the full default viewer.
Given how the scripting functionality is currently implemented in the default viewer, trying to re-use this with the standalone viewer components would be *very* hard and ideally you'd want it to work out-of-the-box.
For an initial implementation, in the default viewer, of the scripting functionality it probably made sense to simply dump all of the code in the `app.js` file, however that cannot be used with the viewer components.
To address this, the functionality is moved into a new `PDFScriptingManager` class which can thus be handled in the same way as all other viewer components (and e.g. be passed to the `BaseViewer`-implementations).
Obviously the scripting functionality needs quite a lot of data, during its initialization, and for the default viewer we want to maintain the current way of doing the lookups since that helps avoid a number of redundant API-calls.
To that end, the `PDFScriptingManager` implementation accepts (optional) factories/functions such that we can maintain the current behaviour for the default viewer. For the viewer components specifically, fallback code-paths are provided to ensure that scripting will "just work"[1].
Besides moving the viewer handling of the scripting code to its own file/class, this patch also takes the opportunity to re-factor the functionality into a number of helper methods to improve overall readability[2].
Note that it's definitely possible that the `PDFScriptingManager` class could be improved even further (e.g. for general re-use), since it's still heavily tailored to the default viewer use-case, however I believe that this patch is still a good step forward overall.
---
[1] Obviously *all* the relevant document properties might not be available in the viewer components use-case (e.g. the various URLs), but most things should work just fine.
[2] The old `PDFViewerApplication._initializeJavaScript` method, where everything was simply inlined, have over time (in my opinion) become quite large and somewhat difficult to *easily* reason about.
2021-03-05 08:15:18 +09:00
|
|
|
* @property {PDFScriptingManager} [scriptingManager] - The scripting manager
|
|
|
|
* component.
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {PDFRenderingQueue} [renderingQueue] - The rendering queue object.
|
|
|
|
* @property {boolean} [removePageBorders] - Removes the border shadow around
|
|
|
|
* the pages. The default value is `false`.
|
|
|
|
* @property {number} [textLayerMode] - Controls if the text layer used for
|
2022-01-19 02:09:12 +09:00
|
|
|
* selection and searching is created. The constants from {TextLayerMode}
|
|
|
|
* should be used. The default value is `TextLayerMode.ENABLE`.
|
[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
|
|
|
* @property {number} [annotationMode] - Controls if the annotation layer is
|
|
|
|
* created, and if interactive form elements or `AnnotationStorage`-data are
|
|
|
|
* being rendered. The constants from {@link AnnotationMode} should be used;
|
|
|
|
* see also {@link RenderParameters} and {@link GetOperatorListParameters}.
|
|
|
|
* The default value is `AnnotationMode.ENABLE_FORMS`.
|
2022-07-01 20:27:13 +09:00
|
|
|
* @property {number} [annotationEditorMode] - Enables the creation and editing
|
2022-06-29 18:13:03 +09:00
|
|
|
* of new Annotations. The constants from {@link AnnotationEditorType} should
|
2022-08-21 20:48:48 +09:00
|
|
|
* be used. The default value is `AnnotationEditorType.NONE`.
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {string} [imageResourcesPath] - Path for image resources, mainly
|
2018-02-13 21:17:11 +09:00
|
|
|
* mainly for annotation icons. Include trailing slash.
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {boolean} [enablePrintAutoRotate] - Enables automatic rotation of
|
2020-06-25 08:04:42 +09:00
|
|
|
* landscape pages upon printing. The default is `false`.
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {boolean} [useOnlyCssZoom] - Enables CSS only zooming. The default
|
|
|
|
* value is `false`.
|
2022-11-22 01:15:39 +09:00
|
|
|
* @property {boolean} [isOffscreenCanvasSupported] - Allows to use an
|
|
|
|
* OffscreenCanvas if needed.
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {number} [maxCanvasPixels] - The maximum supported canvas size in
|
|
|
|
* total pixels, i.e. width * height. Use -1 for no limit. The default value
|
|
|
|
* is 4096 * 4096 (16 mega-pixels).
|
2017-05-04 10:05:53 +09:00
|
|
|
* @property {IL10n} l10n - Localization service.
|
2021-12-12 00:23:29 +09:00
|
|
|
* @property {boolean} [enablePermissions] - Enables PDF document permissions,
|
|
|
|
* when they exist. The default value is `false`.
|
2022-05-04 22:37:13 +09:00
|
|
|
* @property {Object} [pageColors] - Overwrites background and foreground colors
|
|
|
|
* with user defined ones in order to improve readability in high contrast
|
|
|
|
* mode.
|
2014-09-21 02:21:49 +09:00
|
|
|
*/
|
|
|
|
|
2021-11-06 18:09:59 +09:00
|
|
|
class PDFPageViewBuffer {
|
2021-11-06 18:10:05 +09:00
|
|
|
// Here we rely on the fact that `Set`s preserve the insertion order.
|
|
|
|
#buf = new Set();
|
2021-11-06 18:09:59 +09:00
|
|
|
|
|
|
|
#size = 0;
|
|
|
|
|
|
|
|
constructor(size) {
|
|
|
|
this.#size = size;
|
|
|
|
}
|
|
|
|
|
|
|
|
push(view) {
|
2021-11-06 18:10:05 +09:00
|
|
|
const buf = this.#buf;
|
|
|
|
if (buf.has(view)) {
|
|
|
|
buf.delete(view); // Move the view to the "end" of the buffer.
|
2014-10-30 21:04:01 +09:00
|
|
|
}
|
2021-11-06 18:10:05 +09:00
|
|
|
buf.add(view);
|
|
|
|
|
|
|
|
if (buf.size > this.#size) {
|
|
|
|
this.#destroyFirstView();
|
2014-10-30 21:04:01 +09:00
|
|
|
}
|
2021-11-06 18:09:59 +09:00
|
|
|
}
|
2021-11-01 19:52:45 +09:00
|
|
|
|
2018-05-15 12:10:32 +09:00
|
|
|
/**
|
2021-11-01 19:52:45 +09:00
|
|
|
* After calling resize, the size of the buffer will be `newSize`.
|
|
|
|
* The optional parameter `idsToKeep` is, if present, a Set of page-ids to
|
|
|
|
* push to the back of the buffer, delaying their destruction. The size of
|
|
|
|
* `idsToKeep` has no impact on the final size of the buffer; if `idsToKeep`
|
|
|
|
* is larger than `newSize`, some of those pages will be destroyed anyway.
|
2018-05-15 12:10:32 +09:00
|
|
|
*/
|
2021-11-06 18:09:59 +09:00
|
|
|
resize(newSize, idsToKeep = null) {
|
|
|
|
this.#size = newSize;
|
|
|
|
|
2021-11-06 18:10:05 +09:00
|
|
|
const buf = this.#buf;
|
2021-11-01 19:52:45 +09:00
|
|
|
if (idsToKeep) {
|
2021-11-06 18:10:05 +09:00
|
|
|
const ii = buf.size;
|
|
|
|
let i = 1;
|
|
|
|
for (const view of buf) {
|
|
|
|
if (idsToKeep.has(view.id)) {
|
|
|
|
buf.delete(view); // Move the view to the "end" of the buffer.
|
|
|
|
buf.add(view);
|
|
|
|
}
|
|
|
|
if (++i > ii) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
2021-11-06 18:10:05 +09:00
|
|
|
|
|
|
|
while (buf.size > this.#size) {
|
|
|
|
this.#destroyFirstView();
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2021-11-06 18:09:59 +09:00
|
|
|
}
|
2021-11-05 22:29:02 +09:00
|
|
|
|
2021-11-06 18:09:59 +09:00
|
|
|
has(view) {
|
2021-11-06 18:10:05 +09:00
|
|
|
return this.#buf.has(view);
|
|
|
|
}
|
|
|
|
|
2021-11-14 20:20:04 +09:00
|
|
|
[Symbol.iterator]() {
|
|
|
|
return this.#buf.keys();
|
|
|
|
}
|
|
|
|
|
2021-11-06 18:10:05 +09:00
|
|
|
#destroyFirstView() {
|
|
|
|
const firstView = this.#buf.keys().next().value;
|
|
|
|
|
|
|
|
firstView?.destroy();
|
|
|
|
this.#buf.delete(firstView);
|
2021-11-05 22:29:02 +09:00
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-10-30 21:04:01 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* Simple viewer control to display PDF content/pages.
|
|
|
|
*/
|
2022-09-08 18:51:17 +09:00
|
|
|
class PDFViewer {
|
2021-11-06 18:09:59 +09:00
|
|
|
#buffer = null;
|
|
|
|
|
2022-08-21 20:48:48 +09:00
|
|
|
#annotationEditorMode = AnnotationEditorType.NONE;
|
2022-06-01 17:38:08 +09:00
|
|
|
|
|
|
|
#annotationEditorUIManager = null;
|
|
|
|
|
2021-12-12 00:53:59 +09:00
|
|
|
#annotationMode = AnnotationMode.ENABLE_FORMS;
|
|
|
|
|
2022-12-15 02:47:59 +09:00
|
|
|
#containerTopLeft = null;
|
|
|
|
|
2021-12-12 00:23:29 +09:00
|
|
|
#enablePermissions = false;
|
|
|
|
|
2021-11-23 21:29:00 +09:00
|
|
|
#previousContainerHeight = 0;
|
|
|
|
|
2022-12-15 02:47:59 +09:00
|
|
|
#resizeObserver = new ResizeObserver(this.#resizeObserverCallback.bind(this));
|
|
|
|
|
2021-10-28 18:57:27 +09:00
|
|
|
#scrollModePageState = null;
|
|
|
|
|
2021-12-19 05:25:31 +09:00
|
|
|
#onVisibilityChange = null;
|
|
|
|
|
2022-12-12 22:24:27 +09:00
|
|
|
#scaleTimeoutId = null;
|
|
|
|
|
2014-09-21 02:21:49 +09:00
|
|
|
/**
|
|
|
|
* @param {PDFViewerOptions} options
|
|
|
|
*/
|
2017-07-09 20:07:06 +09:00
|
|
|
constructor(options) {
|
2020-10-28 01:09:42 +09:00
|
|
|
const viewerVersion =
|
|
|
|
typeof PDFJSDev !== "undefined" ? PDFJSDev.eval("BUNDLE_VERSION") : null;
|
|
|
|
if (version !== viewerVersion) {
|
|
|
|
throw new Error(
|
|
|
|
`The API version "${version}" does not match the Viewer version "${viewerVersion}".`
|
|
|
|
);
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
this.container = options.container;
|
2014-09-16 05:46:01 +09:00
|
|
|
this.viewer = options.viewer || options.container.firstElementChild;
|
2020-09-03 21:54:54 +09:00
|
|
|
|
|
|
|
if (
|
Ensure that the `container` div, on `BaseViewer`-instances, is absolutely positioned
The `getVisibleElements` helper function currently requires the viewerContainer to be absolutely positioned; possibly fixing this is tracked in issue 11626.
Without `position: absolute;` set, in the CSS, there's a number of things that won't work correctly such as e.g.
- Determining which pages are currently visible, thus forcing all of them to render on load and increasing resource usage significantly; note https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#allthepages
- Scrolling pages into view, by using the `BaseViewer.currentPageNumber` setter or similar.
Based on the number of opened issues over the years, the fact that `position: absolute;` is required has shown to be something that users can very easily overlook unless they follow e.g. the `simpleviewer` example to the letter.
Hence, to improve things until such a time that issue 11626 is fixed, we'll now refuse to initialize a `BaseViewer` instance unless the `container` has the required CSS set. (Forcibly setting `position: absolute;` on the viewerContainer element is bound to cause significantly more issues/confusion, hence the current approach of throwing an Error.)
2020-09-09 22:07:38 +09:00
|
|
|
typeof PDFJSDev === "undefined" ||
|
|
|
|
PDFJSDev.test("!PRODUCTION || GENERIC")
|
2020-09-03 21:54:54 +09:00
|
|
|
) {
|
2023-01-02 22:10:36 +09:00
|
|
|
if (this.container?.tagName !== "DIV" || this.viewer?.tagName !== "DIV") {
|
Ensure that the `container` div, on `BaseViewer`-instances, is absolutely positioned
The `getVisibleElements` helper function currently requires the viewerContainer to be absolutely positioned; possibly fixing this is tracked in issue 11626.
Without `position: absolute;` set, in the CSS, there's a number of things that won't work correctly such as e.g.
- Determining which pages are currently visible, thus forcing all of them to render on load and increasing resource usage significantly; note https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#allthepages
- Scrolling pages into view, by using the `BaseViewer.currentPageNumber` setter or similar.
Based on the number of opened issues over the years, the fact that `position: absolute;` is required has shown to be something that users can very easily overlook unless they follow e.g. the `simpleviewer` example to the letter.
Hence, to improve things until such a time that issue 11626 is fixed, we'll now refuse to initialize a `BaseViewer` instance unless the `container` has the required CSS set. (Forcibly setting `position: absolute;` on the viewerContainer element is bound to cause significantly more issues/confusion, hence the current approach of throwing an Error.)
2020-09-09 22:07:38 +09:00
|
|
|
throw new Error("Invalid `container` and/or `viewer` option.");
|
|
|
|
}
|
|
|
|
|
2021-02-09 20:01:07 +09:00
|
|
|
if (
|
|
|
|
this.container.offsetParent &&
|
|
|
|
getComputedStyle(this.container).position !== "absolute"
|
|
|
|
) {
|
Ensure that the `container` div, on `BaseViewer`-instances, is absolutely positioned
The `getVisibleElements` helper function currently requires the viewerContainer to be absolutely positioned; possibly fixing this is tracked in issue 11626.
Without `position: absolute;` set, in the CSS, there's a number of things that won't work correctly such as e.g.
- Determining which pages are currently visible, thus forcing all of them to render on load and increasing resource usage significantly; note https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#allthepages
- Scrolling pages into view, by using the `BaseViewer.currentPageNumber` setter or similar.
Based on the number of opened issues over the years, the fact that `position: absolute;` is required has shown to be something that users can very easily overlook unless they follow e.g. the `simpleviewer` example to the letter.
Hence, to improve things until such a time that issue 11626 is fixed, we'll now refuse to initialize a `BaseViewer` instance unless the `container` has the required CSS set. (Forcibly setting `position: absolute;` on the viewerContainer element is bound to cause significantly more issues/confusion, hence the current approach of throwing an Error.)
2020-09-09 22:07:38 +09:00
|
|
|
throw new Error("The `container` must be absolutely positioned.");
|
|
|
|
}
|
2020-09-03 21:54:54 +09:00
|
|
|
}
|
2023-01-02 22:10:36 +09:00
|
|
|
this.#resizeObserver.observe(this.container);
|
|
|
|
|
2020-02-27 23:02:03 +09:00
|
|
|
this.eventBus = options.eventBus;
|
Simplify the SimpleLinkService and use it to pass in a linkService instance in DefaultAnnotationsLayerFactory
Considering that most methods of `SimpleLinkService` are complete stubs, or practically "useless" considering what they return, we can actually simplify it even more.
*Note:* This depends on the previous patch, that did a small amount of refactoring of `PDFViewer_scrollPageIntoView`, since `PDFViewer.linkService.page` is no longer accessed.
----------
Currently the `pageviewer` components example doesn't work correctly (an error is printed in the console), since no `linkService` is present when the `AnnotationsLayerBuilder` is created.
*Note:* Given that this uses the `SimpleLinkService`, clicking on e.g. internal links won't actually do anything. However, given that internal links (and similar features) are pretty much useless when only *one* page is loaded the `pageviewer` example, I don't think that really matters.
Also, using the complete `PDFLinkService` would require a `PDFViewer` instance. That would significantly complicate the example, thus making it both less clear and less self contained.
2015-06-12 05:20:04 +09:00
|
|
|
this.linkService = options.linkService || new SimpleLinkService();
|
2016-02-15 04:44:00 +09:00
|
|
|
this.downloadManager = options.downloadManager || null;
|
2018-09-23 02:44:13 +09:00
|
|
|
this.findController = options.findController || null;
|
[api-minor] Move the viewer scripting initialization/handling into a new `PDFScriptingManager` class
The *main* purpose of this patch is to allow scripting to be used together with the viewer components, note the updated "simpleviewer"/"singlepageviewer" examples, in addition to the full default viewer.
Given how the scripting functionality is currently implemented in the default viewer, trying to re-use this with the standalone viewer components would be *very* hard and ideally you'd want it to work out-of-the-box.
For an initial implementation, in the default viewer, of the scripting functionality it probably made sense to simply dump all of the code in the `app.js` file, however that cannot be used with the viewer components.
To address this, the functionality is moved into a new `PDFScriptingManager` class which can thus be handled in the same way as all other viewer components (and e.g. be passed to the `BaseViewer`-implementations).
Obviously the scripting functionality needs quite a lot of data, during its initialization, and for the default viewer we want to maintain the current way of doing the lookups since that helps avoid a number of redundant API-calls.
To that end, the `PDFScriptingManager` implementation accepts (optional) factories/functions such that we can maintain the current behaviour for the default viewer. For the viewer components specifically, fallback code-paths are provided to ensure that scripting will "just work"[1].
Besides moving the viewer handling of the scripting code to its own file/class, this patch also takes the opportunity to re-factor the functionality into a number of helper methods to improve overall readability[2].
Note that it's definitely possible that the `PDFScriptingManager` class could be improved even further (e.g. for general re-use), since it's still heavily tailored to the default viewer use-case, however I believe that this patch is still a good step forward overall.
---
[1] Obviously *all* the relevant document properties might not be available in the viewer components use-case (e.g. the various URLs), but most things should work just fine.
[2] The old `PDFViewerApplication._initializeJavaScript` method, where everything was simply inlined, have over time (in my opinion) become quite large and somewhat difficult to *easily* reason about.
2021-03-05 08:15:18 +09:00
|
|
|
this._scriptingManager = options.scriptingManager || null;
|
[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
|
|
|
this.textLayerMode = options.textLayerMode ?? TextLayerMode.ENABLE;
|
2021-12-12 00:53:59 +09:00
|
|
|
this.#annotationMode =
|
[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
|
|
|
options.annotationMode ?? AnnotationMode.ENABLE_FORMS;
|
2022-06-29 18:13:03 +09:00
|
|
|
this.#annotationEditorMode =
|
2022-08-21 20:48:48 +09:00
|
|
|
options.annotationEditorMode ?? AnnotationEditorType.NONE;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.imageResourcesPath = options.imageResourcesPath || "";
|
2017-02-08 08:15:09 +09:00
|
|
|
this.enablePrintAutoRotate = options.enablePrintAutoRotate || false;
|
2022-07-19 20:41:01 +09:00
|
|
|
if (
|
|
|
|
typeof PDFJSDev === "undefined" ||
|
|
|
|
PDFJSDev.test("!PRODUCTION || GENERIC")
|
|
|
|
) {
|
2023-02-03 18:08:47 +09:00
|
|
|
this.removePageBorders = options.removePageBorders || false;
|
2022-07-19 20:41:01 +09:00
|
|
|
this.renderer = options.renderer || RendererType.CANVAS;
|
|
|
|
}
|
2018-02-13 20:52:42 +09:00
|
|
|
this.useOnlyCssZoom = options.useOnlyCssZoom || false;
|
2022-11-22 01:15:39 +09:00
|
|
|
this.isOffscreenCanvasSupported =
|
|
|
|
options.isOffscreenCanvasSupported ?? true;
|
2018-02-13 21:02:15 +09:00
|
|
|
this.maxCanvasPixels = options.maxCanvasPixels;
|
2017-05-04 10:05:53 +09:00
|
|
|
this.l10n = options.l10n || NullL10n;
|
2021-12-12 00:23:29 +09:00
|
|
|
this.#enablePermissions = options.enablePermissions || false;
|
2022-05-04 22:37:13 +09:00
|
|
|
this.pageColors = options.pageColors || null;
|
|
|
|
|
|
|
|
if (typeof PDFJSDev === "undefined" || !PDFJSDev.test("MOZCENTRAL")) {
|
|
|
|
if (
|
2022-05-26 16:45:05 +09:00
|
|
|
this.pageColors &&
|
|
|
|
!(
|
|
|
|
CSS.supports("color", this.pageColors.background) &&
|
|
|
|
CSS.supports("color", this.pageColors.foreground)
|
|
|
|
)
|
2022-05-04 22:37:13 +09:00
|
|
|
) {
|
2022-05-26 16:45:05 +09:00
|
|
|
if (this.pageColors.background || this.pageColors.foreground) {
|
2022-05-04 22:37:13 +09:00
|
|
|
console.warn(
|
2022-09-08 18:51:17 +09:00
|
|
|
"PDFViewer: Ignoring `pageColors`-option, since the browser doesn't support the values used."
|
2022-05-04 22:37:13 +09:00
|
|
|
);
|
|
|
|
}
|
|
|
|
this.pageColors = null;
|
|
|
|
}
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2014-09-16 05:46:01 +09:00
|
|
|
this.defaultRenderingQueue = !options.renderingQueue;
|
|
|
|
if (this.defaultRenderingQueue) {
|
|
|
|
// Custom rendering queue is not specified, using default one
|
|
|
|
this.renderingQueue = new PDFRenderingQueue();
|
|
|
|
this.renderingQueue.setViewer(this);
|
|
|
|
} else {
|
|
|
|
this.renderingQueue = options.renderingQueue;
|
|
|
|
}
|
2021-08-04 21:42:24 +09:00
|
|
|
|
2014-09-13 11:27:45 +09:00
|
|
|
this.scroll = watchScroll(this.container, this._scrollUpdate.bind(this));
|
2014-09-16 02:37:03 +09:00
|
|
|
this.presentationModeState = PresentationModeState.UNKNOWN;
|
2019-07-19 19:40:49 +09:00
|
|
|
this._onBeforeDraw = this._onAfterDraw = null;
|
2014-09-21 02:15:18 +09:00
|
|
|
this._resetView();
|
2015-03-12 04:36:01 +09:00
|
|
|
|
2023-02-03 18:08:47 +09:00
|
|
|
if (
|
|
|
|
(typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) &&
|
|
|
|
this.removePageBorders
|
|
|
|
) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.viewer.classList.add("removePageBorders");
|
2015-03-12 04:36:01 +09:00
|
|
|
}
|
2022-12-15 02:47:59 +09:00
|
|
|
|
|
|
|
this.#updateContainerHeightCss();
|
2014-09-13 11:27:45 +09:00
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
get pagesCount() {
|
|
|
|
return this._pages.length;
|
|
|
|
}
|
Remove the `previousPageNumber` parameter from the `pagechanging`/pagechange` events, and stop dispatching the events if the input is out of bounds
This patch attempts to cleanup a couple of things:
- Remove the `previousPageNumber` paramater. Prior to PR 7289, when the events were dispatched even when the active page didn't change, it made sense to be able to detect that in an event listener. However, now that's no longer the case, and furthermore other similar events (e.g. `scalechanging`/`scalechange`) don't include information about the previous state.
- Don't dispatch the events when the value passed to `set currentPageNumber` is out of bounds. Given that the active page doesn't change in this case, again similar to PR 7289, I don't think that the events should actually be dispatched in this case.
- Ensure that the value passed to `set currentPageNumber` is actually an integer, to avoid any issues (note how e.g. `set currentScale` has similar validation code).
Given that these changes could possibly affect the PDF.js `mochitest` integration tests in mozilla-central, in particular https://dxr.mozilla.org/mozilla-central/source/browser/extensions/pdfjs/test/browser_pdfjs_navigation.js, I ran the tests locally with this patch applied to ensure that they still pass.
2016-07-22 22:32:14 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
getPageView(index) {
|
|
|
|
return this._pages[index];
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {boolean} - True if all {PDFPageView} objects are initialized.
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
get pageViewsReady() {
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
if (!this._pagesCapability.settled) {
|
2019-11-19 19:58:19 +09:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// Prevent printing errors when 'disableAutoFetch' is set, by ensuring
|
|
|
|
// that *all* pages have in fact been completely loaded.
|
2020-04-14 19:28:14 +09:00
|
|
|
return this._pages.every(function (pageView) {
|
2021-02-06 01:36:28 +09:00
|
|
|
return pageView?.pdfPage;
|
2019-11-19 19:58:19 +09:00
|
|
|
});
|
2017-07-09 20:07:06 +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
|
|
|
/**
|
|
|
|
* @type {boolean}
|
|
|
|
*/
|
|
|
|
get renderForms() {
|
2021-12-12 00:53:59 +09:00
|
|
|
return this.#annotationMode === AnnotationMode.ENABLE_FORMS;
|
[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
|
|
|
}
|
|
|
|
|
2021-07-29 16:53:24 +09:00
|
|
|
/**
|
|
|
|
* @type {boolean}
|
|
|
|
*/
|
|
|
|
get enableScripting() {
|
|
|
|
return !!this._scriptingManager;
|
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {number}
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
get currentPageNumber() {
|
|
|
|
return this._currentPageNumber;
|
|
|
|
}
|
2016-07-14 19:04:16 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* @param {number} val - The page number.
|
|
|
|
*/
|
|
|
|
set currentPageNumber(val) {
|
2017-09-03 20:08:50 +09:00
|
|
|
if (!Number.isInteger(val)) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
throw new Error("Invalid page number.");
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// The intent can be to just reset a scroll position and/or scale.
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
if (!this._setCurrentPageNumber(val, /* resetCurrentPageView = */ true)) {
|
2021-08-09 19:05:50 +09:00
|
|
|
console.error(`currentPageNumber: "${val}" is not a valid page.`);
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-10-13 01:14:29 +09:00
|
|
|
* @returns {boolean} Whether the pageNumber is valid (within bounds).
|
2017-07-09 20:07:06 +09:00
|
|
|
* @private
|
|
|
|
*/
|
|
|
|
_setCurrentPageNumber(val, resetCurrentPageView = false) {
|
|
|
|
if (this._currentPageNumber === val) {
|
2016-07-14 19:04:16 +09:00
|
|
|
if (resetCurrentPageView) {
|
2022-04-17 19:37:10 +09:00
|
|
|
this.#resetCurrentPageView();
|
2016-07-14 19:04:16 +09:00
|
|
|
}
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
return true;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2017-06-21 18:23:17 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
if (!(0 < val && val <= this.pagesCount)) {
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
return false;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2020-12-10 04:08:49 +09:00
|
|
|
const previous = this._currentPageNumber;
|
2018-09-21 03:51:50 +09:00
|
|
|
this._currentPageNumber = val;
|
2014-09-21 02:15:18 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("pagechanging", {
|
2017-07-09 20:07:06 +09:00
|
|
|
source: this,
|
|
|
|
pageNumber: val,
|
2021-02-06 00:24:39 +09:00
|
|
|
pageLabel: this._pageLabels?.[val - 1] ?? null,
|
2020-12-10 04:08:49 +09:00
|
|
|
previous,
|
2018-09-21 03:51:50 +09:00
|
|
|
});
|
2015-07-01 04:49:32 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
if (resetCurrentPageView) {
|
2022-04-17 19:37:10 +09:00
|
|
|
this.#resetCurrentPageView();
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
return true;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-15 23:49:24 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {string|null} Returns the current page label, or `null` if no page
|
|
|
|
* labels exist.
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
get currentPageLabel() {
|
2021-02-06 00:24:39 +09:00
|
|
|
return this._pageLabels?.[this._currentPageNumber - 1] ?? null;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-15 23:49:24 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* @param {string} val - The page label.
|
|
|
|
*/
|
|
|
|
set currentPageLabel(val) {
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
let page = val | 0; // Fallback page number.
|
2017-07-09 20:07:06 +09:00
|
|
|
if (this._pageLabels) {
|
2019-12-27 08:22:32 +09:00
|
|
|
const i = this._pageLabels.indexOf(val);
|
2017-07-09 20:07:06 +09:00
|
|
|
if (i >= 0) {
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
page = i + 1;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
}
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
// The intent can be to just reset a scroll position and/or scale.
|
|
|
|
if (!this._setCurrentPageNumber(page, /* resetCurrentPageView = */ true)) {
|
2021-08-09 19:05:50 +09:00
|
|
|
console.error(`currentPageLabel: "${val}" is not a valid page.`);
|
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824)
Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit.
The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`.
The other changes are:
- Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds.
- Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages.
- Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter.
- Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2017-04-15 19:57:54 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {number}
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
get currentScale() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return this._currentScale !== UNKNOWN_SCALE
|
|
|
|
? this._currentScale
|
|
|
|
: DEFAULT_SCALE;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-15 23:49:24 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* @param {number} val - Scale of the pages in percents.
|
|
|
|
*/
|
|
|
|
set currentScale(val) {
|
|
|
|
if (isNaN(val)) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
throw new Error("Invalid numeric scale.");
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(val, { noScroll: false });
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-15 23:49:24 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {string}
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
get currentScaleValue() {
|
|
|
|
return this._currentScaleValue;
|
|
|
|
}
|
2014-09-15 23:49:24 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* @param val - The scale of the pages (in percent or predefined value).
|
|
|
|
*/
|
|
|
|
set currentScaleValue(val) {
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(val, { noScroll: false });
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-16 05:46:01 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {number}
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
get pagesRotation() {
|
|
|
|
return this._pagesRotation;
|
|
|
|
}
|
2014-10-01 02:31:58 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* @param {number} rotation - The rotation of the pages (0, 90, 180, 270).
|
|
|
|
*/
|
|
|
|
set pagesRotation(rotation) {
|
2017-08-19 21:23:40 +09:00
|
|
|
if (!isValidRotation(rotation)) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
throw new Error("Invalid pages rotation angle.");
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
2021-03-28 21:12:13 +09:00
|
|
|
// Normalize the rotation, by clamping it to the [0, 360) range.
|
|
|
|
rotation %= 360;
|
|
|
|
if (rotation < 0) {
|
|
|
|
rotation += 360;
|
|
|
|
}
|
2017-08-19 21:23:40 +09:00
|
|
|
if (this._pagesRotation === rotation) {
|
|
|
|
return; // The rotation didn't change.
|
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
this._pagesRotation = rotation;
|
2015-02-11 21:05:04 +09:00
|
|
|
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageNumber = this._currentPageNumber;
|
2017-08-19 21:23:40 +09:00
|
|
|
|
2022-12-12 22:24:27 +09:00
|
|
|
this.refresh(true, { rotation });
|
|
|
|
|
2017-08-19 21:23:40 +09:00
|
|
|
// Prevent errors in case the rotation changes *before* the scale has been
|
|
|
|
// set to a non-default value.
|
|
|
|
if (this._currentScaleValue) {
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(this._currentScaleValue, { noScroll: true });
|
2017-08-19 21:23:40 +09:00
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("rotationchanging", {
|
2017-08-19 21:23:40 +09:00
|
|
|
source: this,
|
|
|
|
pagesRotation: rotation,
|
|
|
|
pageNumber,
|
|
|
|
});
|
2016-01-23 21:56:56 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
if (this.defaultRenderingQueue) {
|
2014-09-13 11:27:45 +09:00
|
|
|
this.update();
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
get firstPagePromise() {
|
|
|
|
return this.pdfDocument ? this._firstPageCapability.promise : null;
|
|
|
|
}
|
|
|
|
|
|
|
|
get onePageRendered() {
|
|
|
|
return this.pdfDocument ? this._onePageRenderedCapability.promise : null;
|
|
|
|
}
|
|
|
|
|
|
|
|
get pagesPromise() {
|
|
|
|
return this.pdfDocument ? this._pagesCapability.promise : null;
|
|
|
|
}
|
|
|
|
|
[api-minor] Remove the `annotationEditorLayerFactory` in the viewer
Please note that this functionality has never really mattered for the Firefox PDF Viewer, the GENERIC viewer, or even the "simpleviewer"/"singlepageviewer" component-examples. Hence, in practice this means that only the "pageviewer" component-example[1] have ever really utilized this.
Using factories to initialize various layers in the viewer, rather than simply invoking the relevant code directly, seems (at least to me) like a somewhat roundabout way of doing things.
Not only does this lead to more code, both to write and maintain, but since many of the layers have common parameters (e.g. an `AnnotationStorage`-instance) there's also some duplication.
Hence this patch, which removes the `annotationEditorLayerFactory` and instead uses a lookup-function in the `PDFPageView`-class to access the external viewer-properties as necessary.
Note that this should even be an improvement for the "pageviewer" component-example, since most layers will now work by default rather than require manual configuration.
---
[1] In practice we generally suggest using the "simpleviewer", or "singlepageviewer", since it does *most* things out-of-the-box and given that a lot of functionality really require *a viewer* and not just a single page in order to work.
2022-12-06 22:21:51 +09:00
|
|
|
#layerProperties() {
|
|
|
|
const self = this;
|
|
|
|
return {
|
|
|
|
get annotationEditorUIManager() {
|
|
|
|
return self.#annotationEditorUIManager;
|
|
|
|
},
|
[api-minor] Remove the `annotationLayerFactory` in the viewer
Please note that this functionality has never really mattered for the Firefox PDF Viewer, the GENERIC viewer, or even the "simpleviewer"/"singlepageviewer" component-examples. Hence, in practice this means that only the "pageviewer" component-example[1] have ever really utilized this.
Using factories to initialize various layers in the viewer, rather than simply invoking the relevant code directly, seems (at least to me) like a somewhat roundabout way of doing things.
Not only does this lead to more code, both to write and maintain, but since many of the layers have common parameters (e.g. an `AnnotationStorage`-instance) there's also some duplication.
Hence this patch, which removes the `annotationLayerFactory` and instead uses a lookup-function in the `PDFPageView`-class to access the external viewer-properties as necessary.
Note that this should even be an improvement for the "pageviewer" component-example, since most layers will now work by default rather than require manual configuration.
---
[1] In practice we generally suggest using the "simpleviewer", or "singlepageviewer", since it does *most* things out-of-the-box and given that a lot of functionality really require *a viewer* and not just a single page in order to work.
2022-12-07 07:34:55 +09:00
|
|
|
get annotationStorage() {
|
|
|
|
return self.pdfDocument?.annotationStorage;
|
|
|
|
},
|
|
|
|
get downloadManager() {
|
|
|
|
return self.downloadManager;
|
|
|
|
},
|
|
|
|
get enableScripting() {
|
|
|
|
return !!self._scriptingManager;
|
|
|
|
},
|
|
|
|
get fieldObjectsPromise() {
|
|
|
|
return self.pdfDocument?.getFieldObjects();
|
|
|
|
},
|
[api-minor] Remove the `textHighlighterFactory` in the viewer
Please note that this functionality has never really mattered for the Firefox PDF Viewer, the GENERIC viewer, or even the "simpleviewer"/"singlepageviewer" component-examples. Hence, in practice this means that only the "pageviewer" component-example[1] have ever really utilized this.
Using factories to initialize various layers in the viewer, rather than simply invoking the relevant code directly, seems (at least to me) like a somewhat roundabout way of doing things.
Not only does this lead to more code, both to write and maintain, but since many of the layers have common parameters (e.g. an `AnnotationStorage`-instance) there's also some duplication.
Hence this patch, which removes the `textHighlighterFactory` and instead uses a lookup-function in the `PDFPageView`-class to access the external viewer-properties as necessary.
Note that this should even be an improvement for the "pageviewer" component-example, since most layers will now work by default rather than require manual configuration.
---
[1] In practice we generally suggest using the "simpleviewer", or "singlepageviewer", since it does *most* things out-of-the-box and given that a lot of functionality really require *a viewer* and not just a single page in order to work.
2022-12-07 07:55:23 +09:00
|
|
|
get findController() {
|
|
|
|
return self.findController;
|
|
|
|
},
|
[api-minor] Remove the `annotationLayerFactory` in the viewer
Please note that this functionality has never really mattered for the Firefox PDF Viewer, the GENERIC viewer, or even the "simpleviewer"/"singlepageviewer" component-examples. Hence, in practice this means that only the "pageviewer" component-example[1] have ever really utilized this.
Using factories to initialize various layers in the viewer, rather than simply invoking the relevant code directly, seems (at least to me) like a somewhat roundabout way of doing things.
Not only does this lead to more code, both to write and maintain, but since many of the layers have common parameters (e.g. an `AnnotationStorage`-instance) there's also some duplication.
Hence this patch, which removes the `annotationLayerFactory` and instead uses a lookup-function in the `PDFPageView`-class to access the external viewer-properties as necessary.
Note that this should even be an improvement for the "pageviewer" component-example, since most layers will now work by default rather than require manual configuration.
---
[1] In practice we generally suggest using the "simpleviewer", or "singlepageviewer", since it does *most* things out-of-the-box and given that a lot of functionality really require *a viewer* and not just a single page in order to work.
2022-12-07 07:34:55 +09:00
|
|
|
get hasJSActionsPromise() {
|
|
|
|
return self.pdfDocument?.hasJSActions();
|
|
|
|
},
|
|
|
|
get linkService() {
|
|
|
|
return self.linkService;
|
|
|
|
},
|
[api-minor] Remove the `annotationEditorLayerFactory` in the viewer
Please note that this functionality has never really mattered for the Firefox PDF Viewer, the GENERIC viewer, or even the "simpleviewer"/"singlepageviewer" component-examples. Hence, in practice this means that only the "pageviewer" component-example[1] have ever really utilized this.
Using factories to initialize various layers in the viewer, rather than simply invoking the relevant code directly, seems (at least to me) like a somewhat roundabout way of doing things.
Not only does this lead to more code, both to write and maintain, but since many of the layers have common parameters (e.g. an `AnnotationStorage`-instance) there's also some duplication.
Hence this patch, which removes the `annotationEditorLayerFactory` and instead uses a lookup-function in the `PDFPageView`-class to access the external viewer-properties as necessary.
Note that this should even be an improvement for the "pageviewer" component-example, since most layers will now work by default rather than require manual configuration.
---
[1] In practice we generally suggest using the "simpleviewer", or "singlepageviewer", since it does *most* things out-of-the-box and given that a lot of functionality really require *a viewer* and not just a single page in order to work.
2022-12-06 22:21:51 +09:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2021-12-12 00:53:59 +09:00
|
|
|
/**
|
|
|
|
* Currently only *some* permissions are supported.
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
* @returns {Object}
|
2021-12-12 00:53:59 +09:00
|
|
|
*/
|
2021-12-14 20:18:12 +09:00
|
|
|
#initializePermissions(permissions) {
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
const params = {
|
|
|
|
annotationEditorMode: this.#annotationEditorMode,
|
|
|
|
annotationMode: this.#annotationMode,
|
|
|
|
textLayerMode: this.textLayerMode,
|
|
|
|
};
|
2021-12-12 04:41:41 +09:00
|
|
|
if (!permissions) {
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
return params;
|
2021-12-12 00:23:29 +09:00
|
|
|
}
|
2021-12-12 00:53:59 +09:00
|
|
|
|
2021-12-12 00:23:29 +09:00
|
|
|
if (!permissions.includes(PermissionFlag.COPY)) {
|
|
|
|
this.viewer.classList.add(ENABLE_PERMISSIONS_CLASS);
|
|
|
|
}
|
2021-12-12 00:53:59 +09:00
|
|
|
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
if (!permissions.includes(PermissionFlag.MODIFY_CONTENTS)) {
|
2022-06-29 18:13:03 +09:00
|
|
|
params.annotationEditorMode = AnnotationEditorType.DISABLE;
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
}
|
|
|
|
|
2021-12-12 00:53:59 +09:00
|
|
|
if (
|
|
|
|
!permissions.includes(PermissionFlag.MODIFY_ANNOTATIONS) &&
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
!permissions.includes(PermissionFlag.FILL_INTERACTIVE_FORMS) &&
|
|
|
|
this.#annotationMode === AnnotationMode.ENABLE_FORMS
|
2021-12-12 00:53:59 +09:00
|
|
|
) {
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
params.annotationMode = AnnotationMode.ENABLE;
|
2021-12-12 00:53:59 +09:00
|
|
|
}
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
|
|
|
|
return params;
|
2021-12-12 00:23:29 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
#onePageRenderedOrForceFetch() {
|
2020-03-24 20:58:34 +09:00
|
|
|
// Unless the viewer *and* its pages are visible, rendering won't start and
|
|
|
|
// `this._onePageRenderedCapability` thus won't be resolved.
|
|
|
|
// To ensure that automatic printing, on document load, still works even in
|
|
|
|
// those cases we force-allow fetching of all pages when:
|
2021-12-19 03:04:38 +09:00
|
|
|
// - The current window/tab is inactive, which will prevent rendering since
|
|
|
|
// `requestAnimationFrame` is being used; fixes bug 1746213.
|
2020-03-24 20:58:34 +09:00
|
|
|
// - The viewer is hidden in the DOM, e.g. in a `display: none` <iframe>
|
|
|
|
// element; fixes bug 1618621.
|
|
|
|
// - The viewer is visible, but none of the pages are (e.g. if the
|
|
|
|
// viewer is very small); fixes bug 1618955.
|
|
|
|
if (
|
2021-12-19 03:04:38 +09:00
|
|
|
document.visibilityState === "hidden" ||
|
2020-03-24 20:58:34 +09:00
|
|
|
!this.container.offsetParent ||
|
|
|
|
this._getVisiblePages().views.length === 0
|
|
|
|
) {
|
|
|
|
return Promise.resolve();
|
|
|
|
}
|
2021-12-19 05:25:31 +09:00
|
|
|
|
|
|
|
// Handle the window/tab becoming inactive *after* rendering has started;
|
|
|
|
// fixes (another part of) bug 1746213.
|
|
|
|
const visibilityChangePromise = new Promise(resolve => {
|
|
|
|
this.#onVisibilityChange = () => {
|
|
|
|
if (document.visibilityState !== "hidden") {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
resolve();
|
|
|
|
|
|
|
|
document.removeEventListener(
|
|
|
|
"visibilitychange",
|
|
|
|
this.#onVisibilityChange
|
|
|
|
);
|
|
|
|
this.#onVisibilityChange = null;
|
|
|
|
};
|
|
|
|
document.addEventListener("visibilitychange", this.#onVisibilityChange);
|
|
|
|
});
|
|
|
|
|
|
|
|
return Promise.race([
|
|
|
|
this._onePageRenderedCapability.promise,
|
|
|
|
visibilityChangePromise,
|
|
|
|
]);
|
2020-03-24 20:58:34 +09:00
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2021-12-15 07:59:17 +09:00
|
|
|
* @param {PDFDocumentProxy} pdfDocument
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
setDocument(pdfDocument) {
|
|
|
|
if (this.pdfDocument) {
|
2020-12-16 01:20:15 +09:00
|
|
|
this.eventBus.dispatch("pagesdestroy", { source: this });
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
this._cancelRendering();
|
|
|
|
this._resetView();
|
Make `PDFFindController` less confusing to use, by allowing searching to start when `setDocument` is called
*This patch is based on something that I noticed while working on PR 10126.*
The recent re-factoring of `PDFFindController` brought many improvements, among those the fact that access to `BaseViewer` is no longer required. However, with these changes there's one thing which now strikes me as not particularly user-friendly[1]: The fact that in order for searching to actually work, `PDFFindController.setDocument` must be called *and* a 'pagesinit' event must be dispatched (from somewhere).
For all other viewer components, calling the `setDocument` method[2] is enough in order for the component to actually be usable.
The `PDFFindController` thus stands out quite a bit, and it also becomes difficult to work with in any sort of custom implementation. For example: Imagine someone trying to use `PDFFindController` separately from the viewer[3], which *should* now be relatively simple given the re-factoring, and thus having to (somehow) figure out that they'll also need to manually dispatch a 'pagesinit' event for searching to work.
Note that the above even affects the unit-tests, where an out-of-place 'pagesinit' event is being used.
To attempt to address these problems, I'm thus suggesting that *only* `setDocument` should be used to indicate that searching may start. For the default viewer and/or the viewer components, `BaseViewer.setDocument` will now call `PDFFindController.setDocument` when the document is ready, thus requiring no outside configuration anymore[4]. For custom implementation, and the unit-tests, it's now as simple as just calling `PDFFindController.setDocument` to allow searching to start.
---
[1] I should have caught this during review of PR 10099, but unfortunately it's sometimes not until you actually work with the code in question that things like these become clear.
[2] Assuming, obviously, that the viewer component in question actually implements such a method :-)
[3] There's even a very recent issue, filed by someone trying to do just that.
[4] Short of providing a `PDFFindController` instance when creating a `BaseViewer` instance, of course.
2018-10-03 19:42:41 +09:00
|
|
|
|
2022-09-05 22:36:04 +09:00
|
|
|
this.findController?.setDocument(null);
|
|
|
|
this._scriptingManager?.setDocument(null);
|
|
|
|
|
2022-07-05 01:04:32 +09:00
|
|
|
if (this.#annotationEditorUIManager) {
|
|
|
|
this.#annotationEditorUIManager.destroy();
|
|
|
|
this.#annotationEditorUIManager = null;
|
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
this.pdfDocument = pdfDocument;
|
|
|
|
if (!pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
2019-12-27 08:22:32 +09:00
|
|
|
const pagesCount = pdfDocument.numPages;
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
const firstPagePromise = pdfDocument.getPage(1);
|
Some `hasJSActions`, and general annotation-code, related cleanup in the viewer and API
- Add support for logical assignment operators, i.e. `&&=`, `||=`, and `??=`, with a Babel-plugin. Given that these required incrementing the ECMAScript version in the ESLint and Acorn configurations, and that platform/browser support is still fairly limited, always transpiling them seems appropriate for now.
- Cache the `hasJSActions` promise in the API, similar to the existing `getAnnotations` caching. With this implemented, the lookup should now be cheap enough that it can be called unconditionally in the viewer.
- Slightly improve cleanup of resources when destroying the `WorkerTransport`.
- Remove the `annotationStorage`-property from the `PDFPageView` constructor, since it's not necessary and also brings it more inline with the `BaseViewer`.
- Update the `BaseViewer.createAnnotationLayerBuilder` method to actaually agree with the `IPDFAnnotationLayerFactory` interface.[1]
- Slightly tweak a couple of JSDoc comments.
---
[1] We probably ought to re-factor both the `IPDFTextLayerFactory` and `IPDFAnnotationLayerFactory` interfaces to take parameter objects instead, since especially the `IPDFAnnotationLayerFactory` one is becoming quite unwieldy. Given that that would likely be a breaking change for any custom viewer-components implementation, this probably requires careful deprecation.
2020-11-14 21:38:36 +09:00
|
|
|
// Rendering (potentially) depends on this, hence fetching it immediately.
|
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096)
*Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.)
By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature.
Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar.
(Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.)
Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime.
To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which:
- Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive.
- Uses a slightly different formatting, compared to the "regular" headings.
- Is localizable.
Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers.
To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
|
|
|
const optionalContentConfigPromise = pdfDocument.getOptionalContentConfig();
|
2021-12-12 04:41:41 +09:00
|
|
|
const permissionsPromise = this.#enablePermissions
|
|
|
|
? pdfDocument.getPermissions()
|
|
|
|
: Promise.resolve();
|
2020-08-05 19:57:32 +09:00
|
|
|
|
Enforce PAGE-scrolling for *very* large/long documents (bug 1588435, PR 11263 follow-up)
This patch is essentially a continuation of PR 11263, which tried to improve loading/initialization performance of *very* large/long documents.
Note that browsers, in general, don't handle a huge amount of DOM-elements very well, with really poor (e.g. sluggish scrolling) performance once the number gets "large". Furthermore, at least in Firefox, it seems that DOM-elements towards the bottom of a HTML-page can effectively be ignored; for the PDF.js viewer that means that pages at the end of the document can become impossible to access.
Hence, in order to improve things for these *very* large/long documents, this patch will now enforce usage of the (recently added) PAGE-scrolling mode for these documents. As implemented, this will only happen once the number of pages *exceed* 15000 (which is hopefully rare in practice).
While this might feel a bit jarring to users being *forced* to use PAGE-scrolling, it seems all things considered like a better idea to ensure that the entire document actually remains accessible and with (hopefully) more acceptable performance.
Fixes [bug 1588435](https://bugzilla.mozilla.org/show_bug.cgi?id=1588435), to the extent that doing so is possible since the document contains 25560 pages (and is 197 MB large).
2021-11-29 02:43:30 +09:00
|
|
|
// Given that browsers don't handle huge amounts of DOM-elements very well,
|
|
|
|
// enforce usage of PAGE-scrolling when loading *very* long/large documents.
|
|
|
|
if (pagesCount > PagesCountLimit.FORCE_SCROLL_MODE_PAGE) {
|
|
|
|
console.warn(
|
|
|
|
"Forcing PAGE-scrolling for performance reasons, given the length of the document."
|
|
|
|
);
|
|
|
|
const mode = (this._scrollMode = ScrollMode.PAGE);
|
|
|
|
this.eventBus.dispatch("scrollmodechanged", { source: this, mode });
|
|
|
|
}
|
|
|
|
|
2021-12-05 00:40:48 +09:00
|
|
|
this._pagesCapability.promise.then(
|
|
|
|
() => {
|
|
|
|
this.eventBus.dispatch("pagesloaded", { source: this, pagesCount });
|
|
|
|
},
|
|
|
|
() => {
|
|
|
|
/* Prevent "Uncaught (in promise)"-messages in the console. */
|
|
|
|
}
|
|
|
|
);
|
2017-07-09 20:07:06 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this._onBeforeDraw = evt => {
|
2019-07-19 19:40:49 +09:00
|
|
|
const pageView = this._pages[evt.pageNumber - 1];
|
|
|
|
if (!pageView) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Add the page to the buffer at the start of drawing. That way it can be
|
|
|
|
// evicted from the buffer and destroyed even if we pause its rendering.
|
2021-11-06 18:09:59 +09:00
|
|
|
this.#buffer.push(pageView);
|
2017-07-09 20:07:06 +09:00
|
|
|
};
|
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated
Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples:
The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first.
However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact.
Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page).
---
[1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes).
In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference.
[2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
|
|
|
this.eventBus._on("pagerender", this._onBeforeDraw);
|
2015-02-20 01:30:47 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this._onAfterDraw = evt => {
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
if (evt.cssTransform || this._onePageRenderedCapability.settled) {
|
2019-07-19 19:40:49 +09:00
|
|
|
return;
|
|
|
|
}
|
2021-11-11 20:36:06 +09:00
|
|
|
this._onePageRenderedCapability.resolve({ timestamp: evt.timestamp });
|
2019-07-19 19:40:49 +09:00
|
|
|
|
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated
Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples:
The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first.
However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact.
Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page).
---
[1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes).
In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference.
[2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
|
|
|
this.eventBus._off("pagerendered", this._onAfterDraw);
|
2019-07-19 19:40:49 +09:00
|
|
|
this._onAfterDraw = null;
|
2021-12-19 05:25:31 +09:00
|
|
|
|
|
|
|
if (this.#onVisibilityChange) {
|
|
|
|
document.removeEventListener(
|
|
|
|
"visibilitychange",
|
|
|
|
this.#onVisibilityChange
|
|
|
|
);
|
|
|
|
this.#onVisibilityChange = null;
|
|
|
|
}
|
2019-07-19 19:40:49 +09:00
|
|
|
};
|
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated
Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples:
The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first.
However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact.
Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page).
---
[1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes).
In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference.
[2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
|
|
|
this.eventBus._on("pagerendered", this._onAfterDraw);
|
2017-07-09 20:07:06 +09:00
|
|
|
|
|
|
|
// Fetch a single page so we can get a viewport that will be the default
|
|
|
|
// viewport for all pages
|
2021-12-12 00:23:29 +09:00
|
|
|
Promise.all([firstPagePromise, permissionsPromise])
|
|
|
|
.then(([firstPdfPage, permissions]) => {
|
2021-12-14 20:18:12 +09:00
|
|
|
if (pdfDocument !== this.pdfDocument) {
|
|
|
|
return; // The document was closed while the first page resolved.
|
|
|
|
}
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
this._firstPageCapability.resolve(firstPdfPage);
|
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096)
*Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.)
By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature.
Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar.
(Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.)
Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime.
To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which:
- Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive.
- Uses a slightly different formatting, compared to the "regular" headings.
- Is localizable.
Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers.
To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
|
|
|
this._optionalContentConfigPromise = optionalContentConfigPromise;
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
|
|
|
|
const { annotationEditorMode, annotationMode, textLayerMode } =
|
|
|
|
this.#initializePermissions(permissions);
|
|
|
|
|
2022-06-29 18:13:03 +09:00
|
|
|
if (annotationEditorMode !== AnnotationEditorType.DISABLE) {
|
|
|
|
const mode = annotationEditorMode;
|
|
|
|
|
2022-12-06 21:38:19 +09:00
|
|
|
if (pdfDocument.isPureXfa) {
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
console.warn("Warning: XFA-editing is not implemented.");
|
2022-06-29 18:13:03 +09:00
|
|
|
} else if (isValidAnnotationEditorMode(mode)) {
|
2022-06-14 01:23:10 +09:00
|
|
|
this.#annotationEditorUIManager = new AnnotationEditorUIManager(
|
2022-07-20 03:54:17 +09:00
|
|
|
this.container,
|
2022-12-05 20:25:06 +09:00
|
|
|
this.eventBus,
|
2022-12-06 21:38:19 +09:00
|
|
|
pdfDocument?.annotationStorage
|
2022-06-14 01:23:10 +09:00
|
|
|
);
|
2022-06-29 18:13:03 +09:00
|
|
|
if (mode !== AnnotationEditorType.NONE) {
|
|
|
|
this.#annotationEditorUIManager.updateMode(mode);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
console.error(`Invalid AnnotationEditor mode: ${mode}`);
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
}
|
|
|
|
}
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
|
[api-minor] Remove the `annotationEditorLayerFactory` in the viewer
Please note that this functionality has never really mattered for the Firefox PDF Viewer, the GENERIC viewer, or even the "simpleviewer"/"singlepageviewer" component-examples. Hence, in practice this means that only the "pageviewer" component-example[1] have ever really utilized this.
Using factories to initialize various layers in the viewer, rather than simply invoking the relevant code directly, seems (at least to me) like a somewhat roundabout way of doing things.
Not only does this lead to more code, both to write and maintain, but since many of the layers have common parameters (e.g. an `AnnotationStorage`-instance) there's also some duplication.
Hence this patch, which removes the `annotationEditorLayerFactory` and instead uses a lookup-function in the `PDFPageView`-class to access the external viewer-properties as necessary.
Note that this should even be an improvement for the "pageviewer" component-example, since most layers will now work by default rather than require manual configuration.
---
[1] In practice we generally suggest using the "simpleviewer", or "singlepageviewer", since it does *most* things out-of-the-box and given that a lot of functionality really require *a viewer* and not just a single page in order to work.
2022-12-06 22:21:51 +09:00
|
|
|
const layerProperties = this.#layerProperties.bind(this);
|
2021-10-07 21:04:41 +09:00
|
|
|
const viewerElement =
|
2021-10-28 18:57:27 +09:00
|
|
|
this._scrollMode === ScrollMode.PAGE ? null : this.viewer;
|
2019-12-27 08:22:32 +09:00
|
|
|
const scale = this.currentScale;
|
2021-09-20 17:10:57 +09:00
|
|
|
const viewport = firstPdfPage.getViewport({
|
|
|
|
scale: scale * PixelsPerInch.PDF_TO_CSS_UNITS,
|
|
|
|
});
|
2022-12-09 22:30:12 +09:00
|
|
|
// Ensure that the various layers always get the correct initial size,
|
|
|
|
// see issue 15795.
|
2023-01-17 03:38:33 +09:00
|
|
|
this.viewer.style.setProperty("--scale-factor", viewport.scale);
|
2022-12-09 22:30:12 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
for (let pageNum = 1; pageNum <= pagesCount; ++pageNum) {
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageView = new PDFPageView({
|
2021-10-07 21:04:41 +09:00
|
|
|
container: viewerElement,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
eventBus: this.eventBus,
|
|
|
|
id: pageNum,
|
|
|
|
scale,
|
|
|
|
defaultViewport: viewport.clone(),
|
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096)
*Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.)
By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature.
Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar.
(Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.)
Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime.
To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which:
- Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive.
- Uses a slightly different formatting, compared to the "regular" headings.
- Is localizable.
Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers.
To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
|
|
|
optionalContentConfigPromise,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
renderingQueue: this.renderingQueue,
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
textLayerMode,
|
|
|
|
annotationMode,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
imageResourcesPath: this.imageResourcesPath,
|
2022-07-19 20:41:01 +09:00
|
|
|
renderer:
|
|
|
|
typeof PDFJSDev === "undefined" ||
|
|
|
|
PDFJSDev.test("!PRODUCTION || GENERIC")
|
|
|
|
? this.renderer
|
|
|
|
: null,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
useOnlyCssZoom: this.useOnlyCssZoom,
|
2022-11-22 01:15:39 +09:00
|
|
|
isOffscreenCanvasSupported: this.isOffscreenCanvasSupported,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
maxCanvasPixels: this.maxCanvasPixels,
|
2022-05-04 22:37:13 +09:00
|
|
|
pageColors: this.pageColors,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
l10n: this.l10n,
|
[api-minor] Remove the `annotationEditorLayerFactory` in the viewer
Please note that this functionality has never really mattered for the Firefox PDF Viewer, the GENERIC viewer, or even the "simpleviewer"/"singlepageviewer" component-examples. Hence, in practice this means that only the "pageviewer" component-example[1] have ever really utilized this.
Using factories to initialize various layers in the viewer, rather than simply invoking the relevant code directly, seems (at least to me) like a somewhat roundabout way of doing things.
Not only does this lead to more code, both to write and maintain, but since many of the layers have common parameters (e.g. an `AnnotationStorage`-instance) there's also some duplication.
Hence this patch, which removes the `annotationEditorLayerFactory` and instead uses a lookup-function in the `PDFPageView`-class to access the external viewer-properties as necessary.
Note that this should even be an improvement for the "pageviewer" component-example, since most layers will now work by default rather than require manual configuration.
---
[1] In practice we generally suggest using the "simpleviewer", or "singlepageviewer", since it does *most* things out-of-the-box and given that a lot of functionality really require *a viewer* and not just a single page in order to work.
2022-12-06 22:21:51 +09:00
|
|
|
layerProperties,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
});
|
|
|
|
this._pages.push(pageView);
|
2014-09-13 11:27:45 +09:00
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
// Set the first `pdfPage` immediately, since it's already loaded,
|
|
|
|
// rather than having to repeat the `PDFDocumentProxy.getPage` call in
|
2021-11-21 02:24:12 +09:00
|
|
|
// the `this.#ensurePdfPageLoaded` method before rendering can start.
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
const firstPageView = this._pages[0];
|
|
|
|
if (firstPageView) {
|
|
|
|
firstPageView.setPdfPage(firstPdfPage);
|
|
|
|
this.linkService.cachePageRef(1, firstPdfPage.ref);
|
2019-07-07 00:23:43 +09:00
|
|
|
}
|
2021-10-07 21:04:41 +09:00
|
|
|
|
|
|
|
if (this._scrollMode === ScrollMode.PAGE) {
|
2021-11-16 23:16:59 +09:00
|
|
|
// Ensure that the current page becomes visible on document load.
|
|
|
|
this.#ensurePageViewVisible();
|
2021-10-07 21:04:41 +09:00
|
|
|
} else if (this._spreadMode !== SpreadMode.NONE) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this._updateSpreadMode();
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2019-12-01 20:21:47 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
// Fetch all the pages since the viewport is needed before printing
|
|
|
|
// starts to create the correct size canvas. Wait until one page is
|
|
|
|
// rendered so we don't tie up too many resources early on.
|
2021-12-12 00:23:29 +09:00
|
|
|
this.#onePageRenderedOrForceFetch().then(async () => {
|
2022-09-05 22:36:04 +09:00
|
|
|
this.findController?.setDocument(pdfDocument); // Enable searching.
|
|
|
|
this._scriptingManager?.setDocument(pdfDocument); // Enable scripting.
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
|
2022-08-10 01:34:05 +09:00
|
|
|
if (this.#annotationEditorUIManager) {
|
|
|
|
// Ensure that the Editor buttons, in the toolbar, are updated.
|
|
|
|
this.eventBus.dispatch("annotationeditormodechanged", {
|
|
|
|
source: this,
|
|
|
|
mode: this.#annotationEditorMode,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
// In addition to 'disableAutoFetch' being set, also attempt to reduce
|
|
|
|
// resource usage when loading *very* long/large documents.
|
Enforce PAGE-scrolling for *very* large/long documents (bug 1588435, PR 11263 follow-up)
This patch is essentially a continuation of PR 11263, which tried to improve loading/initialization performance of *very* large/long documents.
Note that browsers, in general, don't handle a huge amount of DOM-elements very well, with really poor (e.g. sluggish scrolling) performance once the number gets "large". Furthermore, at least in Firefox, it seems that DOM-elements towards the bottom of a HTML-page can effectively be ignored; for the PDF.js viewer that means that pages at the end of the document can become impossible to access.
Hence, in order to improve things for these *very* large/long documents, this patch will now enforce usage of the (recently added) PAGE-scrolling mode for these documents. As implemented, this will only happen once the number of pages *exceed* 15000 (which is hopefully rare in practice).
While this might feel a bit jarring to users being *forced* to use PAGE-scrolling, it seems all things considered like a better idea to ensure that the entire document actually remains accessible and with (hopefully) more acceptable performance.
Fixes [bug 1588435](https://bugzilla.mozilla.org/show_bug.cgi?id=1588435), to the extent that doing so is possible since the document contains 25560 pages (and is 197 MB large).
2021-11-29 02:43:30 +09:00
|
|
|
if (
|
|
|
|
pdfDocument.loadingParams.disableAutoFetch ||
|
|
|
|
pagesCount > PagesCountLimit.FORCE_LAZY_PAGE_INIT
|
|
|
|
) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
// XXX: Printing is semi-broken with auto fetch disabled.
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
this._pagesCapability.resolve();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
let getPagesLeft = pagesCount - 1; // The first page was already loaded.
|
|
|
|
|
|
|
|
if (getPagesLeft <= 0) {
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
this._pagesCapability.resolve();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (let pageNum = 2; pageNum <= pagesCount; ++pageNum) {
|
Avoid overloading the worker-thread during eager page initialization in the viewer (PR 11263 follow-up)
This patch is essentially *another* continuation of PR 11263, which tried to improve loading/initialization performance of *very* large/long documents.
For most documents, unless they're *very* long, we'll eagerly initialize all of the pages in the viewer. For shorter documents having all pages loaded/initialized early provides overall better performance/UX in the viewer, however there's cases where it can instead *hurt* performance.
For documents with a couple of thousand pages[1], the parsing and pre-rendering of the *second* page of the document can be delayed (quite a bit). The reason for this is that we trigger `PDFDocumentProxy.getPage` for *all pages* early during the viewer initialization, which causes the worker-thread to be swamped with handling (potentially) thousands of `getPage`-calls and leaving very little time for other parsing (such as e.g. of operatorLists).
To address this situation, this patch thus proposes temporarily "pausing" the eager `PDFDocumentProxy.getPage`-calls once a threshold has been reached, to give the worker-thread a change to handle other requests.[2]
Obviously this may *slightly* delay the "pagesloaded" event in longer documents, but considering that it's already the result of asynchronous parsing that'll hopefully not be seen as a blocker for these changes.[3]
---
[1] A particularly problematic example is https://github.com/mozilla/pdf.js/files/876321/kjv.pdf (16 MB large), which is a document with 2236 pages and a /Pages-tree that's only *one* level deep.
[2] Please note that I initially considered simply chaining the `PDFDocumentProxy.getPage`-calls, however that'd slowed things down for all documents which didn't seem appropriate.
[3] This patch will *hopefully* also make it possible to re-visit PR 11312, since it seems that changing `Catalog.getPageDict` to an `async` method wasn't the problem in itself. Rather it appears that it leads to slightly different timings, thus exacerbating the already existing issues with the worker-thread being overloaded by `getPage`-calls.
Having recently worked with that method, there's a couple of (very old) issues that I'd also like to address and having `Catalog.getPageDict` be `async` would simplify things a great deal.
2021-12-11 01:14:58 +09:00
|
|
|
const promise = pdfDocument.getPage(pageNum).then(
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
pdfPage => {
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageView = this._pages[pageNum - 1];
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
if (!pageView.pdfPage) {
|
|
|
|
pageView.setPdfPage(pdfPage);
|
|
|
|
}
|
|
|
|
this.linkService.cachePageRef(pageNum, pdfPage.ref);
|
|
|
|
if (--getPagesLeft === 0) {
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
this._pagesCapability.resolve();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
}
|
|
|
|
},
|
|
|
|
reason => {
|
|
|
|
console.error(
|
|
|
|
`Unable to get page ${pageNum} to initialize viewer`,
|
|
|
|
reason
|
|
|
|
);
|
|
|
|
if (--getPagesLeft === 0) {
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
this._pagesCapability.resolve();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
);
|
Avoid overloading the worker-thread during eager page initialization in the viewer (PR 11263 follow-up)
This patch is essentially *another* continuation of PR 11263, which tried to improve loading/initialization performance of *very* large/long documents.
For most documents, unless they're *very* long, we'll eagerly initialize all of the pages in the viewer. For shorter documents having all pages loaded/initialized early provides overall better performance/UX in the viewer, however there's cases where it can instead *hurt* performance.
For documents with a couple of thousand pages[1], the parsing and pre-rendering of the *second* page of the document can be delayed (quite a bit). The reason for this is that we trigger `PDFDocumentProxy.getPage` for *all pages* early during the viewer initialization, which causes the worker-thread to be swamped with handling (potentially) thousands of `getPage`-calls and leaving very little time for other parsing (such as e.g. of operatorLists).
To address this situation, this patch thus proposes temporarily "pausing" the eager `PDFDocumentProxy.getPage`-calls once a threshold has been reached, to give the worker-thread a change to handle other requests.[2]
Obviously this may *slightly* delay the "pagesloaded" event in longer documents, but considering that it's already the result of asynchronous parsing that'll hopefully not be seen as a blocker for these changes.[3]
---
[1] A particularly problematic example is https://github.com/mozilla/pdf.js/files/876321/kjv.pdf (16 MB large), which is a document with 2236 pages and a /Pages-tree that's only *one* level deep.
[2] Please note that I initially considered simply chaining the `PDFDocumentProxy.getPage`-calls, however that'd slowed things down for all documents which didn't seem appropriate.
[3] This patch will *hopefully* also make it possible to re-visit PR 11312, since it seems that changing `Catalog.getPageDict` to an `async` method wasn't the problem in itself. Rather it appears that it leads to slightly different timings, thus exacerbating the already existing issues with the worker-thread being overloaded by `getPage`-calls.
Having recently worked with that method, there's a couple of (very old) issues that I'd also like to address and having `Catalog.getPageDict` be `async` would simplify things a great deal.
2021-12-11 01:14:58 +09:00
|
|
|
|
|
|
|
if (pageNum % PagesCountLimit.PAUSE_EAGER_PAGE_INIT === 0) {
|
|
|
|
await promise;
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
}
|
|
|
|
});
|
2017-07-09 20:07:06 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("pagesinit", { source: this });
|
2015-07-01 04:49:32 +09:00
|
|
|
|
2021-12-14 20:18:12 +09:00
|
|
|
pdfDocument.getMetadata().then(({ info }) => {
|
|
|
|
if (pdfDocument !== this.pdfDocument) {
|
|
|
|
return; // The document was closed while the metadata resolved.
|
|
|
|
}
|
|
|
|
if (info.Language) {
|
|
|
|
this.viewer.lang = info.Language;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
if (this.defaultRenderingQueue) {
|
|
|
|
this.update();
|
|
|
|
}
|
|
|
|
})
|
|
|
|
.catch(reason => {
|
|
|
|
console.error("Unable to initialize viewer", reason);
|
2021-12-05 00:40:48 +09:00
|
|
|
|
|
|
|
this._pagesCapability.reject(reason);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
});
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2016-05-05 01:06:07 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* @param {Array|null} labels
|
|
|
|
*/
|
|
|
|
setPageLabels(labels) {
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!labels) {
|
|
|
|
this._pageLabels = null;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
} else if (
|
|
|
|
!(Array.isArray(labels) && this.pdfDocument.numPages === labels.length)
|
|
|
|
) {
|
2017-07-09 20:07:06 +09:00
|
|
|
this._pageLabels = null;
|
2021-08-09 19:05:50 +09:00
|
|
|
console.error(`setPageLabels: Invalid page labels.`);
|
2017-07-09 20:07:06 +09:00
|
|
|
} else {
|
|
|
|
this._pageLabels = labels;
|
|
|
|
}
|
|
|
|
// Update all the `PDFPageView` instances.
|
|
|
|
for (let i = 0, ii = this._pages.length; i < ii; i++) {
|
2021-02-06 00:24:39 +09:00
|
|
|
this._pages[i].setPageLabel(this._pageLabels?.[i] ?? null);
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
}
|
2015-11-24 00:57:43 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
_resetView() {
|
|
|
|
this._pages = [];
|
|
|
|
this._currentPageNumber = 1;
|
|
|
|
this._currentScale = UNKNOWN_SCALE;
|
|
|
|
this._currentScaleValue = null;
|
|
|
|
this._pageLabels = null;
|
2021-11-06 18:09:59 +09:00
|
|
|
this.#buffer = new PDFPageViewBuffer(DEFAULT_CACHE_SIZE);
|
2017-07-09 20:07:06 +09:00
|
|
|
this._location = null;
|
|
|
|
this._pagesRotation = 0;
|
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096)
*Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.)
By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature.
Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar.
(Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.)
Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime.
To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which:
- Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive.
- Uses a slightly different formatting, compared to the "regular" headings.
- Is localizable.
Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers.
To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
|
|
|
this._optionalContentConfigPromise = null;
|
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality
There's a couple of issues with this functionality:
- The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state.
- While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`).
- There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid.
*Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called.
While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
|
|
|
this._firstPageCapability = createPromiseCapability();
|
|
|
|
this._onePageRenderedCapability = createPromiseCapability();
|
|
|
|
this._pagesCapability = createPromiseCapability();
|
2018-06-29 22:48:45 +09:00
|
|
|
this._scrollMode = ScrollMode.VERTICAL;
|
2021-10-07 21:04:41 +09:00
|
|
|
this._previousScrollMode = ScrollMode.UNKNOWN;
|
2018-06-29 22:48:45 +09:00
|
|
|
this._spreadMode = SpreadMode.NONE;
|
2017-07-09 20:07:06 +09:00
|
|
|
|
2021-10-28 18:57:27 +09:00
|
|
|
this.#scrollModePageState = {
|
2021-10-07 21:04:41 +09:00
|
|
|
previousPageNumber: 1,
|
|
|
|
scrollDown: true,
|
|
|
|
pages: [],
|
|
|
|
};
|
|
|
|
|
2019-07-19 19:40:49 +09:00
|
|
|
if (this._onBeforeDraw) {
|
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated
Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples:
The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first.
However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact.
Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page).
---
[1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes).
In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference.
[2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
|
|
|
this.eventBus._off("pagerender", this._onBeforeDraw);
|
2019-07-19 19:40:49 +09:00
|
|
|
this._onBeforeDraw = null;
|
|
|
|
}
|
|
|
|
if (this._onAfterDraw) {
|
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated
Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples:
The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first.
However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact.
Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page).
---
[1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes).
In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference.
[2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
|
|
|
this.eventBus._off("pagerendered", this._onAfterDraw);
|
2019-07-19 19:40:49 +09:00
|
|
|
this._onAfterDraw = null;
|
|
|
|
}
|
2021-12-19 05:25:31 +09:00
|
|
|
if (this.#onVisibilityChange) {
|
|
|
|
document.removeEventListener(
|
|
|
|
"visibilitychange",
|
|
|
|
this.#onVisibilityChange
|
|
|
|
);
|
|
|
|
this.#onVisibilityChange = null;
|
|
|
|
}
|
2018-06-29 22:48:45 +09:00
|
|
|
// Remove the pages from the DOM...
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.viewer.textContent = "";
|
2018-06-29 22:48:45 +09:00
|
|
|
// ... and reset the Scroll mode CSS class(es) afterwards.
|
|
|
|
this._updateScrollMode();
|
2021-12-12 00:23:29 +09:00
|
|
|
|
2021-12-14 20:18:12 +09:00
|
|
|
this.viewer.removeAttribute("lang");
|
2021-12-12 00:23:29 +09:00
|
|
|
// Reset all PDF document permissions.
|
|
|
|
this.viewer.classList.remove(ENABLE_PERMISSIONS_CLASS);
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
|
2021-11-16 23:16:59 +09:00
|
|
|
#ensurePageViewVisible() {
|
2021-10-07 21:04:41 +09:00
|
|
|
if (this._scrollMode !== ScrollMode.PAGE) {
|
2021-11-16 23:16:59 +09:00
|
|
|
throw new Error("#ensurePageViewVisible: Invalid scrollMode value.");
|
2021-10-07 21:04:41 +09:00
|
|
|
}
|
|
|
|
const pageNumber = this._currentPageNumber,
|
2021-10-28 18:57:27 +09:00
|
|
|
state = this.#scrollModePageState,
|
2021-10-07 21:04:41 +09:00
|
|
|
viewer = this.viewer;
|
|
|
|
|
2021-10-28 18:57:27 +09:00
|
|
|
// Temporarily remove all the pages from the DOM...
|
|
|
|
viewer.textContent = "";
|
|
|
|
// ... and clear out the active ones.
|
2021-10-07 21:04:41 +09:00
|
|
|
state.pages.length = 0;
|
|
|
|
|
2022-05-03 20:14:17 +09:00
|
|
|
if (this._spreadMode === SpreadMode.NONE && !this.isInPresentationMode) {
|
2021-10-07 21:04:41 +09:00
|
|
|
// Finally, append the new page to the viewer.
|
|
|
|
const pageView = this._pages[pageNumber - 1];
|
2022-06-12 19:20:25 +09:00
|
|
|
viewer.append(pageView.div);
|
2021-10-07 21:04:41 +09:00
|
|
|
|
|
|
|
state.pages.push(pageView);
|
|
|
|
} else {
|
|
|
|
const pageIndexSet = new Set(),
|
|
|
|
parity = this._spreadMode - 1;
|
|
|
|
|
|
|
|
// Determine the pageIndices in the new spread.
|
2022-05-03 20:14:17 +09:00
|
|
|
if (parity === -1) {
|
|
|
|
// PresentationMode is active, with `SpreadMode.NONE` set.
|
|
|
|
pageIndexSet.add(pageNumber - 1);
|
|
|
|
} else if (pageNumber % 2 !== parity) {
|
2021-10-07 21:04:41 +09:00
|
|
|
// Left-hand side page.
|
|
|
|
pageIndexSet.add(pageNumber - 1);
|
|
|
|
pageIndexSet.add(pageNumber);
|
|
|
|
} else {
|
|
|
|
// Right-hand side page.
|
|
|
|
pageIndexSet.add(pageNumber - 2);
|
|
|
|
pageIndexSet.add(pageNumber - 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, append the new pages to the viewer and apply the spreadMode.
|
2022-04-17 17:53:34 +09:00
|
|
|
const spread = document.createElement("div");
|
|
|
|
spread.className = "spread";
|
|
|
|
|
2022-05-03 20:14:17 +09:00
|
|
|
if (this.isInPresentationMode) {
|
|
|
|
const dummyPage = document.createElement("div");
|
|
|
|
dummyPage.className = "dummyPage";
|
2022-06-12 19:20:25 +09:00
|
|
|
spread.append(dummyPage);
|
2022-05-03 20:14:17 +09:00
|
|
|
}
|
|
|
|
|
2021-11-16 23:16:59 +09:00
|
|
|
for (const i of pageIndexSet) {
|
|
|
|
const pageView = this._pages[i];
|
|
|
|
if (!pageView) {
|
2021-10-07 21:04:41 +09:00
|
|
|
continue;
|
|
|
|
}
|
2022-06-12 19:20:25 +09:00
|
|
|
spread.append(pageView.div);
|
2021-10-07 21:04:41 +09:00
|
|
|
|
|
|
|
state.pages.push(pageView);
|
|
|
|
}
|
2022-06-12 19:20:25 +09:00
|
|
|
viewer.append(spread);
|
2021-10-07 21:04:41 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
state.scrollDown = pageNumber >= state.previousPageNumber;
|
|
|
|
state.previousPageNumber = pageNumber;
|
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
_scrollUpdate() {
|
|
|
|
if (this.pagesCount === 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
this.update();
|
|
|
|
}
|
|
|
|
|
2022-05-04 18:35:04 +09:00
|
|
|
#scrollIntoView(pageView, pageSpot = null) {
|
|
|
|
const { div, id } = pageView;
|
|
|
|
|
2022-11-22 18:37:24 +09:00
|
|
|
// Ensure that `this._currentPageNumber` is correct, when `#scrollIntoView`
|
|
|
|
// is called directly (and not from `#resetCurrentPageView`).
|
|
|
|
if (this._currentPageNumber !== id) {
|
2022-05-04 18:35:04 +09:00
|
|
|
this._setCurrentPageNumber(id);
|
2022-11-22 18:37:24 +09:00
|
|
|
}
|
|
|
|
if (this._scrollMode === ScrollMode.PAGE) {
|
2021-11-16 23:16:59 +09:00
|
|
|
this.#ensurePageViewVisible();
|
2021-10-07 21:04:41 +09:00
|
|
|
// Ensure that rendering always occurs, to avoid showing a blank page,
|
|
|
|
// even if the current position doesn't change when the page is scrolled.
|
|
|
|
this.update();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!pageSpot && !this.isInPresentationMode) {
|
2022-05-04 18:35:04 +09:00
|
|
|
const left = div.offsetLeft + div.clientLeft,
|
|
|
|
right = left + div.clientWidth;
|
2021-10-07 21:04:41 +09:00
|
|
|
const { scrollLeft, clientWidth } = this.container;
|
|
|
|
if (
|
|
|
|
this._scrollMode === ScrollMode.HORIZONTAL ||
|
|
|
|
left < scrollLeft ||
|
|
|
|
right > scrollLeft + clientWidth
|
|
|
|
) {
|
|
|
|
pageSpot = { left: 0, top: 0 };
|
|
|
|
}
|
|
|
|
}
|
2022-05-04 18:35:04 +09:00
|
|
|
scrollIntoView(div, pageSpot);
|
2022-11-22 18:37:24 +09:00
|
|
|
|
|
|
|
// Ensure that the correct *initial* document position is set, when any
|
|
|
|
// OpenParameters are used, for documents with non-default Scroll/Spread
|
|
|
|
// modes (fixes issue 15695). This is necessary since the scroll-handler
|
|
|
|
// invokes the `update`-method asynchronously, and `this._location` could
|
|
|
|
// thus be wrong when the initial zooming occurs in the default viewer.
|
|
|
|
if (!this._currentScaleValue && this._location) {
|
|
|
|
this._location = null;
|
|
|
|
}
|
2017-08-01 21:11:28 +09:00
|
|
|
}
|
|
|
|
|
2021-11-23 21:29:00 +09:00
|
|
|
/**
|
|
|
|
* Prevent unnecessary re-rendering of all pages when the scale changes
|
|
|
|
* only because of limited numerical precision.
|
|
|
|
*/
|
|
|
|
#isSameScale(newScale) {
|
|
|
|
return (
|
|
|
|
newScale === this._currentScale ||
|
|
|
|
Math.abs(newScale - this._currentScale) < 1e-15
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2023-03-23 17:00:54 +09:00
|
|
|
#setScaleUpdatePages(
|
2022-12-12 22:24:27 +09:00
|
|
|
newScale,
|
|
|
|
newValue,
|
2022-12-28 21:26:01 +09:00
|
|
|
{ noScroll = false, preset = false, drawingDelay = -1 }
|
2022-12-12 22:24:27 +09:00
|
|
|
) {
|
2017-07-09 20:07:06 +09:00
|
|
|
this._currentScaleValue = newValue.toString();
|
|
|
|
|
2021-11-23 21:29:00 +09:00
|
|
|
if (this.#isSameScale(newScale)) {
|
2017-07-09 20:07:06 +09:00
|
|
|
if (preset) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("scalechanging", {
|
2018-09-21 06:27:10 +09:00
|
|
|
source: this,
|
|
|
|
scale: newScale,
|
|
|
|
presetValue: newValue,
|
|
|
|
});
|
2014-09-30 21:13:46 +09:00
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
return;
|
|
|
|
}
|
2021-11-07 02:36:49 +09:00
|
|
|
|
2023-01-17 03:38:33 +09:00
|
|
|
this.viewer.style.setProperty(
|
2022-06-13 18:01:55 +09:00
|
|
|
"--scale-factor",
|
|
|
|
newScale * PixelsPerInch.PDF_TO_CSS_UNITS
|
|
|
|
);
|
2021-08-04 21:42:24 +09:00
|
|
|
|
2022-12-28 21:26:01 +09:00
|
|
|
const postponeDrawing = drawingDelay >= 0 && drawingDelay < 1000;
|
|
|
|
this.refresh(true, {
|
2022-12-12 22:24:27 +09:00
|
|
|
scale: newScale,
|
2022-12-28 21:26:01 +09:00
|
|
|
drawingDelay: postponeDrawing ? drawingDelay : -1,
|
|
|
|
});
|
2022-12-12 22:24:27 +09:00
|
|
|
|
2022-12-28 21:26:01 +09:00
|
|
|
if (postponeDrawing) {
|
2022-12-12 22:24:27 +09:00
|
|
|
this.#scaleTimeoutId = setTimeout(() => {
|
|
|
|
this.#scaleTimeoutId = null;
|
|
|
|
this.refresh();
|
|
|
|
}, drawingDelay);
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2022-12-12 22:24:27 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
this._currentScale = newScale;
|
|
|
|
|
|
|
|
if (!noScroll) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
let page = this._currentPageNumber,
|
|
|
|
dest;
|
|
|
|
if (
|
|
|
|
this._location &&
|
|
|
|
!(this.isInPresentationMode || this.isChangingPresentationMode)
|
|
|
|
) {
|
2017-07-09 20:07:06 +09:00
|
|
|
page = this._location.pageNumber;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
dest = [
|
|
|
|
null,
|
|
|
|
{ name: "XYZ" },
|
|
|
|
this._location.left,
|
|
|
|
this._location.top,
|
|
|
|
null,
|
|
|
|
];
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
this.scrollPageIntoView({
|
|
|
|
pageNumber: page,
|
|
|
|
destArray: dest,
|
|
|
|
allowNegativeOffset: true,
|
|
|
|
});
|
|
|
|
}
|
2014-09-30 21:13:46 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("scalechanging", {
|
2018-09-21 06:27:10 +09:00
|
|
|
source: this,
|
|
|
|
scale: newScale,
|
|
|
|
presetValue: preset ? newValue : undefined,
|
|
|
|
});
|
2017-07-09 20:07:06 +09:00
|
|
|
|
|
|
|
if (this.defaultRenderingQueue) {
|
|
|
|
this.update();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-03-23 17:00:54 +09:00
|
|
|
get #pageWidthScaleFactor() {
|
2020-12-07 04:59:10 +09:00
|
|
|
if (
|
2021-02-14 20:32:50 +09:00
|
|
|
this._spreadMode !== SpreadMode.NONE &&
|
2021-10-07 21:04:41 +09:00
|
|
|
this._scrollMode !== ScrollMode.HORIZONTAL
|
2020-12-07 04:59:10 +09:00
|
|
|
) {
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2023-03-23 17:00:54 +09:00
|
|
|
#setScale(value, options) {
|
2017-07-09 20:07:06 +09:00
|
|
|
let scale = parseFloat(value);
|
|
|
|
|
|
|
|
if (scale > 0) {
|
2022-12-12 22:24:27 +09:00
|
|
|
options.preset = false;
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScaleUpdatePages(scale, value, options);
|
2017-07-09 20:07:06 +09:00
|
|
|
} else {
|
2019-12-27 08:22:32 +09:00
|
|
|
const currentPage = this._pages[this._currentPageNumber - 1];
|
2017-07-09 20:07:06 +09:00
|
|
|
if (!currentPage) {
|
Prevent destinations with bad left/top values from scrolling the wrong page into view (bug 874482)
There are PDF generators which create destinations with e.g. too large top values, which cause the wrong page to be scrolled into view because the offset becomes negative.
By ignoring negative offsets, we can prevent this issue, and get a similar behaviour as in Adobe Reader.
However, since we're also using `PDFViewer_scrollPageIntoView` in more cases than just when links (in the document/outline) are clicked, the patch adds a way to allow the caller to opt-out of this behaviour.
In e.g. the following situations, I think that we still want to be able to allow negative offsets: when restoring a position from the `ViewHistory`, when the `viewBookmark` button is used to obtain a link to the current position, or when maintaining the current position on zooming.
Rather than adding another parameter to `PDFViewer_scrollPageIntoView`, I've changed the signature to take an parameter object instead. To maintain backwards compatibility, I've added fallback code enclosed in a `GENERIC` preprocessor tag.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=874482.
2016-06-20 19:30:05 +09:00
|
|
|
return;
|
|
|
|
}
|
2021-11-23 21:29:00 +09:00
|
|
|
let hPadding = SCROLLBAR_PADDING,
|
|
|
|
vPadding = VERTICAL_PADDING;
|
2018-06-22 04:45:03 +09:00
|
|
|
|
2021-11-23 21:29:00 +09:00
|
|
|
if (this.isInPresentationMode) {
|
2022-12-09 19:40:45 +09:00
|
|
|
// Pages have a 2px (transparent) border in PresentationMode, see
|
|
|
|
// the `web/pdf_viewer.css` file.
|
|
|
|
hPadding = vPadding = 4; // 2 * 2px
|
|
|
|
if (this._spreadMode !== SpreadMode.NONE) {
|
|
|
|
// Account for two pages being visible in PresentationMode, thus
|
|
|
|
// "doubling" the total border width.
|
|
|
|
hPadding *= 2;
|
|
|
|
}
|
2023-02-03 18:08:47 +09:00
|
|
|
} else if (
|
|
|
|
(typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) &&
|
|
|
|
this.removePageBorders
|
|
|
|
) {
|
2021-11-23 21:29:00 +09:00
|
|
|
hPadding = vPadding = 0;
|
2022-05-06 00:37:33 +09:00
|
|
|
} else if (this._scrollMode === ScrollMode.HORIZONTAL) {
|
2018-08-20 21:18:16 +09:00
|
|
|
[hPadding, vPadding] = [vPadding, hPadding]; // Swap the padding values.
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageWidthScale =
|
2020-12-07 04:59:10 +09:00
|
|
|
(((this.container.clientWidth - hPadding) / currentPage.width) *
|
|
|
|
currentPage.scale) /
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#pageWidthScaleFactor;
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageHeightScale =
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
((this.container.clientHeight - vPadding) / currentPage.height) *
|
|
|
|
currentPage.scale;
|
2017-07-09 20:07:06 +09:00
|
|
|
switch (value) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "page-actual":
|
2017-07-09 20:07:06 +09:00
|
|
|
scale = 1;
|
2014-09-30 21:13:46 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "page-width":
|
2017-07-09 20:07:06 +09:00
|
|
|
scale = pageWidthScale;
|
2014-09-30 21:13:46 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "page-height":
|
2017-07-09 20:07:06 +09:00
|
|
|
scale = pageHeightScale;
|
2014-09-30 21:13:46 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "page-fit":
|
2017-07-09 20:07:06 +09:00
|
|
|
scale = Math.min(pageWidthScale, pageHeightScale);
|
2014-09-30 21:13:46 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "auto":
|
2017-07-09 20:07:06 +09:00
|
|
|
// For pages in landscape mode, fit the page height to the viewer
|
|
|
|
// *unless* the page would thus become too wide to fit horizontally.
|
2019-12-27 08:22:32 +09:00
|
|
|
const horizontalScale = isPortraitOrientation(currentPage)
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
? pageWidthScale
|
|
|
|
: Math.min(pageHeightScale, pageWidthScale);
|
2017-07-09 20:07:06 +09:00
|
|
|
scale = Math.min(MAX_AUTO_SCALE, horizontalScale);
|
2014-09-30 21:13:46 +09:00
|
|
|
break;
|
|
|
|
default:
|
2023-03-23 17:00:54 +09:00
|
|
|
console.error(`#setScale: "${value}" is an unknown zoom value.`);
|
2014-09-30 21:13:46 +09:00
|
|
|
return;
|
|
|
|
}
|
2022-12-12 22:24:27 +09:00
|
|
|
options.preset = true;
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScaleUpdatePages(scale, value, options);
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
}
|
2014-09-30 21:13:46 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* Refreshes page view: scrolls to the current page and updates the scale.
|
|
|
|
*/
|
2022-04-17 19:37:10 +09:00
|
|
|
#resetCurrentPageView() {
|
2022-05-04 18:35:04 +09:00
|
|
|
const pageView = this._pages[this._currentPageNumber - 1];
|
2022-04-17 19:37:10 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
if (this.isInPresentationMode) {
|
|
|
|
// Fixes the case when PDF has different page sizes.
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(this._currentScaleValue, { noScroll: true });
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2022-05-04 18:35:04 +09:00
|
|
|
this.#scrollIntoView(pageView);
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-30 21:13:46 +09:00
|
|
|
|
2020-10-31 18:17:28 +09:00
|
|
|
/**
|
|
|
|
* @param {string} label - The page label.
|
|
|
|
* @returns {number|null} The page number corresponding to the page label,
|
|
|
|
* or `null` when no page labels exist and/or the input is invalid.
|
|
|
|
*/
|
|
|
|
pageLabelToPageNumber(label) {
|
|
|
|
if (!this._pageLabels) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
const i = this._pageLabels.indexOf(label);
|
|
|
|
if (i < 0) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
return i + 1;
|
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
2022-03-04 20:10:16 +09:00
|
|
|
* @typedef {Object} ScrollPageIntoViewParameters
|
2017-07-09 20:07:06 +09:00
|
|
|
* @property {number} pageNumber - The page number.
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {Array} [destArray] - The original PDF destination array, in the
|
|
|
|
* format: <page-ref> </XYZ|/FitXXX> <args..>
|
|
|
|
* @property {boolean} [allowNegativeOffset] - Allow negative page offsets.
|
|
|
|
* The default value is `false`.
|
2020-02-17 22:04:55 +09:00
|
|
|
* @property {boolean} [ignoreDestinationZoom] - Ignore the zoom argument in
|
|
|
|
* the destination array. The default value is `false`.
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Scrolls page into view.
|
|
|
|
* @param {ScrollPageIntoViewParameters} params
|
|
|
|
*/
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
scrollPageIntoView({
|
|
|
|
pageNumber,
|
|
|
|
destArray = null,
|
|
|
|
allowNegativeOffset = false,
|
2020-02-17 22:04:55 +09:00
|
|
|
ignoreDestinationZoom = false,
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
}) {
|
2017-08-22 19:07:25 +09:00
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
const pageView =
|
|
|
|
Number.isInteger(pageNumber) && this._pages[pageNumber - 1];
|
2017-07-09 20:07:06 +09:00
|
|
|
if (!pageView) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.error(
|
2021-08-09 19:05:50 +09:00
|
|
|
`scrollPageIntoView: "${pageNumber}" is not a valid pageNumber parameter.`
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
2017-07-09 20:07:06 +09:00
|
|
|
return;
|
|
|
|
}
|
2018-11-09 17:45:09 +09:00
|
|
|
|
|
|
|
if (this.isInPresentationMode || !destArray) {
|
|
|
|
this._setCurrentPageNumber(pageNumber, /* resetCurrentPageView = */ true);
|
|
|
|
return;
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
let x = 0,
|
|
|
|
y = 0;
|
|
|
|
let width = 0,
|
|
|
|
height = 0,
|
|
|
|
widthScale,
|
|
|
|
heightScale;
|
2020-01-12 22:50:52 +09:00
|
|
|
const changeOrientation = pageView.rotation % 180 !== 0;
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageWidth =
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
(changeOrientation ? pageView.height : pageView.width) /
|
|
|
|
pageView.scale /
|
2021-09-20 17:10:57 +09:00
|
|
|
PixelsPerInch.PDF_TO_CSS_UNITS;
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageHeight =
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
(changeOrientation ? pageView.width : pageView.height) /
|
|
|
|
pageView.scale /
|
2021-09-20 17:10:57 +09:00
|
|
|
PixelsPerInch.PDF_TO_CSS_UNITS;
|
2017-07-09 20:07:06 +09:00
|
|
|
let scale = 0;
|
2018-11-09 17:45:09 +09:00
|
|
|
switch (destArray[1].name) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "XYZ":
|
2018-11-09 17:45:09 +09:00
|
|
|
x = destArray[2];
|
|
|
|
y = destArray[3];
|
|
|
|
scale = destArray[4];
|
2017-07-09 20:07:06 +09:00
|
|
|
// If x and/or y coordinates are not supplied, default to
|
|
|
|
// _top_ left of the page (not the obvious bottom left,
|
|
|
|
// since aligning the bottom of the intended page with the
|
|
|
|
// top of the window is rarely helpful).
|
|
|
|
x = x !== null ? x : 0;
|
|
|
|
y = y !== null ? y : pageHeight;
|
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "Fit":
|
|
|
|
case "FitB":
|
|
|
|
scale = "page-fit";
|
2017-07-09 20:07:06 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "FitH":
|
|
|
|
case "FitBH":
|
2018-11-09 17:45:09 +09:00
|
|
|
y = destArray[2];
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
scale = "page-width";
|
2017-07-09 20:07:06 +09:00
|
|
|
// According to the PDF spec, section 12.3.2.2, a `null` value in the
|
|
|
|
// parameter should maintain the position relative to the new page.
|
|
|
|
if (y === null && this._location) {
|
|
|
|
x = this._location.left;
|
|
|
|
y = this._location.top;
|
2021-12-18 19:35:21 +09:00
|
|
|
} else if (typeof y !== "number" || y < 0) {
|
2020-09-07 17:27:32 +09:00
|
|
|
// The "top" value isn't optional, according to the spec, however some
|
|
|
|
// bad PDF generators will pretend that it is (fixes bug 1663390).
|
|
|
|
y = pageHeight;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "FitV":
|
|
|
|
case "FitBV":
|
2018-11-09 17:45:09 +09:00
|
|
|
x = destArray[2];
|
2017-07-09 20:07:06 +09:00
|
|
|
width = pageWidth;
|
|
|
|
height = pageHeight;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
scale = "page-height";
|
2017-07-09 20:07:06 +09:00
|
|
|
break;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
case "FitR":
|
2018-11-09 17:45:09 +09:00
|
|
|
x = destArray[2];
|
|
|
|
y = destArray[3];
|
|
|
|
width = destArray[4] - x;
|
|
|
|
height = destArray[5] - y;
|
2023-02-03 18:08:47 +09:00
|
|
|
let hPadding = SCROLLBAR_PADDING,
|
|
|
|
vPadding = VERTICAL_PADDING;
|
|
|
|
|
|
|
|
if (
|
|
|
|
(typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) &&
|
|
|
|
this.removePageBorders
|
|
|
|
) {
|
|
|
|
hPadding = vPadding = 0;
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
widthScale =
|
2021-09-20 17:10:57 +09:00
|
|
|
(this.container.clientWidth - hPadding) /
|
|
|
|
width /
|
|
|
|
PixelsPerInch.PDF_TO_CSS_UNITS;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
heightScale =
|
2021-09-20 17:10:57 +09:00
|
|
|
(this.container.clientHeight - vPadding) /
|
|
|
|
height /
|
|
|
|
PixelsPerInch.PDF_TO_CSS_UNITS;
|
2017-07-09 20:07:06 +09:00
|
|
|
scale = Math.min(Math.abs(widthScale), Math.abs(heightScale));
|
|
|
|
break;
|
|
|
|
default:
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
console.error(
|
2021-08-09 19:05:50 +09:00
|
|
|
`scrollPageIntoView: "${destArray[1].name}" is not a valid destination type.`
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
2014-09-13 11:27:45 +09:00
|
|
|
return;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2020-02-17 22:04:55 +09:00
|
|
|
if (!ignoreDestinationZoom) {
|
|
|
|
if (scale && scale !== this._currentScale) {
|
|
|
|
this.currentScaleValue = scale;
|
|
|
|
} else if (this._currentScale === UNKNOWN_SCALE) {
|
|
|
|
this.currentScaleValue = DEFAULT_SCALE_VALUE;
|
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
if (scale === "page-fit" && !destArray[4]) {
|
2022-05-04 18:35:04 +09:00
|
|
|
this.#scrollIntoView(pageView);
|
2017-07-09 20:07:06 +09:00
|
|
|
return;
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2019-12-27 08:22:32 +09:00
|
|
|
const boundingRect = [
|
2017-07-09 20:07:06 +09:00
|
|
|
pageView.viewport.convertToViewportPoint(x, y),
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
pageView.viewport.convertToViewportPoint(x + width, y + height),
|
2017-07-09 20:07:06 +09:00
|
|
|
];
|
|
|
|
let left = Math.min(boundingRect[0][0], boundingRect[1][0]);
|
|
|
|
let top = Math.min(boundingRect[0][1], boundingRect[1][1]);
|
|
|
|
|
|
|
|
if (!allowNegativeOffset) {
|
|
|
|
// Some bad PDF generators will create destinations with e.g. top values
|
|
|
|
// that exceeds the page height. Ensure that offsets are not negative,
|
|
|
|
// to prevent a previous page from becoming visible (fixes bug 874482).
|
|
|
|
left = Math.max(left, 0);
|
|
|
|
top = Math.max(top, 0);
|
|
|
|
}
|
2022-05-04 18:35:04 +09:00
|
|
|
this.#scrollIntoView(pageView, /* pageSpot = */ { left, top });
|
2017-08-01 21:11:28 +09:00
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
_updateLocation(firstPage) {
|
2019-12-27 08:22:32 +09:00
|
|
|
const currentScale = this._currentScale;
|
|
|
|
const currentScaleValue = this._currentScaleValue;
|
|
|
|
const normalizedScaleValue =
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
parseFloat(currentScaleValue) === currentScale
|
|
|
|
? Math.round(currentScale * 10000) / 100
|
|
|
|
: currentScaleValue;
|
2017-07-09 20:07:06 +09:00
|
|
|
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageNumber = firstPage.id;
|
|
|
|
const currentPageView = this._pages[pageNumber - 1];
|
|
|
|
const container = this.container;
|
|
|
|
const topLeft = currentPageView.getPagePoint(
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
container.scrollLeft - firstPage.x,
|
|
|
|
container.scrollTop - firstPage.y
|
|
|
|
);
|
2019-12-27 08:22:32 +09:00
|
|
|
const intLeft = Math.round(topLeft[0]);
|
|
|
|
const intTop = Math.round(topLeft[1]);
|
2022-04-05 20:56:51 +09:00
|
|
|
|
|
|
|
let pdfOpenParams = `#page=${pageNumber}`;
|
|
|
|
if (!this.isInPresentationMode) {
|
|
|
|
pdfOpenParams += `&zoom=${normalizedScaleValue},${intLeft},${intTop}`;
|
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
|
|
|
|
this._location = {
|
|
|
|
pageNumber,
|
|
|
|
scale: normalizedScaleValue,
|
|
|
|
top: intTop,
|
|
|
|
left: intLeft,
|
2017-08-21 18:22:07 +09:00
|
|
|
rotation: this._pagesRotation,
|
2017-07-09 20:07:06 +09:00
|
|
|
pdfOpenParams,
|
|
|
|
};
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
update() {
|
2019-01-18 20:42:32 +09:00
|
|
|
const visible = this._getVisiblePages();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
const visiblePages = visible.views,
|
|
|
|
numVisiblePages = visiblePages.length;
|
2019-01-18 20:42:32 +09:00
|
|
|
|
|
|
|
if (numVisiblePages === 0) {
|
|
|
|
return;
|
|
|
|
}
|
2019-01-23 17:11:06 +09:00
|
|
|
const newCacheSize = Math.max(DEFAULT_CACHE_SIZE, 2 * numVisiblePages + 1);
|
2021-11-06 18:09:59 +09:00
|
|
|
this.#buffer.resize(newCacheSize, visible.ids);
|
2019-01-18 20:42:32 +09:00
|
|
|
|
|
|
|
this.renderingQueue.renderHighestPriority(visible);
|
|
|
|
|
2022-04-17 19:37:10 +09:00
|
|
|
const isSimpleLayout =
|
|
|
|
this._spreadMode === SpreadMode.NONE &&
|
|
|
|
(this._scrollMode === ScrollMode.PAGE ||
|
|
|
|
this._scrollMode === ScrollMode.VERTICAL);
|
|
|
|
const currentId = this._currentPageNumber;
|
|
|
|
let stillFullyVisible = false;
|
|
|
|
|
|
|
|
for (const page of visiblePages) {
|
|
|
|
if (page.percent < 100) {
|
|
|
|
break;
|
2021-10-07 21:04:41 +09:00
|
|
|
}
|
2022-04-17 19:37:10 +09:00
|
|
|
if (page.id === currentId && isSimpleLayout) {
|
|
|
|
stillFullyVisible = true;
|
|
|
|
break;
|
2021-10-07 21:04:41 +09:00
|
|
|
}
|
|
|
|
}
|
2022-04-17 19:37:10 +09:00
|
|
|
this._setCurrentPageNumber(
|
|
|
|
stillFullyVisible ? currentId : visiblePages[0].id
|
|
|
|
);
|
2019-01-18 20:42:32 +09:00
|
|
|
|
|
|
|
this._updateLocation(visible.first);
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("updateviewarea", {
|
2019-01-18 20:42:32 +09:00
|
|
|
source: this,
|
|
|
|
location: this._location,
|
|
|
|
});
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
containsElement(element) {
|
|
|
|
return this.container.contains(element);
|
|
|
|
}
|
2015-01-29 21:37:49 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
focus() {
|
|
|
|
this.container.focus();
|
|
|
|
}
|
2015-01-29 21:37:49 +09:00
|
|
|
|
2020-10-09 23:20:06 +09:00
|
|
|
get _isContainerRtl() {
|
|
|
|
return getComputedStyle(this.container).direction === "rtl";
|
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
get isInPresentationMode() {
|
|
|
|
return this.presentationModeState === PresentationModeState.FULLSCREEN;
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
get isChangingPresentationMode() {
|
|
|
|
return this.presentationModeState === PresentationModeState.CHANGING;
|
|
|
|
}
|
|
|
|
|
|
|
|
get isHorizontalScrollbarEnabled() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return this.isInPresentationMode
|
|
|
|
? false
|
|
|
|
: this.container.scrollWidth > this.container.clientWidth;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
|
2018-05-15 12:10:32 +09:00
|
|
|
get isVerticalScrollbarEnabled() {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return this.isInPresentationMode
|
|
|
|
? false
|
|
|
|
: this.container.scrollHeight > this.container.clientHeight;
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
_getVisiblePages() {
|
2021-10-07 21:04:41 +09:00
|
|
|
const views =
|
|
|
|
this._scrollMode === ScrollMode.PAGE
|
2021-10-28 18:57:27 +09:00
|
|
|
? this.#scrollModePageState.pages
|
2021-10-07 21:04:41 +09:00
|
|
|
: this._pages,
|
|
|
|
horizontal = this._scrollMode === ScrollMode.HORIZONTAL,
|
|
|
|
rtl = horizontal && this._isContainerRtl;
|
|
|
|
|
2020-11-04 20:05:29 +09:00
|
|
|
return getVisibleElements({
|
|
|
|
scrollEl: this.container,
|
2021-10-07 21:04:41 +09:00
|
|
|
views,
|
2020-11-04 20:05:29 +09:00
|
|
|
sortByVisibility: true,
|
2021-10-07 21:04:41 +09:00
|
|
|
horizontal,
|
|
|
|
rtl,
|
2020-11-04 20:05:29 +09:00
|
|
|
});
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
|
2018-10-30 19:08:26 +09:00
|
|
|
/**
|
|
|
|
* @param {number} pageNumber
|
|
|
|
*/
|
|
|
|
isPageVisible(pageNumber) {
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return false;
|
|
|
|
}
|
2020-11-12 23:24:36 +09:00
|
|
|
if (
|
|
|
|
!(
|
|
|
|
Number.isInteger(pageNumber) &&
|
|
|
|
pageNumber > 0 &&
|
|
|
|
pageNumber <= this.pagesCount
|
|
|
|
)
|
|
|
|
) {
|
2021-08-09 19:05:50 +09:00
|
|
|
console.error(`isPageVisible: "${pageNumber}" is not a valid page.`);
|
2018-10-30 19:08:26 +09:00
|
|
|
return false;
|
|
|
|
}
|
2021-11-01 19:52:45 +09:00
|
|
|
return this._getVisiblePages().ids.has(pageNumber);
|
2018-10-30 19:08:26 +09:00
|
|
|
}
|
|
|
|
|
Trigger cleanup, once rendering has finished, in `PDFThumbnailView.draw`
This patch will help reduce memory usage, especially for longer documents, when the user scrolls around in the thumbnailView (in the sidebar).
Note how the `PDFPageProxy.cleanup` method will, assuming it's safe to do so, release main-thread resources associated with the page. These include things such as e.g. image data (which can be arbitrarily large), and also the operatorList (which can also be quite large).
Hence when pages are evicted from the `PDFPageViewBuffer`, on the `BaseViewer`-instance, the `PDFPageView.destroy` method is invoked which will (among other things) call `PDFPageProxy.cleanup` in the API.
However, looking at the `PDFThumbnailViewer`/`PDFThumbnailView` classes you'll notice that there's no attempt to ever call `PDFPageProxy.cleanup`, which implies that in certain circumstances we'll essentially keep all resources allocated permanently on the `PDFPageProxy`-instances in the API.
In particular, this happens when the users opens the sidebar and starts scrolling around in the thumbnails. Generally speaking you obviously need to keep all thumbnail *images* around, since otherwise the thumbnailView is useless, but there's still room for improvement here.
Please note that the case where a *rendered page* is used to create the thumbnail is (obviously) completely unaffected by the issues described above, and this rather only applies to thumbnails being explicitly rendered by the `PDFThumbnailView.draw` method.
For the latter case, we can fix these issues simply by calling `PDFPageProxy.cleanup` once rendering has finished. To prevent *accidentally* pulling the rug out from under `PDFPageViewBuffer` in the viewer, which expects data to be available, this required adding a couple of new methods[1] to enable checking that it's indeed safe to call `PDFPageProxy.cleanup` from the `PDFThumbnailView.draw` method.
It's really quite fascinating that no one has noticed this issue before, since it's been around since basically "forever".
---
[1] While it should be *very* rare for `PDFThumbnailView.draw` to be called for a pageView that's also in the `PDFPageViewBuffer`, given that pages are rendered before thumbnails and that the *rendered page* is used to create the thumbnail, it can still happen since rendering is asynchronous.
Furthermore, it's also possible for `PDFThumbnailView.setImage` to be disabled, in which case checking the `PDFPageViewBuffer` for active pageViews *really* matters.
2020-11-12 23:49:29 +09:00
|
|
|
/**
|
|
|
|
* @param {number} pageNumber
|
|
|
|
*/
|
|
|
|
isPageCached(pageNumber) {
|
2021-11-01 19:52:45 +09:00
|
|
|
if (!this.pdfDocument) {
|
Trigger cleanup, once rendering has finished, in `PDFThumbnailView.draw`
This patch will help reduce memory usage, especially for longer documents, when the user scrolls around in the thumbnailView (in the sidebar).
Note how the `PDFPageProxy.cleanup` method will, assuming it's safe to do so, release main-thread resources associated with the page. These include things such as e.g. image data (which can be arbitrarily large), and also the operatorList (which can also be quite large).
Hence when pages are evicted from the `PDFPageViewBuffer`, on the `BaseViewer`-instance, the `PDFPageView.destroy` method is invoked which will (among other things) call `PDFPageProxy.cleanup` in the API.
However, looking at the `PDFThumbnailViewer`/`PDFThumbnailView` classes you'll notice that there's no attempt to ever call `PDFPageProxy.cleanup`, which implies that in certain circumstances we'll essentially keep all resources allocated permanently on the `PDFPageProxy`-instances in the API.
In particular, this happens when the users opens the sidebar and starts scrolling around in the thumbnails. Generally speaking you obviously need to keep all thumbnail *images* around, since otherwise the thumbnailView is useless, but there's still room for improvement here.
Please note that the case where a *rendered page* is used to create the thumbnail is (obviously) completely unaffected by the issues described above, and this rather only applies to thumbnails being explicitly rendered by the `PDFThumbnailView.draw` method.
For the latter case, we can fix these issues simply by calling `PDFPageProxy.cleanup` once rendering has finished. To prevent *accidentally* pulling the rug out from under `PDFPageViewBuffer` in the viewer, which expects data to be available, this required adding a couple of new methods[1] to enable checking that it's indeed safe to call `PDFPageProxy.cleanup` from the `PDFThumbnailView.draw` method.
It's really quite fascinating that no one has noticed this issue before, since it's been around since basically "forever".
---
[1] While it should be *very* rare for `PDFThumbnailView.draw` to be called for a pageView that's also in the `PDFPageViewBuffer`, given that pages are rendered before thumbnails and that the *rendered page* is used to create the thumbnail, it can still happen since rendering is asynchronous.
Furthermore, it's also possible for `PDFThumbnailView.setImage` to be disabled, in which case checking the `PDFPageViewBuffer` for active pageViews *really* matters.
2020-11-12 23:49:29 +09:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (
|
|
|
|
!(
|
|
|
|
Number.isInteger(pageNumber) &&
|
|
|
|
pageNumber > 0 &&
|
|
|
|
pageNumber <= this.pagesCount
|
|
|
|
)
|
|
|
|
) {
|
2021-08-09 19:05:50 +09:00
|
|
|
console.error(`isPageCached: "${pageNumber}" is not a valid page.`);
|
Trigger cleanup, once rendering has finished, in `PDFThumbnailView.draw`
This patch will help reduce memory usage, especially for longer documents, when the user scrolls around in the thumbnailView (in the sidebar).
Note how the `PDFPageProxy.cleanup` method will, assuming it's safe to do so, release main-thread resources associated with the page. These include things such as e.g. image data (which can be arbitrarily large), and also the operatorList (which can also be quite large).
Hence when pages are evicted from the `PDFPageViewBuffer`, on the `BaseViewer`-instance, the `PDFPageView.destroy` method is invoked which will (among other things) call `PDFPageProxy.cleanup` in the API.
However, looking at the `PDFThumbnailViewer`/`PDFThumbnailView` classes you'll notice that there's no attempt to ever call `PDFPageProxy.cleanup`, which implies that in certain circumstances we'll essentially keep all resources allocated permanently on the `PDFPageProxy`-instances in the API.
In particular, this happens when the users opens the sidebar and starts scrolling around in the thumbnails. Generally speaking you obviously need to keep all thumbnail *images* around, since otherwise the thumbnailView is useless, but there's still room for improvement here.
Please note that the case where a *rendered page* is used to create the thumbnail is (obviously) completely unaffected by the issues described above, and this rather only applies to thumbnails being explicitly rendered by the `PDFThumbnailView.draw` method.
For the latter case, we can fix these issues simply by calling `PDFPageProxy.cleanup` once rendering has finished. To prevent *accidentally* pulling the rug out from under `PDFPageViewBuffer` in the viewer, which expects data to be available, this required adding a couple of new methods[1] to enable checking that it's indeed safe to call `PDFPageProxy.cleanup` from the `PDFThumbnailView.draw` method.
It's really quite fascinating that no one has noticed this issue before, since it's been around since basically "forever".
---
[1] While it should be *very* rare for `PDFThumbnailView.draw` to be called for a pageView that's also in the `PDFPageViewBuffer`, given that pages are rendered before thumbnails and that the *rendered page* is used to create the thumbnail, it can still happen since rendering is asynchronous.
Furthermore, it's also possible for `PDFThumbnailView.setImage` to be disabled, in which case checking the `PDFPageViewBuffer` for active pageViews *really* matters.
2020-11-12 23:49:29 +09:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
const pageView = this._pages[pageNumber - 1];
|
2021-11-06 18:09:59 +09:00
|
|
|
return this.#buffer.has(pageView);
|
Trigger cleanup, once rendering has finished, in `PDFThumbnailView.draw`
This patch will help reduce memory usage, especially for longer documents, when the user scrolls around in the thumbnailView (in the sidebar).
Note how the `PDFPageProxy.cleanup` method will, assuming it's safe to do so, release main-thread resources associated with the page. These include things such as e.g. image data (which can be arbitrarily large), and also the operatorList (which can also be quite large).
Hence when pages are evicted from the `PDFPageViewBuffer`, on the `BaseViewer`-instance, the `PDFPageView.destroy` method is invoked which will (among other things) call `PDFPageProxy.cleanup` in the API.
However, looking at the `PDFThumbnailViewer`/`PDFThumbnailView` classes you'll notice that there's no attempt to ever call `PDFPageProxy.cleanup`, which implies that in certain circumstances we'll essentially keep all resources allocated permanently on the `PDFPageProxy`-instances in the API.
In particular, this happens when the users opens the sidebar and starts scrolling around in the thumbnails. Generally speaking you obviously need to keep all thumbnail *images* around, since otherwise the thumbnailView is useless, but there's still room for improvement here.
Please note that the case where a *rendered page* is used to create the thumbnail is (obviously) completely unaffected by the issues described above, and this rather only applies to thumbnails being explicitly rendered by the `PDFThumbnailView.draw` method.
For the latter case, we can fix these issues simply by calling `PDFPageProxy.cleanup` once rendering has finished. To prevent *accidentally* pulling the rug out from under `PDFPageViewBuffer` in the viewer, which expects data to be available, this required adding a couple of new methods[1] to enable checking that it's indeed safe to call `PDFPageProxy.cleanup` from the `PDFThumbnailView.draw` method.
It's really quite fascinating that no one has noticed this issue before, since it's been around since basically "forever".
---
[1] While it should be *very* rare for `PDFThumbnailView.draw` to be called for a pageView that's also in the `PDFPageViewBuffer`, given that pages are rendered before thumbnails and that the *rendered page* is used to create the thumbnail, it can still happen since rendering is asynchronous.
Furthermore, it's also possible for `PDFThumbnailView.setImage` to be disabled, in which case checking the `PDFPageViewBuffer` for active pageViews *really* matters.
2020-11-12 23:49:29 +09:00
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
cleanup() {
|
2022-04-23 19:46:38 +09:00
|
|
|
for (const pageView of this._pages) {
|
|
|
|
if (pageView.renderingState !== RenderingStates.FINISHED) {
|
|
|
|
pageView.reset();
|
2014-09-29 22:11:46 +09:00
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @private
|
|
|
|
*/
|
|
|
|
_cancelRendering() {
|
2022-04-23 19:46:38 +09:00
|
|
|
for (const pageView of this._pages) {
|
|
|
|
pageView.cancelRendering();
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
}
|
2014-09-15 23:49:24 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* @param {PDFPageView} pageView
|
2021-11-21 02:24:12 +09:00
|
|
|
* @returns {Promise<PDFPageProxy | null>}
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
2021-11-21 02:24:12 +09:00
|
|
|
async #ensurePdfPageLoaded(pageView) {
|
2017-07-09 20:07:06 +09:00
|
|
|
if (pageView.pdfPage) {
|
2021-11-21 02:24:12 +09:00
|
|
|
return pageView.pdfPage;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2021-11-21 02:24:12 +09:00
|
|
|
try {
|
|
|
|
const pdfPage = await this.pdfDocument.getPage(pageView.id);
|
|
|
|
if (!pageView.pdfPage) {
|
|
|
|
pageView.setPdfPage(pdfPage);
|
|
|
|
}
|
2022-01-13 01:04:51 +09:00
|
|
|
if (!this.linkService._cachedPageNumber?.(pdfPage.ref)) {
|
2021-11-21 06:31:31 +09:00
|
|
|
this.linkService.cachePageRef(pageView.id, pdfPage.ref);
|
|
|
|
}
|
2021-11-21 02:24:12 +09:00
|
|
|
return pdfPage;
|
|
|
|
} catch (reason) {
|
|
|
|
console.error("Unable to get page for page view", reason);
|
|
|
|
return null; // Page error -- there is nothing that can be done.
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-10-25 21:20:24 +09:00
|
|
|
#getScrollAhead(visible) {
|
|
|
|
if (visible.first?.id === 1) {
|
2021-10-18 19:13:54 +09:00
|
|
|
return true;
|
2021-10-25 21:20:24 +09:00
|
|
|
} else if (visible.last?.id === this.pagesCount) {
|
2021-10-18 19:13:54 +09:00
|
|
|
return false;
|
|
|
|
}
|
2021-10-07 21:04:41 +09:00
|
|
|
switch (this._scrollMode) {
|
|
|
|
case ScrollMode.PAGE:
|
2021-10-28 18:57:27 +09:00
|
|
|
return this.#scrollModePageState.scrollDown;
|
2021-10-07 21:04:41 +09:00
|
|
|
case ScrollMode.HORIZONTAL:
|
|
|
|
return this.scroll.right;
|
|
|
|
}
|
|
|
|
return this.scroll.down;
|
|
|
|
}
|
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
forceRendering(currentlyVisiblePages) {
|
2019-12-27 08:22:32 +09:00
|
|
|
const visiblePages = currentlyVisiblePages || this._getVisiblePages();
|
2021-10-18 19:13:54 +09:00
|
|
|
const scrollAhead = this.#getScrollAhead(visiblePages);
|
2021-10-02 18:43:58 +09:00
|
|
|
const preRenderExtra =
|
|
|
|
this._spreadMode !== SpreadMode.NONE &&
|
2021-10-07 21:04:41 +09:00
|
|
|
this._scrollMode !== ScrollMode.HORIZONTAL;
|
2021-10-02 18:43:58 +09:00
|
|
|
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageView = this.renderingQueue.getHighestPriority(
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
visiblePages,
|
|
|
|
this._pages,
|
2021-10-02 18:43:58 +09:00
|
|
|
scrollAhead,
|
|
|
|
preRenderExtra
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
2021-11-14 20:20:04 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
if (pageView) {
|
2021-11-21 02:24:12 +09:00
|
|
|
this.#ensurePdfPageLoaded(pageView).then(() => {
|
2017-07-09 20:07:06 +09:00
|
|
|
this.renderingQueue.renderView(pageView);
|
2014-09-30 01:05:28 +09:00
|
|
|
});
|
2017-07-09 19:43:57 +09:00
|
|
|
return true;
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {boolean} Whether all pages of the PDF document have identical
|
|
|
|
* widths and heights.
|
2017-07-09 20:07:06 +09:00
|
|
|
*/
|
|
|
|
get hasEqualPageSizes() {
|
2019-12-27 08:22:32 +09:00
|
|
|
const firstPageView = this._pages[0];
|
2017-07-09 20:07:06 +09:00
|
|
|
for (let i = 1, ii = this._pages.length; i < ii; ++i) {
|
2019-12-27 08:22:32 +09:00
|
|
|
const pageView = this._pages[i];
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
if (
|
|
|
|
pageView.width !== firstPageView.width ||
|
|
|
|
pageView.height !== firstPageView.height
|
|
|
|
) {
|
2017-07-09 20:07:06 +09:00
|
|
|
return false;
|
2017-02-08 08:15:09 +09:00
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2014-09-13 11:27:45 +09:00
|
|
|
|
2017-07-09 20:07:06 +09:00
|
|
|
/**
|
|
|
|
* Returns sizes of the pages.
|
|
|
|
* @returns {Array} Array of objects with width/height/rotation fields.
|
|
|
|
*/
|
|
|
|
getPagesOverview() {
|
2021-03-19 20:19:29 +09:00
|
|
|
return this._pages.map(pageView => {
|
2019-12-27 08:22:32 +09:00
|
|
|
const viewport = pageView.pdfPage.getViewport({ scale: 1 });
|
2021-03-19 20:19:29 +09:00
|
|
|
|
|
|
|
if (!this.enablePrintAutoRotate || isPortraitOrientation(viewport)) {
|
|
|
|
return {
|
|
|
|
width: viewport.width,
|
|
|
|
height: viewport.height,
|
|
|
|
rotation: viewport.rotation,
|
|
|
|
};
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2021-03-19 20:19:29 +09:00
|
|
|
// Landscape orientation.
|
2017-07-09 20:07:06 +09:00
|
|
|
return {
|
2021-03-19 20:19:29 +09:00
|
|
|
width: viewport.height,
|
|
|
|
height: viewport.width,
|
|
|
|
rotation: (viewport.rotation - 90) % 360,
|
2017-07-09 20:07:06 +09:00
|
|
|
};
|
|
|
|
});
|
|
|
|
}
|
2018-05-15 12:10:32 +09:00
|
|
|
|
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096)
*Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.)
By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature.
Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar.
(Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.)
Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime.
To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which:
- Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive.
- Uses a slightly different formatting, compared to the "regular" headings.
- Is localizable.
Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers.
To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
|
|
|
/**
|
|
|
|
* @type {Promise<OptionalContentConfig | null>}
|
|
|
|
*/
|
|
|
|
get optionalContentConfigPromise() {
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return Promise.resolve(null);
|
|
|
|
}
|
|
|
|
if (!this._optionalContentConfigPromise) {
|
2022-07-24 20:14:58 +09:00
|
|
|
console.error("optionalContentConfigPromise: Not initialized yet.");
|
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096)
*Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.)
By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature.
Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar.
(Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.)
Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime.
To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which:
- Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive.
- Uses a slightly different formatting, compared to the "regular" headings.
- Is localizable.
Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers.
To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
|
|
|
// Prevent issues if the getter is accessed *before* the `onePageRendered`
|
|
|
|
// promise has resolved; won't (normally) happen in the default viewer.
|
|
|
|
return this.pdfDocument.getOptionalContentConfig();
|
|
|
|
}
|
|
|
|
return this._optionalContentConfigPromise;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @param {Promise<OptionalContentConfig>} promise - A promise that is
|
|
|
|
* resolved with an {@link OptionalContentConfig} instance.
|
|
|
|
*/
|
|
|
|
set optionalContentConfigPromise(promise) {
|
|
|
|
if (!(promise instanceof Promise)) {
|
|
|
|
throw new Error(`Invalid optionalContentConfigPromise: ${promise}`);
|
|
|
|
}
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!this._optionalContentConfigPromise) {
|
|
|
|
// Ignore the setter *before* the `onePageRendered` promise has resolved,
|
|
|
|
// since it'll be overwritten anyway; won't happen in the default viewer.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
this._optionalContentConfigPromise = promise;
|
|
|
|
|
2022-12-12 22:24:27 +09:00
|
|
|
this.refresh(false, { optionalContentConfigPromise: promise });
|
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096)
*Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.)
By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature.
Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar.
(Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.)
Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime.
To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which:
- Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive.
- Uses a slightly different formatting, compared to the "regular" headings.
- Is localizable.
Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers.
To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
|
|
|
|
|
|
|
this.eventBus.dispatch("optionalcontentconfigchanged", {
|
|
|
|
source: this,
|
|
|
|
promise,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2018-06-29 22:07:42 +09:00
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {number} One of the values in {ScrollMode}.
|
2018-06-29 22:07:42 +09:00
|
|
|
*/
|
|
|
|
get scrollMode() {
|
|
|
|
return this._scrollMode;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @param {number} mode - The direction in which the document pages should be
|
|
|
|
* laid out within the scrolling container.
|
|
|
|
* The constants from {ScrollMode} should be used.
|
|
|
|
*/
|
|
|
|
set scrollMode(mode) {
|
|
|
|
if (this._scrollMode === mode) {
|
|
|
|
return; // The Scroll mode didn't change.
|
|
|
|
}
|
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
|
|
|
if (!isValidScrollMode(mode)) {
|
2018-06-22 02:53:13 +09:00
|
|
|
throw new Error(`Invalid scroll mode: ${mode}`);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
Enforce PAGE-scrolling for *very* large/long documents (bug 1588435, PR 11263 follow-up)
This patch is essentially a continuation of PR 11263, which tried to improve loading/initialization performance of *very* large/long documents.
Note that browsers, in general, don't handle a huge amount of DOM-elements very well, with really poor (e.g. sluggish scrolling) performance once the number gets "large". Furthermore, at least in Firefox, it seems that DOM-elements towards the bottom of a HTML-page can effectively be ignored; for the PDF.js viewer that means that pages at the end of the document can become impossible to access.
Hence, in order to improve things for these *very* large/long documents, this patch will now enforce usage of the (recently added) PAGE-scrolling mode for these documents. As implemented, this will only happen once the number of pages *exceed* 15000 (which is hopefully rare in practice).
While this might feel a bit jarring to users being *forced* to use PAGE-scrolling, it seems all things considered like a better idea to ensure that the entire document actually remains accessible and with (hopefully) more acceptable performance.
Fixes [bug 1588435](https://bugzilla.mozilla.org/show_bug.cgi?id=1588435), to the extent that doing so is possible since the document contains 25560 pages (and is 197 MB large).
2021-11-29 02:43:30 +09:00
|
|
|
if (this.pagesCount > PagesCountLimit.FORCE_SCROLL_MODE_PAGE) {
|
|
|
|
return; // Disabled for performance reasons.
|
|
|
|
}
|
2021-10-07 21:04:41 +09:00
|
|
|
this._previousScrollMode = this._scrollMode;
|
|
|
|
|
2018-06-29 21:14:11 +09:00
|
|
|
this._scrollMode = mode;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("scrollmodechanged", { source: this, mode });
|
2018-06-29 22:07:42 +09:00
|
|
|
|
2018-06-29 22:28:38 +09:00
|
|
|
this._updateScrollMode(/* pageNumber = */ this._currentPageNumber);
|
|
|
|
}
|
2018-06-29 22:07:42 +09:00
|
|
|
|
2018-06-29 22:28:38 +09:00
|
|
|
_updateScrollMode(pageNumber = null) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
const scrollMode = this._scrollMode,
|
|
|
|
viewer = this.viewer;
|
2018-06-29 22:28:38 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
viewer.classList.toggle(
|
|
|
|
"scrollHorizontal",
|
|
|
|
scrollMode === ScrollMode.HORIZONTAL
|
|
|
|
);
|
|
|
|
viewer.classList.toggle("scrollWrapped", scrollMode === ScrollMode.WRAPPED);
|
2018-06-29 22:28:38 +09:00
|
|
|
|
|
|
|
if (!this.pdfDocument || !pageNumber) {
|
2018-06-29 22:07:42 +09:00
|
|
|
return;
|
|
|
|
}
|
2021-10-07 21:04:41 +09:00
|
|
|
|
|
|
|
if (scrollMode === ScrollMode.PAGE) {
|
2021-11-16 23:16:59 +09:00
|
|
|
this.#ensurePageViewVisible();
|
2021-10-07 21:04:41 +09:00
|
|
|
} else if (this._previousScrollMode === ScrollMode.PAGE) {
|
|
|
|
// Ensure that the current spreadMode is still applied correctly when
|
|
|
|
// the *previous* scrollMode was `ScrollMode.PAGE`.
|
|
|
|
this._updateSpreadMode();
|
|
|
|
}
|
2018-06-29 22:07:42 +09:00
|
|
|
// Non-numeric scale values can be sensitive to the scroll orientation.
|
|
|
|
// Call this before re-scrolling to the current page, to ensure that any
|
|
|
|
// changes in scale don't move the current page.
|
2018-06-29 22:28:38 +09:00
|
|
|
if (this._currentScaleValue && isNaN(this._currentScaleValue)) {
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(this._currentScaleValue, { noScroll: true });
|
2018-06-29 22:07:42 +09:00
|
|
|
}
|
2018-11-09 18:16:40 +09:00
|
|
|
this._setCurrentPageNumber(pageNumber, /* resetCurrentPageView = */ true);
|
2018-06-29 22:07:42 +09:00
|
|
|
this.update();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-10-13 00:02:54 +09:00
|
|
|
* @type {number} One of the values in {SpreadMode}.
|
2018-06-29 22:07:42 +09:00
|
|
|
*/
|
|
|
|
get spreadMode() {
|
|
|
|
return this._spreadMode;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @param {number} mode - Group the pages in spreads, starting with odd- or
|
|
|
|
* even-number pages (unless `SpreadMode.NONE` is used).
|
|
|
|
* The constants from {SpreadMode} should be used.
|
|
|
|
*/
|
|
|
|
set spreadMode(mode) {
|
|
|
|
if (this._spreadMode === mode) {
|
|
|
|
return; // The Spread mode didn't change.
|
|
|
|
}
|
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
|
|
|
if (!isValidSpreadMode(mode)) {
|
2018-06-22 02:53:13 +09:00
|
|
|
throw new Error(`Invalid spread mode: ${mode}`);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
2018-06-29 21:14:11 +09:00
|
|
|
this._spreadMode = mode;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this.eventBus.dispatch("spreadmodechanged", { source: this, mode });
|
2018-06-29 22:07:42 +09:00
|
|
|
|
2018-06-29 22:28:38 +09:00
|
|
|
this._updateSpreadMode(/* pageNumber = */ this._currentPageNumber);
|
2018-06-29 22:07:42 +09:00
|
|
|
}
|
|
|
|
|
2018-06-29 22:28:38 +09:00
|
|
|
_updateSpreadMode(pageNumber = null) {
|
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
const viewer = this.viewer,
|
|
|
|
pages = this._pages;
|
2018-06-29 22:28:38 +09:00
|
|
|
|
2021-10-07 21:04:41 +09:00
|
|
|
if (this._scrollMode === ScrollMode.PAGE) {
|
2021-11-16 23:16:59 +09:00
|
|
|
this.#ensurePageViewVisible();
|
2018-06-29 22:28:38 +09:00
|
|
|
} else {
|
2021-10-07 21:04:41 +09:00
|
|
|
// Temporarily remove all the pages from the DOM.
|
|
|
|
viewer.textContent = "";
|
|
|
|
|
|
|
|
if (this._spreadMode === SpreadMode.NONE) {
|
2022-04-23 19:46:38 +09:00
|
|
|
for (const pageView of this._pages) {
|
2022-06-12 19:20:25 +09:00
|
|
|
viewer.append(pageView.div);
|
2021-10-07 21:04:41 +09:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
const parity = this._spreadMode - 1;
|
|
|
|
let spread = null;
|
|
|
|
for (let i = 0, ii = pages.length; i < ii; ++i) {
|
|
|
|
if (spread === null) {
|
|
|
|
spread = document.createElement("div");
|
|
|
|
spread.className = "spread";
|
2022-06-12 19:20:25 +09:00
|
|
|
viewer.append(spread);
|
2021-10-07 21:04:41 +09:00
|
|
|
} else if (i % 2 === parity) {
|
|
|
|
spread = spread.cloneNode(false);
|
2022-06-12 19:20:25 +09:00
|
|
|
viewer.append(spread);
|
2021-10-07 21:04:41 +09:00
|
|
|
}
|
2022-06-12 19:20:25 +09:00
|
|
|
spread.append(pages[i].div);
|
2018-06-29 22:28:38 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!pageNumber) {
|
|
|
|
return;
|
|
|
|
}
|
2021-10-07 21:04:41 +09:00
|
|
|
// Non-numeric scale values can be sensitive to the scroll orientation.
|
|
|
|
// Call this before re-scrolling to the current page, to ensure that any
|
|
|
|
// changes in scale don't move the current page.
|
2020-12-07 04:59:10 +09:00
|
|
|
if (this._currentScaleValue && isNaN(this._currentScaleValue)) {
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(this._currentScaleValue, { noScroll: true });
|
2020-12-07 04:59:10 +09:00
|
|
|
}
|
2018-11-09 18:16:40 +09:00
|
|
|
this._setCurrentPageNumber(pageNumber, /* resetCurrentPageView = */ true);
|
2018-06-29 22:28:38 +09:00
|
|
|
this.update();
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
2020-12-10 04:08:49 +09:00
|
|
|
|
Add previous/next-page functionality that takes scroll/spread-modes into account (issue 11946)
- For wrapped scrolling, we unfortunately need to do a fair bit of parsing of the *current* page layout. Compared to e.g. the spread-modes, where we can easily tell how the pages are laid out, with wrapped scrolling we cannot tell without actually checking. In particular documents with varying page sizes require some care, since we need to check all pages on the "row" of the current page are visible and that there aren't any "holes" present. Otherwise, in the general case, there's a risk that we'd skip over pages if we'd simply always advance to the previous/next "row" in wrapped scrolling.
- For horizontal scrolling, this patch simply maintains the current behaviour of advancing *one* page at a time. The reason for this is to prevent inconsistent behaviour for the next and previous cases, since those cannot be handled identically. For the next-case, it'd obviously be simple to advance to the first not completely visible page. However for the previous-case, we'd only be able to go back *one* page since it's not possible to (easily) determine the page layout of non-visible pages (documents with varying page sizes being a particular issue).
- For vertical scrolling, this patch maintains the current behaviour by default. When spread-modes are being used, we'll now attempt to advance to the next *spread*, rather than just the next page, whenever possible. To prevent skipping over a page, this two-page advance will only apply when both pages of the current spread are visible (to avoid breaking documents with varying page sizes) and when the second page in the current spread is fully visible *horizontally* (to handle larger zoom values).
In order to reduce the performance impact of these changes, note that the previous/next-functionality will only call `getVisibleElements` for the scroll/spread-modes where that's necessary and that "normal" vertical scrolling is thus unaffected by these changes.
To support these changes, the `getVisibleElements` helper function will now also include the `widthPercent` in addition to the existing `percent` property.
The `PDFViewer._updateHelper` method is changed slightly w.r.t. updating the `currentPageNumber` for the non-vertical/spread modes, i.e. won't affect "normal" vertical scrolling, since that helped simplify the overall calculation of the page advance.
Finally, these new `BaseViewer` methods also allow (some) simplification of previous/next-page functionality in various viewer components.
*Please note:* There's one thing that this patch does not attempt to change, namely disabling of the previous/next toolbarButtons respectively the firstPage/lastPage secondaryToolbarButtons. The reason for this is that doing so would add quite a bit of complexity in general, and if for some reason `BaseViewer._getPageAdvance` would get things wrong we could end up incorrectly disabling the buttons. Hence it seemed overall safer to *not* touch this, and accept that the buttons won't be `disabled` despite in some edge-cases no further scrolling being possible.
2021-01-16 02:45:12 +09:00
|
|
|
/**
|
|
|
|
* @private
|
|
|
|
*/
|
|
|
|
_getPageAdvance(currentPageNumber, previous = false) {
|
|
|
|
switch (this._scrollMode) {
|
|
|
|
case ScrollMode.WRAPPED: {
|
|
|
|
const { views } = this._getVisiblePages(),
|
|
|
|
pageLayout = new Map();
|
|
|
|
|
|
|
|
// Determine the current (visible) page layout.
|
|
|
|
for (const { id, y, percent, widthPercent } of views) {
|
|
|
|
if (percent === 0 || widthPercent < 100) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
let yArray = pageLayout.get(y);
|
|
|
|
if (!yArray) {
|
|
|
|
pageLayout.set(y, (yArray ||= []));
|
|
|
|
}
|
|
|
|
yArray.push(id);
|
|
|
|
}
|
|
|
|
// Find the row of the current page.
|
|
|
|
for (const yArray of pageLayout.values()) {
|
|
|
|
const currentIndex = yArray.indexOf(currentPageNumber);
|
|
|
|
if (currentIndex === -1) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
const numPages = yArray.length;
|
|
|
|
if (numPages === 1) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
// Handle documents with varying page sizes.
|
|
|
|
if (previous) {
|
|
|
|
for (let i = currentIndex - 1, ii = 0; i >= ii; i--) {
|
|
|
|
const currentId = yArray[i],
|
|
|
|
expectedId = yArray[i + 1] - 1;
|
|
|
|
if (currentId < expectedId) {
|
|
|
|
return currentPageNumber - expectedId;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
for (let i = currentIndex + 1, ii = numPages; i < ii; i++) {
|
|
|
|
const currentId = yArray[i],
|
|
|
|
expectedId = yArray[i - 1] + 1;
|
|
|
|
if (currentId > expectedId) {
|
|
|
|
return expectedId - currentPageNumber;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// The current row is "complete", advance to the previous/next one.
|
|
|
|
if (previous) {
|
|
|
|
const firstId = yArray[0];
|
|
|
|
if (firstId < currentPageNumber) {
|
|
|
|
return currentPageNumber - firstId + 1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
const lastId = yArray[numPages - 1];
|
|
|
|
if (lastId > currentPageNumber) {
|
|
|
|
return lastId - currentPageNumber + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case ScrollMode.HORIZONTAL: {
|
|
|
|
break;
|
|
|
|
}
|
2021-10-07 21:04:41 +09:00
|
|
|
case ScrollMode.PAGE:
|
Add previous/next-page functionality that takes scroll/spread-modes into account (issue 11946)
- For wrapped scrolling, we unfortunately need to do a fair bit of parsing of the *current* page layout. Compared to e.g. the spread-modes, where we can easily tell how the pages are laid out, with wrapped scrolling we cannot tell without actually checking. In particular documents with varying page sizes require some care, since we need to check all pages on the "row" of the current page are visible and that there aren't any "holes" present. Otherwise, in the general case, there's a risk that we'd skip over pages if we'd simply always advance to the previous/next "row" in wrapped scrolling.
- For horizontal scrolling, this patch simply maintains the current behaviour of advancing *one* page at a time. The reason for this is to prevent inconsistent behaviour for the next and previous cases, since those cannot be handled identically. For the next-case, it'd obviously be simple to advance to the first not completely visible page. However for the previous-case, we'd only be able to go back *one* page since it's not possible to (easily) determine the page layout of non-visible pages (documents with varying page sizes being a particular issue).
- For vertical scrolling, this patch maintains the current behaviour by default. When spread-modes are being used, we'll now attempt to advance to the next *spread*, rather than just the next page, whenever possible. To prevent skipping over a page, this two-page advance will only apply when both pages of the current spread are visible (to avoid breaking documents with varying page sizes) and when the second page in the current spread is fully visible *horizontally* (to handle larger zoom values).
In order to reduce the performance impact of these changes, note that the previous/next-functionality will only call `getVisibleElements` for the scroll/spread-modes where that's necessary and that "normal" vertical scrolling is thus unaffected by these changes.
To support these changes, the `getVisibleElements` helper function will now also include the `widthPercent` in addition to the existing `percent` property.
The `PDFViewer._updateHelper` method is changed slightly w.r.t. updating the `currentPageNumber` for the non-vertical/spread modes, i.e. won't affect "normal" vertical scrolling, since that helped simplify the overall calculation of the page advance.
Finally, these new `BaseViewer` methods also allow (some) simplification of previous/next-page functionality in various viewer components.
*Please note:* There's one thing that this patch does not attempt to change, namely disabling of the previous/next toolbarButtons respectively the firstPage/lastPage secondaryToolbarButtons. The reason for this is that doing so would add quite a bit of complexity in general, and if for some reason `BaseViewer._getPageAdvance` would get things wrong we could end up incorrectly disabling the buttons. Hence it seemed overall safer to *not* touch this, and accept that the buttons won't be `disabled` despite in some edge-cases no further scrolling being possible.
2021-01-16 02:45:12 +09:00
|
|
|
case ScrollMode.VERTICAL: {
|
|
|
|
if (this._spreadMode === SpreadMode.NONE) {
|
|
|
|
break; // Normal vertical scrolling.
|
|
|
|
}
|
|
|
|
const parity = this._spreadMode - 1;
|
|
|
|
|
|
|
|
if (previous && currentPageNumber % 2 !== parity) {
|
|
|
|
break; // Left-hand side page.
|
|
|
|
} else if (!previous && currentPageNumber % 2 === parity) {
|
|
|
|
break; // Right-hand side page.
|
|
|
|
}
|
|
|
|
const { views } = this._getVisiblePages(),
|
|
|
|
expectedId = previous ? currentPageNumber - 1 : currentPageNumber + 1;
|
|
|
|
|
|
|
|
for (const { id, percent, widthPercent } of views) {
|
|
|
|
if (id !== expectedId) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (percent > 0 && widthPercent === 100) {
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Go to the next page, taking scroll/spread-modes into account.
|
2023-03-26 04:46:02 +09:00
|
|
|
* @returns {boolean} Whether navigation occurred.
|
Add previous/next-page functionality that takes scroll/spread-modes into account (issue 11946)
- For wrapped scrolling, we unfortunately need to do a fair bit of parsing of the *current* page layout. Compared to e.g. the spread-modes, where we can easily tell how the pages are laid out, with wrapped scrolling we cannot tell without actually checking. In particular documents with varying page sizes require some care, since we need to check all pages on the "row" of the current page are visible and that there aren't any "holes" present. Otherwise, in the general case, there's a risk that we'd skip over pages if we'd simply always advance to the previous/next "row" in wrapped scrolling.
- For horizontal scrolling, this patch simply maintains the current behaviour of advancing *one* page at a time. The reason for this is to prevent inconsistent behaviour for the next and previous cases, since those cannot be handled identically. For the next-case, it'd obviously be simple to advance to the first not completely visible page. However for the previous-case, we'd only be able to go back *one* page since it's not possible to (easily) determine the page layout of non-visible pages (documents with varying page sizes being a particular issue).
- For vertical scrolling, this patch maintains the current behaviour by default. When spread-modes are being used, we'll now attempt to advance to the next *spread*, rather than just the next page, whenever possible. To prevent skipping over a page, this two-page advance will only apply when both pages of the current spread are visible (to avoid breaking documents with varying page sizes) and when the second page in the current spread is fully visible *horizontally* (to handle larger zoom values).
In order to reduce the performance impact of these changes, note that the previous/next-functionality will only call `getVisibleElements` for the scroll/spread-modes where that's necessary and that "normal" vertical scrolling is thus unaffected by these changes.
To support these changes, the `getVisibleElements` helper function will now also include the `widthPercent` in addition to the existing `percent` property.
The `PDFViewer._updateHelper` method is changed slightly w.r.t. updating the `currentPageNumber` for the non-vertical/spread modes, i.e. won't affect "normal" vertical scrolling, since that helped simplify the overall calculation of the page advance.
Finally, these new `BaseViewer` methods also allow (some) simplification of previous/next-page functionality in various viewer components.
*Please note:* There's one thing that this patch does not attempt to change, namely disabling of the previous/next toolbarButtons respectively the firstPage/lastPage secondaryToolbarButtons. The reason for this is that doing so would add quite a bit of complexity in general, and if for some reason `BaseViewer._getPageAdvance` would get things wrong we could end up incorrectly disabling the buttons. Hence it seemed overall safer to *not* touch this, and accept that the buttons won't be `disabled` despite in some edge-cases no further scrolling being possible.
2021-01-16 02:45:12 +09:00
|
|
|
*/
|
|
|
|
nextPage() {
|
|
|
|
const currentPageNumber = this._currentPageNumber,
|
|
|
|
pagesCount = this.pagesCount;
|
|
|
|
|
|
|
|
if (currentPageNumber >= pagesCount) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
const advance =
|
|
|
|
this._getPageAdvance(currentPageNumber, /* previous = */ false) || 1;
|
|
|
|
|
|
|
|
this.currentPageNumber = Math.min(currentPageNumber + advance, pagesCount);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Go to the previous page, taking scroll/spread-modes into account.
|
2023-03-26 04:46:02 +09:00
|
|
|
* @returns {boolean} Whether navigation occurred.
|
Add previous/next-page functionality that takes scroll/spread-modes into account (issue 11946)
- For wrapped scrolling, we unfortunately need to do a fair bit of parsing of the *current* page layout. Compared to e.g. the spread-modes, where we can easily tell how the pages are laid out, with wrapped scrolling we cannot tell without actually checking. In particular documents with varying page sizes require some care, since we need to check all pages on the "row" of the current page are visible and that there aren't any "holes" present. Otherwise, in the general case, there's a risk that we'd skip over pages if we'd simply always advance to the previous/next "row" in wrapped scrolling.
- For horizontal scrolling, this patch simply maintains the current behaviour of advancing *one* page at a time. The reason for this is to prevent inconsistent behaviour for the next and previous cases, since those cannot be handled identically. For the next-case, it'd obviously be simple to advance to the first not completely visible page. However for the previous-case, we'd only be able to go back *one* page since it's not possible to (easily) determine the page layout of non-visible pages (documents with varying page sizes being a particular issue).
- For vertical scrolling, this patch maintains the current behaviour by default. When spread-modes are being used, we'll now attempt to advance to the next *spread*, rather than just the next page, whenever possible. To prevent skipping over a page, this two-page advance will only apply when both pages of the current spread are visible (to avoid breaking documents with varying page sizes) and when the second page in the current spread is fully visible *horizontally* (to handle larger zoom values).
In order to reduce the performance impact of these changes, note that the previous/next-functionality will only call `getVisibleElements` for the scroll/spread-modes where that's necessary and that "normal" vertical scrolling is thus unaffected by these changes.
To support these changes, the `getVisibleElements` helper function will now also include the `widthPercent` in addition to the existing `percent` property.
The `PDFViewer._updateHelper` method is changed slightly w.r.t. updating the `currentPageNumber` for the non-vertical/spread modes, i.e. won't affect "normal" vertical scrolling, since that helped simplify the overall calculation of the page advance.
Finally, these new `BaseViewer` methods also allow (some) simplification of previous/next-page functionality in various viewer components.
*Please note:* There's one thing that this patch does not attempt to change, namely disabling of the previous/next toolbarButtons respectively the firstPage/lastPage secondaryToolbarButtons. The reason for this is that doing so would add quite a bit of complexity in general, and if for some reason `BaseViewer._getPageAdvance` would get things wrong we could end up incorrectly disabling the buttons. Hence it seemed overall safer to *not* touch this, and accept that the buttons won't be `disabled` despite in some edge-cases no further scrolling being possible.
2021-01-16 02:45:12 +09:00
|
|
|
*/
|
|
|
|
previousPage() {
|
|
|
|
const currentPageNumber = this._currentPageNumber;
|
|
|
|
|
|
|
|
if (currentPageNumber <= 1) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
const advance =
|
|
|
|
this._getPageAdvance(currentPageNumber, /* previous = */ true) || 1;
|
|
|
|
|
|
|
|
this.currentPageNumber = Math.max(currentPageNumber - advance, 1);
|
|
|
|
return true;
|
|
|
|
}
|
2021-09-19 18:54:57 +09:00
|
|
|
|
|
|
|
/**
|
2023-03-19 19:11:56 +09:00
|
|
|
* @typedef {Object} ChangeScaleOptions
|
|
|
|
* @property {number} [drawingDelay]
|
|
|
|
* @property {number} [scaleFactor]
|
|
|
|
* @property {number} [steps]
|
2021-09-19 18:54:57 +09:00
|
|
|
*/
|
2023-01-03 02:23:44 +09:00
|
|
|
|
2023-03-19 19:11:56 +09:00
|
|
|
/**
|
|
|
|
* Increase the current zoom level one, or more, times.
|
|
|
|
* @param {ChangeScaleOptions} [options]
|
|
|
|
*/
|
|
|
|
increaseScale({ drawingDelay, scaleFactor, steps } = {}) {
|
2023-01-02 22:05:33 +09:00
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
2023-01-03 02:23:44 +09:00
|
|
|
let newScale = this._currentScale;
|
2023-03-19 19:11:56 +09:00
|
|
|
if (scaleFactor > 1) {
|
2023-03-23 17:00:54 +09:00
|
|
|
newScale = Math.round(newScale * scaleFactor * 100) / 100;
|
2023-01-03 02:23:44 +09:00
|
|
|
} else {
|
2023-03-19 19:11:56 +09:00
|
|
|
steps ??= 1;
|
2023-01-03 02:23:44 +09:00
|
|
|
do {
|
2023-03-23 17:00:54 +09:00
|
|
|
newScale =
|
|
|
|
Math.ceil((newScale * DEFAULT_SCALE_DELTA).toFixed(2) * 10) / 10;
|
2023-01-03 02:23:44 +09:00
|
|
|
} while (--steps > 0 && newScale < MAX_SCALE);
|
|
|
|
}
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(Math.min(MAX_SCALE, newScale), {
|
|
|
|
noScroll: false,
|
|
|
|
drawingDelay,
|
|
|
|
});
|
2021-09-19 18:54:57 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Decrease the current zoom level one, or more, times.
|
2023-03-19 19:11:56 +09:00
|
|
|
* @param {ChangeScaleOptions} [options]
|
2021-09-19 18:54:57 +09:00
|
|
|
*/
|
2023-03-19 19:11:56 +09:00
|
|
|
decreaseScale({ drawingDelay, scaleFactor, steps } = {}) {
|
2023-01-02 22:05:33 +09:00
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
2023-01-03 02:23:44 +09:00
|
|
|
let newScale = this._currentScale;
|
2023-03-19 19:11:56 +09:00
|
|
|
if (scaleFactor > 0 && scaleFactor < 1) {
|
2023-03-23 17:00:54 +09:00
|
|
|
newScale = Math.round(newScale * scaleFactor * 100) / 100;
|
2023-01-03 02:23:44 +09:00
|
|
|
} else {
|
2023-03-19 19:11:56 +09:00
|
|
|
steps ??= 1;
|
2023-01-03 02:23:44 +09:00
|
|
|
do {
|
2023-03-23 17:00:54 +09:00
|
|
|
newScale =
|
|
|
|
Math.floor((newScale / DEFAULT_SCALE_DELTA).toFixed(2) * 10) / 10;
|
2023-01-03 02:23:44 +09:00
|
|
|
} while (--steps > 0 && newScale > MIN_SCALE);
|
|
|
|
}
|
2023-03-23 17:00:54 +09:00
|
|
|
this.#setScale(Math.max(MIN_SCALE, newScale), {
|
|
|
|
noScroll: false,
|
|
|
|
drawingDelay,
|
|
|
|
});
|
2021-09-19 18:54:57 +09:00
|
|
|
}
|
2022-05-06 00:37:33 +09:00
|
|
|
|
2022-12-15 02:47:59 +09:00
|
|
|
#updateContainerHeightCss(height = this.container.clientHeight) {
|
2022-05-06 00:37:33 +09:00
|
|
|
if (height !== this.#previousContainerHeight) {
|
|
|
|
this.#previousContainerHeight = height;
|
2022-05-23 01:00:57 +09:00
|
|
|
docStyle.setProperty("--viewer-container-height", `${height}px`);
|
2022-05-06 00:37:33 +09:00
|
|
|
}
|
|
|
|
}
|
2022-06-01 17:38:08 +09:00
|
|
|
|
2022-12-15 02:47:59 +09:00
|
|
|
#resizeObserverCallback(entries) {
|
|
|
|
for (const entry of entries) {
|
|
|
|
if (entry.target === this.container) {
|
|
|
|
this.#updateContainerHeightCss(
|
|
|
|
Math.floor(entry.borderBoxSize[0].blockSize)
|
|
|
|
);
|
|
|
|
this.#containerTopLeft = null;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
get containerTopLeft() {
|
|
|
|
return (this.#containerTopLeft ||= [
|
|
|
|
this.container.offsetTop,
|
|
|
|
this.container.offsetLeft,
|
|
|
|
]);
|
|
|
|
}
|
|
|
|
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
/**
|
2022-06-29 18:13:03 +09:00
|
|
|
* @type {number}
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
*/
|
2022-06-01 17:38:08 +09:00
|
|
|
get annotationEditorMode() {
|
2022-07-01 23:09:10 +09:00
|
|
|
return this.#annotationEditorUIManager
|
|
|
|
? this.#annotationEditorMode
|
|
|
|
: AnnotationEditorType.DISABLE;
|
2022-06-01 17:38:08 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-06-05 04:32:27 +09:00
|
|
|
* @param {number} mode - AnnotationEditor mode (None, FreeText, Ink, ...)
|
2022-06-01 17:38:08 +09:00
|
|
|
*/
|
|
|
|
set annotationEditorMode(mode) {
|
|
|
|
if (!this.#annotationEditorUIManager) {
|
|
|
|
throw new Error(`The AnnotationEditor is not enabled.`);
|
|
|
|
}
|
|
|
|
if (this.#annotationEditorMode === mode) {
|
2022-06-05 04:32:27 +09:00
|
|
|
return; // The AnnotationEditor mode didn't change.
|
2022-06-01 17:38:08 +09:00
|
|
|
}
|
2022-06-05 04:32:27 +09:00
|
|
|
if (!isValidAnnotationEditorMode(mode)) {
|
2022-06-01 17:38:08 +09:00
|
|
|
throw new Error(`Invalid AnnotationEditor mode: ${mode}`);
|
|
|
|
}
|
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049)
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1]
As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
- Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.
- Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).
- When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.
- Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
- Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
- Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while.
- Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049.
---
[1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
2022-06-01 17:38:08 +09:00
|
|
|
this.#annotationEditorMode = mode;
|
|
|
|
this.eventBus.dispatch("annotationeditormodechanged", {
|
|
|
|
source: this,
|
|
|
|
mode,
|
|
|
|
});
|
2022-06-05 04:32:27 +09:00
|
|
|
|
2022-06-01 17:38:08 +09:00
|
|
|
this.#annotationEditorUIManager.updateMode(mode);
|
|
|
|
}
|
2022-06-14 01:23:10 +09:00
|
|
|
|
|
|
|
// eslint-disable-next-line accessor-pairs
|
|
|
|
set annotationEditorParams({ type, value }) {
|
|
|
|
if (!this.#annotationEditorUIManager) {
|
|
|
|
throw new Error(`The AnnotationEditor is not enabled.`);
|
|
|
|
}
|
|
|
|
this.#annotationEditorUIManager.updateParams(type, value);
|
|
|
|
}
|
2022-08-15 23:21:58 +09:00
|
|
|
|
2022-12-12 22:24:27 +09:00
|
|
|
refresh(noUpdate = false, updateArgs = Object.create(null)) {
|
2022-08-15 23:21:58 +09:00
|
|
|
if (!this.pdfDocument) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (const pageView of this._pages) {
|
|
|
|
pageView.update(updateArgs);
|
|
|
|
}
|
2022-12-12 22:24:27 +09:00
|
|
|
if (this.#scaleTimeoutId !== null) {
|
|
|
|
clearTimeout(this.#scaleTimeoutId);
|
|
|
|
this.#scaleTimeoutId = null;
|
|
|
|
}
|
|
|
|
if (!noUpdate) {
|
|
|
|
this.update();
|
|
|
|
}
|
2022-08-15 23:21:58 +09:00
|
|
|
}
|
2017-07-09 20:07:06 +09:00
|
|
|
}
|
2014-09-15 23:49:24 +09:00
|
|
|
|
2022-09-08 18:51:17 +09:00
|
|
|
export { PagesCountLimit, PDFPageViewBuffer, PDFViewer };
|