Split the existing PDFFunction in two classes, a private PDFFunction and a public PDFFunctionFactory, and utilize the latter in PDFDocument to allow various code to access the methods of PDFFunction`
#8968
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 test |
yurydelendik
approved these changes
Sep 29, 2017
src/core/obj.js
Outdated
| this.pdfManager = pdfManager; | ||
| this.xref = xref; | ||
| this.pdfFunctionFactory = pdfFunctionFactory; |
There was a problem hiding this comment.
I cannot spot why we need this property here.
There was a problem hiding this comment.
I cannot spot why we need this property here.
We don't, that's just a case of a bit too much copy-pasting. Removed now, thanks!
…n `PDFImage`, and change a couple of methods to use Objects rather than plain parameters The `inline` parameter is passed to a number of methods/functions in `PDFImage`, despite not actually being used. Its value is never checked, nor is it ever assigned to the current `PDFImage` instance (i.e. no `this.inline = inline` exists). Looking briefly at the history of this code, I was also unable to find a point in time where `inline` was being used. As far as I'm concerned, `inline` does nothing more than add clutter to already very unwieldy method/function signatures, hence why I'm proposing that we just remove it. To further simplify call-sites using `PDFImage`/`NativeImageDecoder`, a number of methods/functions are changed to take Objects rather than a bunch of (somewhat) randomly ordered parameters.
…on` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction` *Follow-up to PR 8909.* This requires us to pass around `pdfFunctionFactory` to quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can access `PDFFunction` as freely as in the old code. Please note that the patch passes all tests locally (unit, font, reference), and I *very* much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.
|
/botio test |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/3d1230141ee4408/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/02848a95278d088/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/02848a95278d088/output.txt Total script time: 16.58 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/3d1230141ee4408/output.txt Total script time: 22.38 mins
|
movsb
pushed a commit
to movsb/pdf.js
that referenced
this pull request
Jul 14, 2018
Split the existing `PDFFunction` in two classes, a private `PDFFunction` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction`
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.
Follow-up to PR #8909.
This requires us to pass around
pdfFunctionFactoryto quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can accessPDFFunctionas freely as in the old code.Please note that the patch passes all tests locally (unit, font, reference), and I very much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.