Open rahulk11 opened 3 years ago
Hello, can the problem be reproduced consistently in all R2 target platforms? (iOS, Android and desktop/Electron)
Hi @danielweck , yes, the issue is reproducible in iOS as well as thorium - r2 based desktop app.
This is in iOS
And this in thorium
This indeed is a side-effect of disabling publisherâs settings as we then apply a font-normalisation to handle font-size. That font-normalisation exists because we donât have a universal way/API to handle font-size in browsers, on all platforms, and a significant percentage of EPUB files would have otherwise broken the font-size setting due to the usage of absolute units. Itâs the best we can do in CSS due to the lack of such standard feature.
This should serve as a use-case for #34 though, because weâve been willing to strongly emphasise that if a native font-size API/method is available on a particular platform, it should be used in lieu of Readium CSSâ font-normalisation.
@JayPanoz Hi, There are issues also with the publisher's default ON. Check above screenshots . The texts are overlapping.
Thanks for your patience.
Iâll have to coordinate with @danielweck and @mickael-menu on this one, as Iâm not sure what is exactly going on in the apps.
So as a recap, these headings are p
with classes
, which is the reason the impact with publisherâs default off is so huge â should these be h1
, h2
, etc. it would already solve some rendering issues with advanced settings. Thatâs also why the chapter heading â which is using a table
with a negative bottom margin for layout purposes â ends up being cut off with publisherâs default off.
Anyways.
Thorium:
I am able to consistently reproduce these rendering issues with the test app as well when enabling settings, but they disappear w/o any issue when re-enabling publisherâs default. I can also tell they happen because readium-advanced-on
is set on the root
element (+ text-align
).
What I donât understand is why it stays there after a single setting change, @danielweck? Or does its removal not trigger a relayout?
Android + iOS:
So this overlapping text with publisherâs default on left me dumbfounded to be honest. Technically, ReadiumCSS does set a line-height
on html
just in case, knowing the vast majority of authorsâ stylesheets will override that value further down the DOM (body
, h1
, p
, etc.). This is not the case with this EPUB.
It should also be large enough that this overlapping doesnât happen, and I canât really understand the discrepancy between Android and iOS so Iâll need @mickael-menuâs help on this one.
Android: it clearly overlaps.
iOS: itâs close, mind you, but it doesnât.
There difference might be explained by the computed value of line-height
for html
and/or if it is inherited by this p
? At first I thought that maybe it could be a bug in Chrome re. font metrics but having tested the iOS test app Iâm not so sure now.
In passing, such âfreeformâ heading should really really set a line-height
, because there is no guarantee the default will be the same in all apps â in some, users can even change this default.
I am having issue with readium css in r2 test app for some epubs. The text is overlapping in some cases and in some cases text on top is getting cropped. I have included the screenshots for all the cases and also from readium1 test app(SDKLauncher-Android) It mostly works fine in readium1.
Case: publisher's default turned off
1.
2.
3.
Case: publisher's default turned on
1.
2.
3.
Case: Readium1 Test App
1.
2.
3.