CSS solution for words cut-off in kepub full screen reading

[scoky]

Originally Posted by GeoffR

It would be good to have a solution that can be automatically applied to sideloaded kepubs. If sideloaded kepubs work better than kobo-bought kepubs then that might give Kobo some extra incentive to fix the bug.

(BTW this does only happen with kepubs in the experimental full-screen mode right? I've never seen it happen with epubs or with kepubs in normal mode.)

yes, words cut-off issue only happens in kepubs when "FullScreenReading=true" is added to FeatureSettings which is a experimental full-screen mode.

[arspr]

Thanks Anak for your detailed explanation. I've just learned the "technical" name (negative side bearing) for my "ordinary" protrusion name...

[arspr]

Originally Posted by scoky

yes, words cut-off issue only happens in kepubs when "FullScreenReading=true" is added to FeatureSettings which is a experimental full-screen mode.

But cut-off letters always happens in kepubs unless there's a small margin/padding to give room to those characters with negative side bearings.

EDITED
I was fully wrong. Fullscreen mode DOES affect the text trimming issue. See this post.

[GeoffR]

Originally Posted by arspr

But cut-off letters always happens in kepubs unless there's a small margin/padding to give room to those characters with negative side bearings.

But only in full-screen mode, right? I've never seen it happen in normal reading mode.

[GeoffR]

Originally Posted by Anak

You can also add the soft margin to the - not used - wrapper "book-columns" to avoid touching the existing Kobo Style Hacks Code. Then it would look something like this:

<style type="text/css">
@page { margin-bottom: 5.000000pt; margin-top: 5.000000pt; }
</style>
<style type="text/css">
div#book-columns div { padding-left:2%;padding-right:2%; }
div#book-inner p, div#book-inner div { font-size: 1.0em; } a { color: black; } a:link, a:visited, a:hover, a:active { color: blue; } div#book-inner * { margin-top: 0 !important; margin-bottom: 0 !important;}
</style>

Is this method fool prove: yes, it will work. Is it perfect for original kepubs: no, because it adds an additional margin (padding:2%) on top of possible predefined left and right (page) margins in the CSS. Therefore you might end up with huge left and right page margins.

Thanks! I've used this to make a patch that should work with synced kepubs. See this thread for testing with firmware 3.12.0:

Will this work with sideloaded kepubs created by Calibre? I guess it doesn't work if the kepub is just a renamed epub.

[arspr]

Originally Posted by GeoffR

But only in full-screen mode, right? I've never seen it happen in normal reading mode.

Nope, you haven't looked carefully enough . It always happens in kepubs.
Edited: I was fully wrong.

You can explicitly test with my final version of Jellby's test book which you can grab in this thread. Just kepubize it however you prefer and enjoy.

One of the final tested is just a repeated italic "jf" text.

[PeterT]

Saying it only happens in kEpubs is rather misleading. Does this happen in OFFICIAL kEpubs as well as user created ones?

Sent from my Nexus 7 using Forum Fiend v1.2.14.

[GeoffR]

Originally Posted by PeterT

Saying it only happens in kEpubs is rather misleading. Does this happen in OFFICIAL kEpubs as well as user created ones?

In summary, as I see it: there are two seperate problems discussed in this thread:

1. Text gets cut off at the right, as if the whole screen has been shifted right. Only happens with kepubs in full-screen mode that have a non-zero body margin.

2. Certain characters (such as j,f) get cut off (left or right). Can happen with kepubs in either mode.

Problem 1 is solved by setting the body margin to zero. As far as I have seen official kepubs have a zero body margin already, but Calibre-created ones might not.

Problem 2 is solved by adding padding to a wrapper div. Official kepubs come with the necessary wrapper, but it lacks padding. Calibre-created kepubs are missing the wrapper altogether. (There is now a firmware patch to add padding to the wrapper, but it only works with official kepubs because Calibre-created ones lack the wrapper.)

[arspr]

Originally Posted by PeterT

Saying it only happens in kEpubs is rather misleading. Does this happen in OFFICIAL kEpubs as well as user created ones?

Yes it does, I'm just looking at a cut-off "f" in the right margin in an official DRMed kepub: "Final Empire" by Brandon Sanderson.

Originally Posted by GeoffR

In summary, as I see it: there are two seperate problems discussed in this thread:

1. Text gets cut off at the right, as if the whole screen has been shifted right. Only happens with kepubs in full-screen mode that have a non-zero body margin.

Ok, but we don't know the trigger... (read ahead).

Originally Posted by GeoffR

2. Certain characters (such as j,f) get cut off (left or right). Can happen with kepubs in either mode.

Exactly, but I would have said "happens" rather than "can happen".

Originally Posted by GeoffR

Problem 1 is solved by setting the body margin to zero. As far as I have seen official kepubs have a zero body margin already, but Calibre-created ones might not.

More testing is needed. I mean, scoky has tested that that margin: 0 setting fixes the issue. But we still don't know WHY/WHEN/HOW it happens. I mean that, as I said in the fourth post, I have TONS of book without any kind of margin setting and the bug doesn't appear in them.

Originally Posted by GeoffR

Problem 2 is solved by adding padding to a wrapper div. Official kepubs come with the necessary wrapper, but it lacks padding. Calibre-created kepubs are missing the wrapper altogether. (There is now a firmware patch to add padding to the wrapper, but it only works with official kepubs because Calibre-created ones lack the wrapper.)

Not exactly.

The problem is solved adding any kind of "room" to the text in order to contain those negative side bearing characters. It doesn't matter if you use either padding or margin, or if you directly apply them to body, div or even p.

(But curiously, if you add margin through the device GUI, the problem is NOT solved. WTH!?!?).

[GeoffR]

Originally Posted by arspr

The problem is solved adding any kind of "room" to the text in order to contain those negative side bearing characters. It doesn't matter if you use either padding or margin, or if you directly apply them to body, div or even p.

It doesn't work to apply to body, it has to be a lower level element. The point is that Calibre-created kepubs don't contain any lower level element that wraps the whole book, so there is no way to fix the problem from from the device's built-in stylesheet, whereas official kepubs do have such a wrapper div.

Edit: On second thought, perhaps adding something something like body div, body p {padding: 0 1%} would work ...

(But curiously, if you add margin through the device GUI, the problem is NOT solved. WTH!?!?).

That is because for kepubs in normal reading mode, the slider margin is added as a body margin which doesn't fix the problem, and in full-screen mode I think it is done by changing the viewport size rather than through CSS.

[arspr]

Originally Posted by GeoffR

It doesn't work to apply to body, it has to be a lower level element. The point is that Calibre-created kepubs don't contain any lower level element that wraps the whole book, so there is no way to fix the problem from from the device's built-in stylesheet, whereas official kepubs do have such a wrapper div.

Edit: On second thought, perhaps adding something something like body div, body p {padding: 0 1%} would work ...



That is because for kepubs in normal reading mode, the slider margin is added as a body margin which doesn't fix the problem, and in full-screen mode I think it is done by changing the viewport size rather than through CSS.

Nope, if you apply apply margin to body inside the epub/kepub then trimming letters issue is gone. No need to apply it to an inner div or p. I've just re-tested.

(But when using a 0 margin in GUI, although the device actually has a minimum available margin. I mean that RMSDK (epubs) does actually have a 0 margin so, of course, you get trimmed characters because they are partially outside the screen. But ACCESS (kepubs) always has a small margin even at the minimum value in GUI. But even with this available space, you get trimmed fonts when the slider is at it's minimum value).

But if you use padding in-book instead of margin, then even with a 0 margin slider in GUI the problem is gone.

So as Anak said, padding ("internal" margin) is therefore more effective than margin ("external" one) in order to "fix" the trimming font issue.


EDITED

And solved the trigger of the word trimming issue (the start of the thread).

The problem arises when you have body with a margin different than 0. (Remember that if it is not set it defaults to 0).

As example: In the Moby Dick book posted in the third message each html file has three linked stylesheets (1.css, 0.css and psepub.css). And body has margin set in 0.css (margin: 5%) and in psepub.css (margin: 0.5em). (In case you want to know the highest priority one is the psepub.css one)

So when you are doing the last conversion, it seems you are ADDING an even higher priority style which overrides the former ones.

The result: your final book has a body with margin 0 and then it works.

And as I hate margins, I always kill that setting in my books. Because of that I always have an effective 0 margin (the default value if not set) and because of that I haven't suffered it as I said in the second post. Probably the time I suffered it was because I just uploaded the book before doing my "compulsory" editing...

[GeoffR]

Originally Posted by arspr

Nope, if you apply apply margin to body inside the epub/kepub then trimming letters issue is gone. No need to apply it to an inner div or p. I've just re-tested.

Well I have tested it and it doesn't work. Adding padding or margin to body results in the problem that the OP describes.

(But when using a 0 margin in GUI, although the device actually has a minimum available margin. I mean that RMSDK (epubs) does actually have a 0 margin so, of course, you get trimmed characters because they are partially outside the screen. But ACCESS (kepubs) always has a small margin even at the minimum value in GUI. But even with this available space, you get trimmed fonts when the slider is at it's minimum value).

This is exactly the opposite of what I have found. The font cut-off doesn't happen at all in the epub reader, even with a zero margin. The kepub reader has a zero CSS body margin at the smallest slider setting, but has an extra margin created by resizing the viewport or some other means.

But if you use padding in-book instead of margin, then even with a 0 margin slider in GUI the problem is gone.

No, adding padding to body results in the same problem described in the OP. I have just tested it.

I've posted a new patch for firmware 3.12.0 that adds padding to the div and p elements immediately below body, this should work for sideloaded kepubs.

[arspr]

Originally Posted by GeoffR

Well I have tested it and it doesn't work. Adding padding or margin to body results in the problem that the OP describes.



This is exactly the opposite of what I have found. The font cut-off doesn't happen at all in the epub reader, even with a zero margin. The kepub reader has a zero CSS body margin at the smallest slider setting, but has an extra margin created by resizing the viewport or some other means.



No, adding padding to body results in the same problem described in the OP. I have just tested it.

I've posted a new patch for firmware 3.12.0 that adds padding to the div and p elements immediately below body, this should work for sideloaded kepubs.

Either you, or much more possible I, are doing something wrong...

I'll post a simple test book because there cannot be such discrepancies in such simple tests... But not today, I'm going to bed.

[GeoffR]

Originally Posted by arspr

Either you, or much more possible I, are doing something wrong...

I'll post a simple test book because there cannot be such discrepancies in such simple tests... But not today, I'm going to bed.

The difference with the kepubs results could be that I am adding margin/padding to the device's built-in stylesheet, rather than to the book's stylesheet, and testing with synced kepubs.

[arspr]

Originally Posted by GeoffR

The difference with the kepubs results could be that I am adding margin/padding to the device's built-in stylesheet, rather than to the book's stylesheet, and testing with synced kepubs.

Unless you are speaking about another thing, I still cannot replicate your behaviour. I've redone the tests using kobo-book.css instead of the book internal css tables and everything continues as I posted before.

Look at the first attached picture. That book (it's Jellby's updated test book from here) has body {margin: 0; padding: 0} but I've set body {margin: 1em} through kobo-book.css. And you can see how the trimming issue is gone.

(Although, as I said, it reappears if I set the device margin setting at 0. In that picture it is actually set at 1, I mean, at the next possible minimum value in the GUI slider).

Originally Posted by GeoffR

The font cut-off doesn't happen at all in the epub reader, even with a zero margin.

Look at the second picture. As I said, within epubs you can get trimmed characters because RMSDK does support a true 0 value in the margin. So yes, part of your characters are in fact outside of the screen... and therefore they are "trimmed".



OTOH and somehow offtopic...

I don't like how kepub-book.css is working...

I mean the exact kepub-book.css code I've used is:

body {
margin: 1em;
}

But the book has an explicitly style set inside:

body {
  margin: 0;
  padding: 0;
}

So the kepub-ebook.css one shouldn't have been applied!!! I should have need !important in the kepub-book.css code. Why is an external CSS setting overriding an internal CSS one?