SDKLauncher-iOS icon indicating copy to clipboard operation
SDKLauncher-iOS copied to clipboard

Pan-Zoom control via touch gestures, disable reader.html meta viewport rescale

Open danielweck opened this issue 9 years ago • 3 comments

readium-js-viewer has additional control for pan-zoom (combo box / pull-down list of zoom-fit options + arbitrary percentage value). This should be achievable in native launchers via touch gestures (pinch / stretch).

danielweck avatar Oct 01 '14 15:10 danielweck

Reflowble viewport is impacted as well: https://github.com/readium/readium-sdk/issues/84

danielweck avatar Oct 23 '14 16:10 danielweck

Duplicate: https://github.com/readium/SDKLauncher-iOS/issues/24

Video: https://www.dropbox.com/s/uv78dnf56jm8ftm/landscape_zoom_problem.mov

danielweck avatar Oct 23 '14 16:10 danielweck

So, let's do a thought exercise, running iOS Launcher on an iPad.

The root UIWebView document reader.html doesn't do much more than wrapping the iframes for each displayed EPUB content document (i.e. there is no UI "chrome", unlike the cloud reader navigation bar + page buttons), and right now its head>meta/viewport allows the user to use pinch/stretch gestures, with undesirable results: it may "look and feel okay" with fixed layout books (including panning the content with one-two finger drag), but with reflow documents it becomes very confusing.

One option is to "lock" the reader.html viewport:

<meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1,minimum-scale=1,maximum-scale=1">

This would mean that the touch interaction would not get consumed "natively" by the UIWebView to zoom in/out of the rendered pages, instead code in readium-shared-js would take care of capturing pinch/stretch gestures (maybe double-tap as well) to interpret them as appropriate. This would make it possible to use Readium's built-in "pan + zoom" feature API (just as with the Chrome extension / cloud reader, although this browser-based implementation doesn't handle touch gestures at this point (for anything other than page swipe), but instead provides a menu UI affordance for setting the zoom).

The problem with the above approach is that touch events would not be handled natively, the app would delegate this to the HTML viewport. Not to everybody's taste / vendor integration requirements.

As a point of discussion, it may be important to remember that the cloud reader's "zoom" UI may eventually be used to control reflow font size as well as pixel-perfect zoom, thereby harmonising the concept of "magnification" across pre-paginated fixed layout publications and reflowable documents. Should the iOS touch-based interaction also be used to control font size? (in addition to classic pinch-stretch zoom gestures) This would be a good argument for locking the viewport and installing a custom touch handler, as described above.

Food for thoughts.

danielweck avatar Oct 23 '14 22:10 danielweck