2014-10-01 02:22:38 +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.
|
|
|
|
*/
|
|
|
|
|
2023-06-24 20:23:02 +09:00
|
|
|
import { FindState, PDFFindController } from "./pdf_find_controller.js";
|
2022-01-03 21:36:49 +09:00
|
|
|
import {
|
|
|
|
LinkTarget,
|
|
|
|
PDFLinkService,
|
|
|
|
SimpleLinkService,
|
|
|
|
} from "./pdf_link_service.js";
|
2022-08-11 22:41:30 +09:00
|
|
|
import {
|
|
|
|
parseQueryString,
|
|
|
|
ProgressBar,
|
|
|
|
RenderingStates,
|
|
|
|
ScrollMode,
|
|
|
|
SpreadMode,
|
|
|
|
} from "./ui_utils.js";
|
2021-12-15 21:54:29 +09:00
|
|
|
import { AnnotationLayerBuilder } from "./annotation_layer_builder.js";
|
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 { DownloadManager } from "./download_manager.js";
|
2021-12-16 01:09:16 +09:00
|
|
|
import { EventBus } from "./event_utils.js";
|
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 { GenericL10n } from "./genericl10n.js";
|
2021-02-22 20:43:16 +09:00
|
|
|
import { NullL10n } from "./l10n_utils.js";
|
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 { PDFHistory } from "./pdf_history.js";
|
|
|
|
import { PDFPageView } from "./pdf_page_view.js";
|
2023-07-13 20:10:06 +09:00
|
|
|
import { PDFScriptingManager } from "./pdf_scripting_manager.component.js";
|
2022-09-08 18:51:17 +09:00
|
|
|
import { PDFSinglePageViewer } from "./pdf_single_page_viewer.js";
|
2022-09-08 18:53:56 +09:00
|
|
|
import { PDFViewer } from "./pdf_viewer.js";
|
2021-12-15 21:54:29 +09:00
|
|
|
import { StructTreeLayerBuilder } from "./struct_tree_layer_builder.js";
|
|
|
|
import { TextLayerBuilder } from "./text_layer_builder.js";
|
|
|
|
import { XfaLayerBuilder } from "./xfa_layer_builder.js";
|
2016-04-09 04:15:48 +09:00
|
|
|
|
2023-06-23 19:21:58 +09:00
|
|
|
/* eslint-disable-next-line no-unused-vars */
|
|
|
|
const pdfjsVersion =
|
|
|
|
typeof PDFJSDev !== "undefined" ? PDFJSDev.eval("BUNDLE_VERSION") : void 0;
|
|
|
|
/* eslint-disable-next-line no-unused-vars */
|
|
|
|
const pdfjsBuild =
|
|
|
|
typeof PDFJSDev !== "undefined" ? PDFJSDev.eval("BUNDLE_BUILD") : void 0;
|
2015-04-27 23:04:11 +09:00
|
|
|
|
2017-11-05 21:45:32 +09:00
|
|
|
export {
|
2018-02-18 07:51:24 +09:00
|
|
|
AnnotationLayerBuilder,
|
|
|
|
DownloadManager,
|
2021-01-09 23:37:44 +09:00
|
|
|
EventBus,
|
2023-06-24 20:23:02 +09:00
|
|
|
FindState,
|
2018-02-18 07:51:24 +09:00
|
|
|
GenericL10n,
|
2022-01-03 21:36:49 +09:00
|
|
|
LinkTarget,
|
2018-02-18 07:51:24 +09:00
|
|
|
NullL10n,
|
2022-02-19 17:41:04 +09:00
|
|
|
parseQueryString,
|
2021-01-09 23:37:44 +09:00
|
|
|
PDFFindController,
|
|
|
|
PDFHistory,
|
|
|
|
PDFLinkService,
|
|
|
|
PDFPageView,
|
[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
|
|
|
PDFScriptingManager,
|
2021-01-09 23:37:44 +09:00
|
|
|
PDFSinglePageViewer,
|
|
|
|
PDFViewer,
|
|
|
|
ProgressBar,
|
2022-08-11 22:41:30 +09:00
|
|
|
RenderingStates,
|
|
|
|
ScrollMode,
|
2021-01-09 23:37:44 +09:00
|
|
|
SimpleLinkService,
|
2022-08-11 22:41:30 +09:00
|
|
|
SpreadMode,
|
Export the XFA/StructTree-layers in the viewer components
While e.g. the `simpleviewer` and `singlepageviewer` examples work, since they're based on the `BaseViewer`-class, the standalone `pageviewer` example currently doesn't support either XFA- or StructTree-layers. This seems like an obvious oversight, which can be easily addressed simply by exporting the necessary functionality through `pdf_viewer.component.js`, similar to the existing Text/Annotation-layers.
While working on, and testing, these changes I happened to notice a number of smaller things that's also fixed in this patch:
- Ensure that `XfaLayerBuilder.render` always have a *consistent* return type, to prevent possible run-time failures in `PDFPageView`; PR 13908 follow-up.
- Change the order of the options in the `XfaLayerBuilder`-constructor to agree with the parameter order in the `DefaultXfaLayerFactory.createXfaLayerBuilder`-method.
- Add a missing `textHighlighterFactory`-option, in the JSDocs for the `PDFPageView`-class.
- A couple of small tweaks in the `TextLayerBuilder.render`-method: Re-use an existing Array rather than creating a new one, and replace an `if` with optional chaining instead.
*Please note:* For now XFA-support is currently disabled by default, similar to the regular viewer.
2021-08-29 01:09:39 +09:00
|
|
|
StructTreeLayerBuilder,
|
2021-01-09 23:37:44 +09:00
|
|
|
TextLayerBuilder,
|
Export the XFA/StructTree-layers in the viewer components
While e.g. the `simpleviewer` and `singlepageviewer` examples work, since they're based on the `BaseViewer`-class, the standalone `pageviewer` example currently doesn't support either XFA- or StructTree-layers. This seems like an obvious oversight, which can be easily addressed simply by exporting the necessary functionality through `pdf_viewer.component.js`, similar to the existing Text/Annotation-layers.
While working on, and testing, these changes I happened to notice a number of smaller things that's also fixed in this patch:
- Ensure that `XfaLayerBuilder.render` always have a *consistent* return type, to prevent possible run-time failures in `PDFPageView`; PR 13908 follow-up.
- Change the order of the options in the `XfaLayerBuilder`-constructor to agree with the parameter order in the `DefaultXfaLayerFactory.createXfaLayerBuilder`-method.
- Add a missing `textHighlighterFactory`-option, in the JSDocs for the `PDFPageView`-class.
- A couple of small tweaks in the `TextLayerBuilder.render`-method: Re-use an existing Array rather than creating a new one, and replace an `if` with optional chaining instead.
*Please note:* For now XFA-support is currently disabled by default, similar to the regular viewer.
2021-08-29 01:09:39 +09:00
|
|
|
XfaLayerBuilder,
|
2017-11-05 21:45:32 +09:00
|
|
|
};
|