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.
|
|
|
|
*/
|
|
|
|
|
2018-12-06 21:55:15 +09:00
|
|
|
if (!pdfjsLib.getDocument || !pdfjsViewer.PDFViewer) {
|
2021-01-23 01:38:26 +09:00
|
|
|
// eslint-disable-next-line no-alert
|
2019-12-26 04:03:46 +09:00
|
|
|
alert("Please build the pdfjs-dist library using\n `gulp dist-install`");
|
2014-10-01 02:22:38 +09:00
|
|
|
}
|
|
|
|
|
2015-11-06 22:39:13 +09:00
|
|
|
// The workerSrc property shall be specified.
|
2014-10-01 02:22:38 +09:00
|
|
|
//
|
2018-03-16 05:49:28 +09:00
|
|
|
pdfjsLib.GlobalWorkerOptions.workerSrc =
|
2023-10-14 18:24:56 +09:00
|
|
|
"../../node_modules/pdfjs-dist/build/pdf.worker.mjs";
|
2014-10-01 02:22:38 +09:00
|
|
|
|
2014-10-01 05:42:28 +09:00
|
|
|
// Some PDFs need external cmaps.
|
2014-10-01 02:22:38 +09:00
|
|
|
//
|
2021-03-13 01:08:17 +09:00
|
|
|
const CMAP_URL = "../../node_modules/pdfjs-dist/cmaps/";
|
|
|
|
const CMAP_PACKED = true;
|
2014-10-01 02:22:38 +09:00
|
|
|
|
2021-03-13 01:08:17 +09:00
|
|
|
const DEFAULT_URL = "../../web/compressed.tracemonkey-pldi-09.pdf";
|
[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
|
|
|
// To test the AcroForm and/or scripting functionality, try e.g. this file:
|
2021-09-08 19:33:59 +09:00
|
|
|
// "../../test/pdfs/160F-2019.pdf"
|
|
|
|
|
|
|
|
const ENABLE_XFA = true;
|
|
|
|
const SEARCH_FOR = ""; // try "Mozilla";
|
[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
|
|
|
|
2023-10-14 18:24:56 +09:00
|
|
|
const SANDBOX_BUNDLE_SRC = new URL(
|
|
|
|
"../../node_modules/pdfjs-dist/build/pdf.sandbox.mjs",
|
|
|
|
window.location
|
|
|
|
);
|
[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
|
|
|
|
2021-03-13 01:08:17 +09:00
|
|
|
const container = document.getElementById("viewerContainer");
|
2015-06-25 19:24:29 +09:00
|
|
|
|
2021-03-13 01:08:17 +09:00
|
|
|
const eventBus = new pdfjsViewer.EventBus();
|
2020-02-27 01:16:30 +09:00
|
|
|
|
2015-06-25 19:24:29 +09:00
|
|
|
// (Optionally) enable hyperlinks within PDF files.
|
2021-03-13 01:08:17 +09:00
|
|
|
const pdfLinkService = new pdfjsViewer.PDFLinkService({
|
2021-01-23 01:38:26 +09:00
|
|
|
eventBus,
|
2020-02-27 01:16:30 +09:00
|
|
|
});
|
2015-06-25 19:24:29 +09:00
|
|
|
|
2018-09-23 02:44:13 +09:00
|
|
|
// (Optionally) enable find controller.
|
2021-03-13 01:08:17 +09:00
|
|
|
const pdfFindController = new pdfjsViewer.PDFFindController({
|
2021-01-23 01:38:26 +09:00
|
|
|
eventBus,
|
2015-06-25 19:24:29 +09:00
|
|
|
linkService: pdfLinkService,
|
2014-10-01 02:31:58 +09:00
|
|
|
});
|
|
|
|
|
[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
|
|
|
// (Optionally) enable scripting support.
|
2021-03-13 01:08:17 +09:00
|
|
|
const pdfScriptingManager = new pdfjsViewer.PDFScriptingManager({
|
[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
|
|
|
eventBus,
|
|
|
|
sandboxBundleSrc: SANDBOX_BUNDLE_SRC,
|
|
|
|
});
|
|
|
|
|
2021-03-13 01:08:17 +09:00
|
|
|
const pdfViewer = new pdfjsViewer.PDFViewer({
|
2021-01-23 01:38:26 +09:00
|
|
|
container,
|
|
|
|
eventBus,
|
2018-09-22 02:40:11 +09:00
|
|
|
linkService: pdfLinkService,
|
2018-09-23 02:44:13 +09:00
|
|
|
findController: pdfFindController,
|
[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
|
|
|
scriptingManager: pdfScriptingManager,
|
2016-04-14 04:39:29 +09:00
|
|
|
});
|
2018-09-23 02:44:13 +09:00
|
|
|
pdfLinkService.setViewer(pdfViewer);
|
[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.setViewer(pdfViewer);
|
2016-04-14 04:39:29 +09:00
|
|
|
|
2020-04-14 19:28:14 +09:00
|
|
|
eventBus.on("pagesinit", function () {
|
2015-06-25 19:24:29 +09:00
|
|
|
// We can use pdfViewer now, e.g. let's change default scale.
|
2014-10-01 02:31:58 +09:00
|
|
|
pdfViewer.currentScaleValue = "page-width";
|
2016-04-14 04:39:29 +09:00
|
|
|
|
2019-12-26 04:03:46 +09:00
|
|
|
// We can try searching for things.
|
2016-04-14 04:39:29 +09:00
|
|
|
if (SEARCH_FOR) {
|
2022-03-02 19:21:47 +09:00
|
|
|
eventBus.dispatch("find", { type: "", query: SEARCH_FOR });
|
2016-04-14 04:39:29 +09:00
|
|
|
}
|
2014-10-01 02:22:38 +09:00
|
|
|
});
|
|
|
|
|
|
|
|
// Loading document.
|
2021-03-13 01:08:17 +09:00
|
|
|
const loadingTask = pdfjsLib.getDocument({
|
2018-02-18 00:57:24 +09:00
|
|
|
url: DEFAULT_URL,
|
|
|
|
cMapUrl: CMAP_URL,
|
|
|
|
cMapPacked: CMAP_PACKED,
|
2021-09-08 19:33:59 +09:00
|
|
|
enableXfa: ENABLE_XFA,
|
2018-11-08 21:40:06 +09:00
|
|
|
});
|
2023-10-14 18:24:56 +09:00
|
|
|
|
|
|
|
const pdfDocument = await loadingTask.promise;
|
|
|
|
// Document loaded, specifying document for the viewer and
|
|
|
|
// the (optional) linkService.
|
|
|
|
pdfViewer.setDocument(pdfDocument);
|
|
|
|
|
|
|
|
pdfLinkService.setDocument(pdfDocument, null);
|