MobileRead Forums - View Single Post

arspr · 11-15-2014, 02:34 AM

After playing with Jellby's test book in epub an kepub flavour:

I re-re-confirm everything I had previously told.

More differences / issues:

ACCESS always has a slight margin. Even at 0 in book and GUI your text does not reach the left-right margin of the screen. RMSDK is much more aggressive. (In fact I feel ACCESS is better, althugh it suffers the trimming letters issue which is not good...)
As already said if you force justification through GUI, ACCESS overrides any kind of setting in the kepub.
In RMSDK that forced justification seems to be set as a BASE setting on <p> (and maybe <div> sections?).
So any paragraph which has an in-book setting through classes applied to <p> is not going to be affected. So if your book paragraph is explicitly set to text-align: left; it is never going to be justified.
OTOH if your justification is set in the book through <body> and then inherited over <p>s, it seems to be overriden (because as I said it seems that RMSDK just adds a p{text-align: GUI-setting;} style). As example the NoMargins.xhtml is modified through GUI settings but the paragraphs in Justification.xhtml aren't (but the intro paragraphs in that Justification.xhtml file are).
I think this behaviour is much better than ACCESS one.
ACCESS has as a side effect that hyphenation is enabled when justified through GUI... RMSDK has the opposite behaviour. Its default hyphenation is disabled when left justification is forced (yes I'm getting some hyphens in that test book).
As expected RMSDK is not epub3/CSS3 capable in any way.
cm absolute measure unit is FUBAR in both systems (at least in my H2O) but is much more FUBAR in ACCESS (5 cm rendered as 1.8 cm) than in RMSDK (5 cm rendered as 4.4 cm).
OTOH full height is pretty strange in RMSDK because it draws a full screen rectangle BUT it's splitted. In the first page you get "one line" even when you have a lot of available free space, and in the second you get the rest. In ACCESS it seems to be ignored.
RMSDK ignores "oeb-page-xxx".
SVG support is somehow incomplete in both. (The rotated text is not displayed in both renderers and there are always some paging issues).
Links through images do not work in ACCESS (wild guess: because of the built in image viewer?)
I think that Lobster slanted font is not correctly rendered in RMSDK. In ACCESS all three Lobsters look the same, in RMSDK only first and third ones.
RMSDK supports ligatures, ACCESS doesn't (if the used font supports them, obviously).
RMSDK supports right to left texts, but they are left aligned... ACCESS seems to work fine. (Nevertheless there are missing unicode chars...)
I really don't care about named entities... I agree with Kovid Goyal, unicode chars should be used instead... It's just safer.
Nevertheless ACCESS does not allow to re-define standard entities like &mdash or &hellip. It also fails in &ap but not in the rest (wild guess: because it's a two letter entity ?????).

11-15-2014, 02:34 AM	#41
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	After playing with Jellby's test book in epub an kepub flavour: I re-re-confirm everything I had previously told. More differences / issues: ACCESS always has a slight margin. Even at 0 in book and GUI your text does not reach the left-right margin of the screen. RMSDK is much more aggressive. (In fact I feel ACCESS is better, althugh it suffers the trimming letters issue which is not good...) As already said if you force justification through GUI, ACCESS overrides any kind of setting in the kepub. In RMSDK that forced justification seems to be set as a BASE setting on <p> (and maybe <div> sections?). So any paragraph which has an in-book setting through classes applied to <p> is not going to be affected. So if your book paragraph is explicitly set to text-align: left; it is never going to be justified. OTOH if your justification is set in the book through <body> and then inherited over <p>s, it seems to be overriden (because as I said it seems that RMSDK just adds a p{text-align: GUI-setting;} style). As example the NoMargins.xhtml is modified through GUI settings but the paragraphs in Justification.xhtml aren't (but the intro paragraphs in that Justification.xhtml file are). I think this behaviour is much better than ACCESS one. ACCESS has as a side effect that hyphenation is enabled when justified through GUI... RMSDK has the opposite behaviour. Its default hyphenation is disabled when left justification is forced (yes I'm getting some hyphens in that test book). As expected RMSDK is not epub3/CSS3 capable in any way. cm absolute measure unit is FUBAR in both systems (at least in my H2O) but is much more FUBAR in ACCESS (5 cm rendered as 1.8 cm) than in RMSDK (5 cm rendered as 4.4 cm). OTOH full height is pretty strange in RMSDK because it draws a full screen rectangle BUT it's splitted. In the first page you get "one line" even when you have a lot of available free space, and in the second you get the rest. In ACCESS it seems to be ignored. RMSDK ignores "oeb-page-xxx". SVG support is somehow incomplete in both. (The rotated text is not displayed in both renderers and there are always some paging issues). Links through images do not work in ACCESS (wild guess: because of the built in image viewer?) I think that Lobster slanted font is not correctly rendered in RMSDK. In ACCESS all three Lobsters look the same, in RMSDK only first and third ones. RMSDK supports ligatures, ACCESS doesn't (if the used font supports them, obviously). RMSDK supports right to left texts, but they are left aligned... ACCESS seems to work fine. (Nevertheless there are missing unicode chars...) I really don't care about named entities... I agree with Kovid Goyal, unicode chars should be used instead... It's just safer. Nevertheless ACCESS does not allow to re-define standard entities like &mdash or &hellip. It also fails in &ap but not in the rest (wild guess: because it's a two letter entity ?????). Last edited by arspr; 11-15-2014 at 03:32 AM.