Inline PDFImage.createRawMask in the PDFImage.createMask method
#19773
Conversation
This file contains hidden or 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
Snuffleupagus
force-pushed
the
inline-PDFImage-createRawMask
branch
2 times, most recently
from
da0b60b to
1cbd437
Compare
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/a967a6ca20c6764/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/4337beea6a84a2e/output.txt |
Snuffleupagus
force-pushed
the
inline-PDFImage-createRawMask
branch
from
1cbd437 to
0eac943
Compare
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/a967a6ca20c6764/output.txt Total script time: 29.52 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/4337beea6a84a2e/output.txt Total script time: 63.81 mins
|
After the introduction of `OffscreenCanvas` support we now have *two separate* mask-methods in the `PDFImage` class, and the reason that they were not combined is likely that we need the "raw" bytes when parsing Type3-glyph image masks. However, that case is easy to support simply by disabling `OffscreenCanvas` usage when parsing Type3-glyphs and that way we're able to reduce some code duplication. Another slightly strange property of the `PDFImage.createMask` method is that it needs various image-dictionary parameters *manually* provided, which is probably because this is very old code. That feels slightly unwieldy, and we instead change the method to pass in the image-stream directly and do the necessary data-lookup internally. A side-effect of this re-factoring is that we now support using the custom `isSingleOpaquePixel` operator in Type3-glyphs, which shouldn't hurt even though it seems extremely unlikely for that to ever happen in Type3-glyphs.
Snuffleupagus
force-pushed
the
inline-PDFImage-createRawMask
branch
from
0eac943 to
dc3e24a
Compare
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.
After the introduction of
OffscreenCanvassupport we now have two separate mask-methods in thePDFImageclass, and the reason that they were not combined is likely that we need the "raw" bytes when parsing Type3-glyph image masks.However, that case is easy to support simply by disabling
OffscreenCanvasusage when parsing Type3-glyphs and that way we're able to reduce some code duplication.Another slightly strange property of the
PDFImage.createMaskmethod is that it needs various image-dictionary parameters manually provided, which is probably because this is very old code.That feels slightly unwieldy, and we instead change the method to pass in the image-stream directly and do the necessary data-lookup internally.
A side-effect of this re-factoring is that we now support using the custom
isSingleOpaquePixeloperator in Type3-glyphs, which shouldn't hurt even though it seems extremely unlikely for that to ever happen in Type3-glyphs.