[api-major] Move the remaining options from, and completely remove, the global PDFJS object
#9493
Commits on Mar 1, 2018
-
Move API specific compatibility options from `src/shared/compatibilit…
…y.js` and into a separate file Unfortunately, as far as I can tell, we still need the ability to adjust certain API options depending on the browser environment in PDF.js version `2.0`. However, we should be able to separate this from the general compatibility code in the `src/shared/compatibility.js` file.
-
Introduce a
AppOptionsabstraction in preparation for a complete re……factoring of the way that viewer options are handled The way that various options are handled in the default viewer is currently a bit of a mess (to say the least). Some viewer options reside in the global `PDFJS` object, while others reside in `Preferences`. To make matters worse, some options even exist in both of the two. Since the goal, with PDF.js version `2.0`, is to reduce our usage of the global `PDFJS` object, we'll instead want pass in the options when initializing the viewer components and when calling API methods (such as `getDocument`). However given the current state of things in the default viewer, this wouldn't be exactly easy to implement. Hence this patch, which attempts to consolidate the way that viewer (and later API) options are handled by introducing a `AppOptions` singleton that provides *one* centralized way of interacting with the various options in the default viewer.
-
Move various viewer components options from
PDFJS/`PDFViewerApplica……tion.viewerPrefs` and into `AppOptions` instead
-
Move the
defaultUrlparameter from theappConfigand into `AppOpt……ions` instead The `appConfig` contains (mostly) references to various DOM elements, used when initializing the viewer components. Hence `defaultUrl` seem like a slightly better fit for the new `AppOptions` abstraction, not to mention that it should thus be easier to set/modify it for custom deployments of the default viewer.
-
Refactor how the default viewer handles the worker options, by making…
… use of `AppOptions` instead of the global `PDFJS` object
-
Move the
maxImageSizeoption from the globalPDFJSobject and int……o `getDocument` instead
-
Move the
cMapUrlandcMapPackedoptions from the globalPDFJSo……bject and into `getDocument` instead
-
Move the
isEvalSupportedoption from the globalPDFJSobject and ……into `getDocument` instead
-
Move the
disableFontFaceoption from the globalPDFJSobject and ……into `getDocument` instead
-
Move the
disableAutoFetchoption from the globalPDFJSobject and…… into `getDocument` instead One additional complication with removing this option from the global `PDFJS` object, is that the viewer currently needs to check `disableAutoFetch` in a couple of places. To address this I'm thus proposing adding a getter in `PDFDocumentProxy`, to allow checking the *actually* used values for a particular `getDocument` invocation.
-
Move the
disableRangeoption from the globalPDFJSobject and int……o `getDocument` instead
-
Move the
disableStreamoption from the globalPDFJSobject and in……to `getDocument` instead
-
Move the
disableCreateObjectURLoption from the globalPDFJSobje……ct and into `getDocument` instead
-
Move the
pdfBugoption from the globalPDFJSobject and into `get……Document` instead Also removes the now unused `getDefaultSetting` helper function.
-
Ensure that we only pass in the necessary parameters when initializin…
…g `PDFDataTransportStream`/`PDFNetworkStream` in `src/display/api.js` With options being moved from the global `PDFJS` object and into `getDocument`, a side-effect is that we're now passing in a fair number of useless parameters to the various transport/network streams. Even though this doesn't *currently* cause any problems, it nonetheless seem like a good idea to explicitly provide the parameters that are actually necessary.
-
