-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[api-minor] Implement basic support for OptionalContent Usage
dicts (issue 5764, bug 1826783)
#17726
[api-minor] Implement basic support for OptionalContent Usage
dicts (issue 5764, bug 1826783)
#17726
Conversation
ade300e
to
b650d27
Compare
002ea3f
to
06d269b
Compare
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/2bdfe9b8fd5c021/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/2bdfe9b8fd5c021/output.txt Total script time: 1.39 mins Published |
088940c
to
f8ce385
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall it looks good to me. Thank you.
… (issue 5764, bug 1826783) The following are some highlights of this patch: - In the Worker we only extract a *subset* of the potential contents of the `Usage` dictionary, to avoid having to implement/test a bunch of code that'd be completely unused in the viewer. - In order to still allow the user to *manually* override the default visible layers in the viewer, the viewable/printable state is purposely *not* enforced during initialization in the `OptionalContentConfig` constructor. - Printing will now always use the *default* visible layers, rather than using the same state as the viewer (as was the case previously). This ensures that the printing-output will correctly take the `Usage` dictionary into account, and in practice toggling of visible layers rarely seem to be necessary except in the viewer itself (if at all).[1] --- [1] In the unlikely case that it'd ever be deemed necessary to support fine-grained control of optional content visibility during printing, some new (additional) UI would likely be needed to support that case.
… (PR 15377 follow-up) This helps ensure that /SetOCGState actions always take the `Usage` dictionary into account as expected.
f8ce385
to
70b6ddc
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/e7276edd9b5529b/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/f3c88d08f4d3284/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.241.84.105:8877/e7276edd9b5529b/output.txt Total script time: 25.32 mins
Image differences available at: http://54.241.84.105:8877/e7276edd9b5529b/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/f3c88d08f4d3284/output.txt Total script time: 42.81 mins
Image differences available at: http://54.193.163.58:8877/f3c88d08f4d3284/reftest-analyzer.html#web=eq.log |
/botio makeref |
From: Bot.io (Windows)ReceivedCommand cmd_makeref from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/9bbc1f8022c4ae0/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/1df8ac9ab5ddf69/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/1df8ac9ab5ddf69/output.txt Total script time: 18.84 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/9bbc1f8022c4ae0/output.txt Total script time: 27.29 mins
|
The following are some highlights of this patch:
In the Worker we only extract a subset of the potential contents of the
Usage
dictionary, to avoid having to implement/test a bunch of code that'd be completely unused in the viewer.In order to still allow the user to manually override the default visible layers in the viewer, the viewable/printable state is purposely not enforced during initialization in the
OptionalContentConfig
constructor.Printing will now always use the default visible layers, rather than using the same state as the viewer (as was the case previously).
This ensures that the printing-output will correctly take the
Usage
dictionary into account, and in practice toggling of visible layers rarely seem to be necessary except in the viewer itself (if at all).[1][1] In the unlikely case that it'd ever be deemed necessary to support fine-grained control of optional content visibility during printing, some new (additional) UI would likely be needed to support that case.