View Single Post
Old 12-16-2014, 04:25 PM   #26
arspr
Dead account. Bye
arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.arspr ought to be getting tired of karma fortunes by now.
 
Posts: 587
Karma: 668244
Join Date: Mar 2011
Device: none
Quote:
Originally Posted by GeoffR View Post
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...

Last edited by arspr; 12-16-2014 at 05:07 PM. Reason: Solved the trigger of WORD trimming.
arspr is offline   Reply With Quote