Document-global text size

[danielweck]

Hello @JayPanoz what do you think about CSS text-size-adjust? https://developer.mozilla.org/en-US/docs/Web/CSS/text-size-adjust

I am asking following the discussion in this issue: https://github.com/readium/readium-js-viewer/issues/686

Thanks!

[JayPanoz]

Ah, tbh this is a strange beast, but we’re indeed using it in ReadiumCSS for iOS (see pagination module).

Since you’re managing the font-size setting in JS, you should be safe – it is worth noting that it would break the native zoom feature of the iOS’ UIWebView though (and maybe the WKWebView but I can’t confirm for this one).

[danielweck]

The problem is that in Readium1, changing font-size (and proportional line-height) at the DOM "leaf" level doesn't adequately scale the "gutters" in the sample EPUB provided by the issue reporter. So, could you please test the provided EPUB with Readium2 's font scaling method, to see if it works? Many thanks!

[JayPanoz]

Yeah sure, will do ASAP.

Quick notes:

• you might want to obfuscate/remove the public download link in the issue as the copyrights at the end of the book make it very clear you need the permission of the publisher to transmit it (maybe the OP asked and got the permission, I don’t know, but that’s not clear);
• the code snippets are using ul with a margin set in px (lines are numbered with pseudo-element :before) so a lot of software truncates that (it just did in the app I’ve used to check the markup, @ 190%), as in the case for list item bullets if you don’t have enough room at larger font-sizes;
• in ReadiumCSS, we have padding-left and -right at the body level + extra margin if the max-width is reached so it might simply not be truncated because we have this extra room; my best option is running a custom test there, to isolate -webkit-text-size-adjust.

I’ll take a closer look and come back to you but from the “source code”, to be completely frank, the markup+styling is asking for this type of problems.

[danielweck]

Thanks!

[JayPanoz]

So the good news is that the number isn’t truncated in my tests.

The bad news is that it’s even worse:

Which can be explained by the following

As you can see, they’re using a different unit (em instead of rem) for list items with double digits.

What this means is that em is computed against their body’s font-size, which is 0.7em or 11.2px while rem is computed against 100% or 16px.

In our normalize, we currently map everything to 1rem (16px) as we have samples whose font-sizes are set in pt or px for body and it breaks the cascade for relative units.

The stylesheet has been designed for iBooks only – they’re now even applying an iTunes DRM so that you can’t use another app to read the guides they publish. Now, iBooks is using the font-size API (UIWebview on iOS, Webview on MacOS) so this problem doesn’t apply (it even takes care of margins in px if I’m not mistaken), but we don’t have that in web browsers and that’s why we’ve been using this normalize, and you’ve been using JS in R1…

I was failing to see how -webkit-text-size-adjust makes a difference there, as I didn’t notice any during my tests… until I found this link.

It indeed works…

Problem is there may be differences in behaviors as it is non-standard, and isn’t supported in some browsers (including Safari Desktop) so this won’t have any effect on desktop

Mind you, I’ll be happy to get rid of the normalize to prevent such edge cases, but it exists (and the JS solution too) because we don’t have anything cross-platform which does the job.

As for truncation, I guess it’s because, as any negative text-indent larger than the margin|padding-left, the risk is the first line overflowing on the left (+ rounding errors, especially as different units are used in this case).

Does this answer makes sense?

[JayPanoz]

Also, the ReadiumCSS gutter doesn’t increase with font-size neither, as this would make the container narrower in larger font sizes, and make the document unreadable.

[JayPanoz]

Out of curiosity, I took a quick look at -webkit-text-size-adjust (and text-size-adjust) on Chrome, with a non-basic support (as the MDN page is saying).

Here’s on desktop, with a value of 200% (no effect)

Here’s on mobile, same value (no effect)

So it probably supports only none or auto.

On a related note, if you have access to anything like “Changing the text size” as in the MacOS Webview for instance, it will probably be a lot easier to manage edge cases.

[JayPanoz]

After further testing, -webkit-text-size-adjust can only be used on iOS (can’t be used to increase/decrease font-size on MacOS, Windows, Linux or Android as % values are not supported, even by WebKit).

Here you can see a test document with a 200% value on an iPad, it works beautifully and reliably, for all units, even the absolute ones (pt, px, keywords). Increasing/decreasing font-size is as simple as changing this percentage.

Here you can (maybe) see it doesn’t work on Android – it’s hard to tell at first sight but I can confirm this is font-size @ 100%.

It’s worth noting -webkit-text-size-adjust appears to be developers’ preferred method when it comes to changing the font-size in an iOS WebView, probably because it’s simple and work reliably.

Android alternative could be native, i.e. setTextZoom() but I’m really not sure about that. People have been using getTextZoom though.

[JayPanoz]

And Electron: Could setZoomFactor/setZoomLevel be a more reliable alternative, @danielweck? See https://electronjs.org/docs/all#contentssetzoomfactorfactor

I can’t tell how the zoom is behaving (changing the font-size + reflowing or simply zooming).

[danielweck]

Yes, the Electron "web contents" API (also accessible via "web frame" proxy https://github.com/electron/electron/blob/master/docs/api/web-frame.md#methods ) provides methods to control zoom "level" ( https://github.com/electron/electron/blob/master/docs/api/web-contents.md#contentssetzoomlevellevel ) and "factor" ( https://github.com/electron/electron/blob/master/docs/api/web-contents.md#contentssetzoomfactorfactor ), which are two different ways (metric scales) to alter layout and visuals "zooming". This is potentially useful not only for publication documents, but also for the application UI itself (both of which are implemented with HTML/CSS)

For example, webPreferences.zoomFactor can be configured directly in the constructor of any BrowserWindow ( https://github.com/electron/electron/blob/master/docs/api/browser-window.md#new-browserwindowoptions ), which in the case of readium-desktop are the top-level window containers for the library view (bookshelf) and the reader view(s). This gives us an opportunity to easily implement a very useful feature for visually-impaired / low-vision / large-print users: "magnify" the entire application UI (own chrome as well as webview-rendered publication documents).

That being said, the original discussion topic here is specifically about "scaling" publication documents, including font size and other rendered objects (images, etc.). Personally I have not tried the Electron API yet, there might be undesirable side effects with CSS columns layout, scrollbar rendering, etc. (to be determined)