Open danielweck opened 6 years ago
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).
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!
Yeah sure, will do ASAP.
Quick notes:
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;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.
Thanks!
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-size
s 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?
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.
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.
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.
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).
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)
Hello @JayPanoz what do you think about CSS
text-size-adjust
? https://developer.mozilla.org/en-US/docs/Web/CSS/text-size-adjustI am asking following the discussion in this issue: https://github.com/readium/readium-js-viewer/issues/686
Thanks!