ZenBrowserMirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/zen-browser/pdf.js.git synced 2025-07-08 01:10:08 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

[api-minor] Move the viewer scripting initialization/handling into a new PDFScriptingManager class

Browse source 
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.
This commit is contained in:
Jonas Jenwald 2021-03-05 00:15:18 +01:00
parent 5b9638329c
commit a6d1cba38c
8 changed files with 525 additions and 261 deletions
Download patch file Download diff file Expand all files Collapse all files

32
web/generic_scripting.js
View file

@ -13,8 +13,38 @@
* limitations under the License.
*/
import { getPDFFileNameFromURL } from "./ui_utils.js";
import { loadScript } from "pdfjs-lib";
async function docPropertiesLookup(pdfDocument) {
const url = "",
baseUrl = url.split("#")[0];
/* eslint-disable prefer-const */
let {
info,
metadata,
contentDispositionFilename,
contentLength,
} = await pdfDocument.getMetadata();
/* eslint-enable prefer-const */
if (!contentLength) {
const { length } = await pdfDocument.getDownloadInfo();
contentLength = length;
}
return {
...info,
baseURL: baseUrl,
filesize: contentLength,
filename: contentDispositionFilename || getPDFFileNameFromURL(url),
metadata: metadata?.getRaw(),
authors: metadata?.get("dc:creator"),
numPages: pdfDocument.numPages,
URL: url,
};
}
class GenericScripting {
constructor(sandboxBundleSrc) {
this._ready = loadScript(
@ -41,4 +71,4 @@ class GenericScripting {
}
}
export { GenericScripting };
export { docPropertiesLookup, GenericScripting };