[WIP] Move options from the global PDFJS object into the relevant viewer components or API methods
#9130
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/a9aa25ada1a62fd/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/a9aa25ada1a62fd/output.txt Total script time: 2.51 mins Published |
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. Unfortunately, as far as I can tell, we still need the ability to adjust certain options depending on the browser environment. However, we should be able to separate this from the general compatibility code in the `src/shared/compatibility.js` file.
…nkService` options instead
…assed to `PDFPageProxy.render`
…etDocument` option instead
…bject to a `getDocument` option instead
… `getDocument` option instead
… `getDocument` option instead
…a `getDocument` option instead One additional complication with removing this parameters 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, to the `PDFDocumentProxy`, which allow checking the *actually* used values for a particular `getDocument` invocation.
…etDocument` option instead Unfortunately, as far as I can tell, we still need the ability to adjust certain options depending on the browser environment. However, we should be able to separate this from the general compatibility code in the `src/shared/compatibility.js` file.
…getDocument` option instead Unfortunately, as far as I can tell, we still need the ability to adjust certain options depending on the browser environment. However, we should be able to separate this from the general compatibility code in the `src/shared/compatibility.js` file.
…ct to a `getDocument` option instead Unfortunately, as far as I can tell, we still need the ability to adjust certain options depending on the browser environment. However, we should be able to separate this from the general compatibility code in the `src/shared/compatibility.js` file.
…a `getDocument` option instead *Please note:* In order to simplify things, the undocumented `enableStats` option was removed and `pdfBug` is now used to enabled general debugging *and* page request/rendering stats. Considering that we, in the default viewer, were only using the stats when debugging was also enabled, this simplification (code wise) definitely seem worthwhile to me.
…g `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 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently blocked on PRs
#9037,#9095,#9125, #9126.Edit: I'm not sure if this is necessarily the best solution, but at this point the PR now moves all (non-worker related, since those may be tricker) options from
PDFJS.