2014-09-30 01:05:28 +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").PDFPageProxy} PDFPageProxy */
|
|
|
|
// eslint-disable-next-line max-len
|
|
|
|
/** @typedef {import("../src/display/display_utils").PageViewport} PageViewport */
|
|
|
|
/** @typedef {import("./interfaces").IDownloadManager} IDownloadManager */
|
|
|
|
/** @typedef {import("./interfaces").IL10n} IL10n */
|
|
|
|
/** @typedef {import("./interfaces").IPDFLinkService} IPDFLinkService */
|
2022-07-29 00:59:03 +09:00
|
|
|
// eslint-disable-next-line max-len
|
|
|
|
/** @typedef {import("./textaccessibility.js").TextAccessibilityManager} TextAccessibilityManager */
|
Fix Viewer API definitions and include in CI
The Viewer API definitions do not compile because of missing imports and
anonymous objects are typed as `Object`. These issues were not caught
during CI because the test project was not compiling anything from the
Viewer API.
As an example of the first problem:
```
/**
* @implements MyInterface
*/
export class MyClass {
...
}
```
will generate a broken definition that doesn’t import MyInterface:
```
/**
* @implements MyInterface
*/
export class MyClass implements MyInterface {
...
}
```
This can be fixed by adding a typedef jsdoc to specify the import:
```
/** @typedef {import("./otherFile").MyInterface} MyInterface */
```
See https://github.com/jsdoc/jsdoc/issues/1537 and
https://github.com/microsoft/TypeScript/issues/22160 for more details.
As an example of the second problem:
```
/**
* Gets the size of the specified page, converted from PDF units to inches.
* @param {Object} An Object containing the properties: {Array} `view`,
* {number} `userUnit`, and {number} `rotate`.
*/
function getPageSizeInches({ view, userUnit, rotate }) {
...
}
```
generates the broken definition:
```
function getPageSizeInches({ view, userUnit, rotate }: Object) {
...
}
```
The jsdoc should specify the type of each nested property:
```
/**
* Gets the size of the specified page, converted from PDF units to inches.
* @param {Object} options An object containing the properties: {Array} `view`,
* {number} `userUnit`, and {number} `rotate`.
* @param {number[]} options.view
* @param {number} options.userUnit
* @param {number} options.rotate
*/
```
2021-08-26 07:44: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
|
|
|
import { AnnotationLayer } from "pdfjs-lib";
|
2021-02-22 20:43:16 +09:00
|
|
|
import { NullL10n } from "./l10n_utils.js";
|
2022-10-31 01:36:20 +09:00
|
|
|
import { PresentationModeState } from "./ui_utils.js";
|
2016-04-09 02:34:27 +09:00
|
|
|
|
2014-09-30 01:05:28 +09:00
|
|
|
/**
|
2015-12-17 20:54:53 +09:00
|
|
|
* @typedef {Object} AnnotationLayerBuilderOptions
|
2014-09-30 01:05:28 +09:00
|
|
|
* @property {HTMLDivElement} pageDiv
|
2021-12-15 07:59:17 +09:00
|
|
|
* @property {PDFPageProxy} pdfPage
|
[api-minor] Fix the `AnnotationStorage` usage properly in the viewer/tests (PR 12107 and 12143 follow-up)
*The [api-minor] label probably ought to have been added to the original PR, given the changes to the `createAnnotationLayerBuilder` signature (if nothing else).*
This patch fixes the following things:
- Let the `AnnotationLayer.render` method create an `AnnotationStorage`-instance if none was provided, thus making the parameter *properly* optional. This not only fixes the reference tests, it also prevents issues when the viewer components are used.
- Stop exporting `AnnotationStorage` in the official API, i.e. the `src/pdf.js` file, since it's no longer necessary given the change above. Generally speaking, unless absolutely necessary we probably shouldn't export unused things in the API.
- Fix a number of JSDocs `typedef`s, in `src/display/` and `web/` code, to actually account for the new `annotationStorage` parameter.
- Update `web/interfaces.js` to account for the changes in `createAnnotationLayerBuilder`.
- Initialize the storage, in `AnnotationStorage`, using `Object.create(null)` rather than `{}` (which is the PDF.js default).
2020-07-31 23:13:26 +09:00
|
|
|
* @property {AnnotationStorage} [annotationStorage]
|
2019-10-12 23:30:32 +09:00
|
|
|
* @property {string} [imageResourcesPath] - Path for image resources, mainly
|
|
|
|
* for annotation icons. Include trailing slash.
|
[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 {boolean} renderForms
|
2014-09-30 01:05:28 +09:00
|
|
|
* @property {IPDFLinkService} linkService
|
2021-12-15 07:59:17 +09:00
|
|
|
* @property {IDownloadManager} downloadManager
|
2017-05-04 10:05:53 +09:00
|
|
|
* @property {IL10n} l10n - Localization service.
|
2020-10-29 03:16:56 +09:00
|
|
|
* @property {boolean} [enableScripting]
|
|
|
|
* @property {Promise<boolean>} [hasJSActionsPromise]
|
2021-09-14 19:06:28 +09:00
|
|
|
* @property {Promise<Object<string, Array<Object>> | null>}
|
|
|
|
* [fieldObjectsPromise]
|
2021-12-15 07:59:17 +09:00
|
|
|
* @property {Map<string, HTMLCanvasElement>} [annotationCanvasMap]
|
2022-12-08 00:12:48 +09:00
|
|
|
* @property {TextAccessibilityManager} [accessibilityManager]
|
2014-09-30 01:05:28 +09:00
|
|
|
*/
|
|
|
|
|
2017-04-24 03:52:58 +09:00
|
|
|
class AnnotationLayerBuilder {
|
2022-12-11 22:51:28 +09:00
|
|
|
#numAnnotations = 0;
|
|
|
|
|
2022-10-31 01:36:20 +09:00
|
|
|
#onPresentationModeChanged = null;
|
|
|
|
|
2014-09-30 01:05:28 +09:00
|
|
|
/**
|
2015-12-17 20:54:53 +09:00
|
|
|
* @param {AnnotationLayerBuilderOptions} options
|
2014-09-30 01:05:28 +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
|
|
|
constructor({
|
|
|
|
pageDiv,
|
|
|
|
pdfPage,
|
|
|
|
linkService,
|
|
|
|
downloadManager,
|
[api-minor] Fix the `AnnotationStorage` usage properly in the viewer/tests (PR 12107 and 12143 follow-up)
*The [api-minor] label probably ought to have been added to the original PR, given the changes to the `createAnnotationLayerBuilder` signature (if nothing else).*
This patch fixes the following things:
- Let the `AnnotationLayer.render` method create an `AnnotationStorage`-instance if none was provided, thus making the parameter *properly* optional. This not only fixes the reference tests, it also prevents issues when the viewer components are used.
- Stop exporting `AnnotationStorage` in the official API, i.e. the `src/pdf.js` file, since it's no longer necessary given the change above. Generally speaking, unless absolutely necessary we probably shouldn't export unused things in the API.
- Fix a number of JSDocs `typedef`s, in `src/display/` and `web/` code, to actually account for the new `annotationStorage` parameter.
- Update `web/interfaces.js` to account for the changes in `createAnnotationLayerBuilder`.
- Initialize the storage, in `AnnotationStorage`, using `Object.create(null)` rather than `{}` (which is the PDF.js default).
2020-07-31 23:13:26 +09:00
|
|
|
annotationStorage = 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
|
|
|
imageResourcesPath = "",
|
[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
|
|
|
renderForms = true,
|
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 = NullL10n,
|
2020-10-29 03:16:56 +09:00
|
|
|
enableScripting = false,
|
|
|
|
hasJSActionsPromise = null,
|
2021-09-14 19:06:28 +09:00
|
|
|
fieldObjectsPromise = null,
|
2021-11-07 02:36:49 +09:00
|
|
|
annotationCanvasMap = null,
|
2022-07-29 00:59:03 +09:00
|
|
|
accessibilityManager = 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
|
|
|
}) {
|
2017-06-30 19:55:22 +09:00
|
|
|
this.pageDiv = pageDiv;
|
|
|
|
this.pdfPage = pdfPage;
|
|
|
|
this.linkService = linkService;
|
|
|
|
this.downloadManager = downloadManager;
|
2018-02-13 21:17:11 +09:00
|
|
|
this.imageResourcesPath = imageResourcesPath;
|
[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.renderForms = renderForms;
|
2017-06-30 19:55:22 +09:00
|
|
|
this.l10n = l10n;
|
2020-07-22 20:55:52 +09:00
|
|
|
this.annotationStorage = annotationStorage;
|
2020-10-29 03:16:56 +09:00
|
|
|
this.enableScripting = enableScripting;
|
2022-12-11 22:51:28 +09:00
|
|
|
this._hasJSActionsPromise = hasJSActionsPromise || Promise.resolve(false);
|
|
|
|
this._fieldObjectsPromise = fieldObjectsPromise || Promise.resolve(null);
|
2021-11-07 02:36:49 +09:00
|
|
|
this._annotationCanvasMap = annotationCanvasMap;
|
2022-07-29 00:59:03 +09:00
|
|
|
this._accessibilityManager = accessibilityManager;
|
2014-09-30 01:05:28 +09:00
|
|
|
|
|
|
|
this.div = null;
|
Prevent the `annotationLayer` from, in some cases, becoming duplicated on the first page when the document loads
I don't know if this is a regression, but I noticed earlier today that depending on the initial scale *and* sidebar state, the `annotationLayer` of the first rendered page may end up duplicated; please see screen-shot below.
[screen-shot]
I can reproduce this reliable with e.g. https://arxiv.org/pdf/1112.0542v1.pdf#zoom=page-width&pagemode=bookmarks.
When the document loads, rendering of the first page begins immediately. When the sidebar is then opened, that forces re-rendering which thus aborts rendering of the first page.
Note that calling `PDFPageView.draw()` will always, provided an `AnnotationLayerFactory` instance exists, call `AnnotationLayerBuilder.render()`. Hence the events described above will result in *two* such calls, where the actual annotation rendering/updating happens asynchronously.
For reasons that I don't (at all) understand, when multiple `pdfPage.getAnnotations()` promises are handled back-to-back (in `AnnotationLayerBuilder.render()`), the `this.div` property seems to not update in time for the subsequent calls.
This thus, at least in Firefox, result in double rendering of all annotations on the first page.
Obviously it'd be good to find out why it breaks, since it *really* shouldn't, but this patch at least provides a (hopefully) acceptable work-around by ignoring `getAnnotations()` calls for `AnnotationLayerBuilder` instances that we're destroying (in `PDFPageView.reset()`).
2017-10-07 00:26:54 +09:00
|
|
|
this._cancelled = false;
|
2022-10-31 01:36:20 +09:00
|
|
|
this._eventBus = linkService.eventBus;
|
2014-09-30 01:05:28 +09:00
|
|
|
}
|
2015-12-03 08:20:18 +09:00
|
|
|
|
2017-04-24 03:52:58 +09:00
|
|
|
/**
|
|
|
|
* @param {PageViewport} viewport
|
|
|
|
* @param {string} intent (default value is 'display')
|
2020-08-18 05:19:03 +09:00
|
|
|
* @returns {Promise<void>} A promise that is resolved when rendering of the
|
|
|
|
* annotations is complete.
|
2017-04-24 03:52:58 +09:00
|
|
|
*/
|
2021-09-14 19:06:28 +09:00
|
|
|
async render(viewport, intent = "display") {
|
2022-12-11 22:51:28 +09:00
|
|
|
if (this.div) {
|
|
|
|
if (this._cancelled || this.#numAnnotations === 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// If an annotationLayer already exists, refresh its children's
|
|
|
|
// transformation matrices.
|
|
|
|
AnnotationLayer.update({
|
|
|
|
viewport: viewport.clone({ dontFlip: true }),
|
|
|
|
div: this.div,
|
|
|
|
annotationCanvasMap: this._annotationCanvasMap,
|
|
|
|
});
|
2021-09-14 19:06:28 +09:00
|
|
|
return;
|
|
|
|
}
|
2014-09-30 01:05:28 +09:00
|
|
|
|
2022-12-11 22:51:28 +09:00
|
|
|
const [annotations, hasJSActions, fieldObjects] = await Promise.all([
|
|
|
|
this.pdfPage.getAnnotations({ intent }),
|
|
|
|
this._hasJSActionsPromise,
|
|
|
|
this._fieldObjectsPromise,
|
|
|
|
]);
|
|
|
|
if (this._cancelled) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
this.#numAnnotations = annotations.length;
|
|
|
|
|
|
|
|
// Create an annotation layer div and render the annotations
|
|
|
|
// if there is at least one annotation.
|
|
|
|
this.div = document.createElement("div");
|
|
|
|
this.div.className = "annotationLayer";
|
|
|
|
this.pageDiv.append(this.div);
|
|
|
|
|
|
|
|
if (this.#numAnnotations === 0) {
|
|
|
|
this.hide();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
AnnotationLayer.render({
|
2021-09-14 19:06:28 +09:00
|
|
|
viewport: viewport.clone({ dontFlip: true }),
|
|
|
|
div: this.div,
|
|
|
|
annotations,
|
|
|
|
page: this.pdfPage,
|
|
|
|
imageResourcesPath: this.imageResourcesPath,
|
|
|
|
renderForms: this.renderForms,
|
|
|
|
linkService: this.linkService,
|
|
|
|
downloadManager: this.downloadManager,
|
|
|
|
annotationStorage: this.annotationStorage,
|
|
|
|
enableScripting: this.enableScripting,
|
|
|
|
hasJSActions,
|
|
|
|
fieldObjects,
|
2021-11-07 02:36:49 +09:00
|
|
|
annotationCanvasMap: this._annotationCanvasMap,
|
2022-07-29 00:59:03 +09:00
|
|
|
accessibilityManager: this._accessibilityManager,
|
2022-12-11 22:51:28 +09:00
|
|
|
});
|
|
|
|
this.l10n.translate(this.div);
|
2015-12-09 07:38:32 +09:00
|
|
|
|
2022-12-11 22:51:28 +09:00
|
|
|
// Ensure that interactive form elements in the annotationLayer are
|
|
|
|
// disabled while PresentationMode is active (see issue 12232).
|
|
|
|
if (this.linkService.isInPresentationMode) {
|
|
|
|
this.#updatePresentationModeState(PresentationModeState.FULLSCREEN);
|
|
|
|
}
|
|
|
|
if (!this.#onPresentationModeChanged) {
|
|
|
|
this.#onPresentationModeChanged = evt => {
|
|
|
|
this.#updatePresentationModeState(evt.state);
|
|
|
|
};
|
|
|
|
this._eventBus?._on(
|
|
|
|
"presentationmodechanged",
|
|
|
|
this.#onPresentationModeChanged
|
|
|
|
);
|
2021-09-14 19:06:28 +09:00
|
|
|
}
|
2017-04-24 03:52:58 +09:00
|
|
|
}
|
2015-12-03 08:20:18 +09:00
|
|
|
|
Prevent the `annotationLayer` from, in some cases, becoming duplicated on the first page when the document loads
I don't know if this is a regression, but I noticed earlier today that depending on the initial scale *and* sidebar state, the `annotationLayer` of the first rendered page may end up duplicated; please see screen-shot below.
[screen-shot]
I can reproduce this reliable with e.g. https://arxiv.org/pdf/1112.0542v1.pdf#zoom=page-width&pagemode=bookmarks.
When the document loads, rendering of the first page begins immediately. When the sidebar is then opened, that forces re-rendering which thus aborts rendering of the first page.
Note that calling `PDFPageView.draw()` will always, provided an `AnnotationLayerFactory` instance exists, call `AnnotationLayerBuilder.render()`. Hence the events described above will result in *two* such calls, where the actual annotation rendering/updating happens asynchronously.
For reasons that I don't (at all) understand, when multiple `pdfPage.getAnnotations()` promises are handled back-to-back (in `AnnotationLayerBuilder.render()`), the `this.div` property seems to not update in time for the subsequent calls.
This thus, at least in Firefox, result in double rendering of all annotations on the first page.
Obviously it'd be good to find out why it breaks, since it *really* shouldn't, but this patch at least provides a (hopefully) acceptable work-around by ignoring `getAnnotations()` calls for `AnnotationLayerBuilder` instances that we're destroying (in `PDFPageView.reset()`).
2017-10-07 00:26:54 +09:00
|
|
|
cancel() {
|
|
|
|
this._cancelled = true;
|
2022-10-31 01:36:20 +09:00
|
|
|
|
|
|
|
if (this.#onPresentationModeChanged) {
|
|
|
|
this._eventBus?._off(
|
|
|
|
"presentationmodechanged",
|
|
|
|
this.#onPresentationModeChanged
|
|
|
|
);
|
|
|
|
this.#onPresentationModeChanged = null;
|
|
|
|
}
|
Prevent the `annotationLayer` from, in some cases, becoming duplicated on the first page when the document loads
I don't know if this is a regression, but I noticed earlier today that depending on the initial scale *and* sidebar state, the `annotationLayer` of the first rendered page may end up duplicated; please see screen-shot below.
[screen-shot]
I can reproduce this reliable with e.g. https://arxiv.org/pdf/1112.0542v1.pdf#zoom=page-width&pagemode=bookmarks.
When the document loads, rendering of the first page begins immediately. When the sidebar is then opened, that forces re-rendering which thus aborts rendering of the first page.
Note that calling `PDFPageView.draw()` will always, provided an `AnnotationLayerFactory` instance exists, call `AnnotationLayerBuilder.render()`. Hence the events described above will result in *two* such calls, where the actual annotation rendering/updating happens asynchronously.
For reasons that I don't (at all) understand, when multiple `pdfPage.getAnnotations()` promises are handled back-to-back (in `AnnotationLayerBuilder.render()`), the `this.div` property seems to not update in time for the subsequent calls.
This thus, at least in Firefox, result in double rendering of all annotations on the first page.
Obviously it'd be good to find out why it breaks, since it *really* shouldn't, but this patch at least provides a (hopefully) acceptable work-around by ignoring `getAnnotations()` calls for `AnnotationLayerBuilder` instances that we're destroying (in `PDFPageView.reset()`).
2017-10-07 00:26:54 +09:00
|
|
|
}
|
|
|
|
|
2017-04-24 03:52:58 +09:00
|
|
|
hide() {
|
|
|
|
if (!this.div) {
|
|
|
|
return;
|
|
|
|
}
|
2021-02-08 08:21:49 +09:00
|
|
|
this.div.hidden = true;
|
2017-04-24 03:52:58 +09:00
|
|
|
}
|
2022-10-31 01:36:20 +09:00
|
|
|
|
|
|
|
#updatePresentationModeState(state) {
|
|
|
|
if (!this.div) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
let disableFormElements = false;
|
|
|
|
|
|
|
|
switch (state) {
|
|
|
|
case PresentationModeState.FULLSCREEN:
|
|
|
|
disableFormElements = true;
|
|
|
|
break;
|
|
|
|
case PresentationModeState.NORMAL:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (const section of this.div.childNodes) {
|
|
|
|
if (section.hasAttribute("data-internal-link")) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
section.inert = disableFormElements;
|
|
|
|
}
|
|
|
|
}
|
2017-04-24 03:52:58 +09:00
|
|
|
}
|
2014-12-18 05:47:14 +09:00
|
|
|
|
2021-12-15 21:54:29 +09:00
|
|
|
export { AnnotationLayerBuilder };
|