[api-minor] Add support for ViewerPreferences in the API (issue 10736) #10738
Conversation
Snuffleupagus
force-pushed
the
ViewerPreferences-api
branch
4 times, most recently
from
97bfa8e to
881c57d
Compare
|
/botio unittest |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/84e3dd489f771b4/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/62971f34153fac0/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/84e3dd489f771b4/output.txt Total script time: 2.71 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/62971f34153fac0/output.txt Total script time: 5.63 mins
|
Please see the specification, https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#M11.9.12864.1Heading.71.Viewer.Preferences Furthermore, note that this patch *only* adds API support and unit-tests but does not attempt to integrate e.g. the `ViewerPreferences -> Direction` property into the viewer (which would be necessary to address issue 10736). The reason for this is that it's not entirely clear to me exactly if/how that could be implemented; e.g. would it be as simple as setting the `dir` attribute on the `viewerContainer` DOM element, or will it be more complicated? There's also the question of how the `ViewerPreferences -> Direction` value interacts with the `PageMode`, and this will generally require a fair bit of manual testing. Since the direction of the *entire* viewer depends on the browser locale, there's also a somewhat open question regarding what default value to use for different locales. Finally, if the viewer supports `ViewerPreferences -> Direction` then I'm assuming that it will be necessary to allow users to override the default value, which will require (most likely) new `SecondaryToolbar` buttons and icons for those etc. Hence this patch only lays the necessary foundation for eventually addressing issue 10736, but defers the actual implementation until later. (Time permitting, I'll try to look into the viewer part later.)
Snuffleupagus
force-pushed
the
ViewerPreferences-api
branch
from
881c57d to
311bac3
Compare
|
/botio unittest |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/620644651c1a7d4/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @timvandermeij received. Current queue size: 0 Live output at: http://54.215.176.217:8877/267499b605192a3/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/620644651c1a7d4/output.txt Total script time: 2.69 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/267499b605192a3/output.txt Total script time: 5.64 mins
|
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/79850f76f4614b9/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/79850f76f4614b9/output.txt Total script time: 1.92 mins Published |
|
Thank you for improving the API! |
Please see the specification, https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#M11.9.12864.1Heading.71.Viewer.Preferences
Furthermore, note that this patch only adds API support and unit-tests but does not attempt to integrate e.g. the
ViewerPreferences -> Directionproperty into the viewer (which would be necessary to address issue #10736).The reason for this is that it's not entirely clear to me exactly if/how that could be implemented; e.g. would it be as simple as setting the
dirattribute on theviewerContainerDOM element, or will it be more complicated?There's also the question of how the
ViewerPreferences -> Directionvalue interacts with thePageMode, and this will generally require a fair bit of manual testing. Since the direction of the entire viewer depends on the browser locale, there's also a somewhat open question regarding what default value to use for different locales.Finally, if the viewer supports
ViewerPreferences -> Directionthen I'm assuming that it will be necessary to allow users to override the default value, which will require (most likely) newSecondaryToolbarbuttons and icons for those etc.Hence this patch only lays the necessary foundation for eventually addressing issue #10736, but defers the actual implementation until later. (Time permitting, I'll try to look into the viewer part later.)