EPUB, KEBUP, ShmEPUB... confused. What's on my reader now?

[Katsunami]

Originally Posted by GeoffR

I set widows:1;orphans:1; in all my books (orphans:0;widow:0 works just as well) and have never had any problem like that.

Usually if a book appears as if it has no stylesheet at all, it means that there was a fatal error in the stylesheet. The ePub reader is very sensitive to errors and will just discard the whole stylesheet if it is not perfect, so it can be a good idea to run epubcheck after making any manual changes.

Yeah, davidfor said as much in the owner's thread. I hadn't thought about the possibility of having made a mistake. I'll try again.

If I can get EPUBs to work in full screen without leaving parts of the screen blank and NOT get KEPUBs to work, I wonder what I'm going to prefer; the full screen reading, or the chapter previews and time to read of the KEPUBs. I stopped caring about TTR on the Kindle, because it's unreliable; at some point, it *always* suddenly cuts TTR in half.

[GeoffR]

Alhough it is better to solve the problem with CSS, if the cut-off problem you are seeing is the one where only certain letters are cut off (ones with large side bearing values, such as J and f), a work-around is to use a font that doesn't have letters with large side bearing values. It just happens that the default font on Kobo (Georgia) has very large side bearing on some letters and so is especially badly affected by the problem.

(An example of a font without large side bearing values is Caudex. See the Google specimen.)

[Katsunami]

Originally Posted by GeoffR

Alhough it is better to solve the problem with CSS, if the cut-off problem you are seeing is the one where only certain letters are cut off (ones with large side bearing values, such as J and f), a work-around is to use a font that doesn't have letters with large side bearing values. It just happens that the default font on Kobo (Georgia) has very large side bearing on some letters and so is especially badly affected by the problem.

No, the entire right edge is cut off; about 25% of all letters is gone.

With regard to patching: it's a bit confusing.

The two patches I am interested in are the KEPUB full screen fix patch, and the Font Freedom patch, but I haven't been able to figure out yet where to get the correct version of the firmware and the patch. I understand how to install it, but I can't find the files and be sure they're the right versions.

If I would like to undo the patch (assuming the reader boots), would I be able to just flash the default firmware? If the reader does not boot, what would I do to get it working again?

[GeoffR]

Originally Posted by Katsunami

No, the entire right edge is cut off; about 25% of all letters is gone.

For KePubs in full-screen mode that problem is caused by the presence of margin or padding on the body element. (It can also be caused by the publisher doing something really stupid like using a negative right margin on paragraphs, that is rare but I've seen it in some Smashwords books.)

All the `Fix three KePub fullScreenReading bugs` patch does is set the margin and padding to zero in the device's built-in stylesheet when full-screen mode is used, so if the patch fixes that problem then you should be able to fix it without the patch by setting the margin and padding to zero in the book's stylesheet.

With regard to patching: it's a bit confusing.

The two patches I am interested in are the KEPUB full screen fix patch, and the Font Freedom patch, but I haven't been able to figure out yet where to get the correct version of the firmware and the patch. I understand how to install it, but I can't find the files and be sure they're the right versions.

If I would like to undo the patch (assuming the reader boots), would I be able to just flash the default firmware? If the reader does not boot, what would I do to get it working again?

Best to ask for help with this in the patching thread for your firmware version in the developer's forum. But I'd suggest not to rush into patching if you can solve the problem without it, because patches need to be re-done every time there is a firmware update, while if you can solve it by using Calibre to modify the book as it is sent to the device then you have a solution that will continue to work in the future without any extra effort.

[Katsunami]

Originally Posted by GeoffR

For KePubs in full-screen mode that problem is caused by the presence of margin or padding on the body element. (It can also be caused by the publisher doing something really stupid like using a negative right margin on paragraphs, that is rare but I've seen it in some Smashwords books.)

Weird. Then the earlier two lines should have worked, but they didn't. Maybe I'll have to first switch the reading mode and then open the book as you suggested.

Should it be:

body { margin: 0 !important; padding: 0 !important; }
div#book-columns { padding-left: 0 !important; padding-right: 0 !important; }

or

body { margin: 0 !important; padding: 0 !important; }
div#book-columns div { padding-left: 0 !important; padding-right: 0 !important; }

I've encountered both in the forum, and with different values of padding.

Best to ask for help with this in the patching thread for your firmware version in the developer's forum. But I'd suggest not to rush into patching if you can solve the problem without it, because patches need to be re-done every time there is a firmware update, while if you can solve it by using Calibre to modify the book as it is sent to the device then you have a solution that will continue to work in the future without any extra effort.

Yes. This is the main reason why I dislike patching.

[GeoffR]

Originally Posted by Katsunami

W
Should it be:

or

I've encountered both in the forum, and with different values of padding.

Neither! The second lines of both of those are wrong, it should add padding to the div not set it to zero. However the problem you have, with the whole page shifted to the right, is not affected by the second line, only the first line:

body { margin: 0 !important; padding: 0 !important; }
div#book-columns { padding-left: 0.2em !important; padding-right: 0.2em !important; }

(alternatively you could replace the div#book-columns selector on the second line with something like body>div or body>*, but div#book-columns div is wrong and will cause lots of problems for some books.)

To be sure that Calibre is adding the CSS correctly it is best to examine a book after it has been sent to the device. i.e. after sending it to the device, copy the kepub.epub file from the device back to the PC and unzip it to check that the stylesheet and html has been modified correctly.

[Katsunami]

Originally Posted by GeoffR

Neither! The second lines of both of those are wrong, it should add padding to the div not set it to zero. However the problem you have, with the whole page shifted to the right, is not affected by the second line, only the first line:

body { margin: 0 !important; padding: 0 !important; }
div#book-columns { padding-left: 0.2em !important; padding-right: 0.2em !important; }

Thanks.

What does the second line do exactly? In the thread I linked previously, it is mentioned that it adds 'soft margins', but I don't know about the rendering (and associated problems) on Kobo devices to guess what it means.

(alternatively you could replace the div#book-columns selector on the second line with something like body>div or body>*, but div#book-columns div is wrong and will cause lots of problems for some books.

The extra "div" in red comes from the earlier linked thread. I'll remove it.

To be sure that Calibre is adding the CSS correctly it is best to examine a book after it has been sent to the device. i.e. after sending it to the device, copy the kepub.epub file from the device back to the PC and unzip it to check that the stylesheet and html has been modified correctly.

It is adding the CSS. I've already checked. I'll try again this evening, switching the reading mode before opening a book.

This slider problem which you mentioned (and which I have already encountered):

There is also a KePub bug that started in the 3.19 firmware where the margin slider stops working, for which the work-around it to exit the book and open it again. None of these problems seem to affect ePubs though.

Is it a consequence of the added CSS, or is this a bug Kobo should fix in another firmware update?

[GeoffR]

Originally Posted by Katsunami

What does the second line do exactly? In the thread I linked previously, it is mentioned that it adds 'soft margins', but I don't know about the rendering (and associated problems) on Kobo devices to guess what it means.

The second line adds a small amount of padding (an amount proportional to the currently selected font size) to the wrapper div named "book-columns". If no such wrapper div exists then it does nothing. That little bit of padding gives enough room to allow glyphs with side bearing positioned at the edge of a line to be rendered without being clipped by the edge of the viewport.

The fact that the glyphs would be clipped in the first place is probably because of a bug in the KePub reader. (One that isn't present in the ePub reader, which uses a completely different rendering engine.)

The reason that the bug isn't usually noticed in KePubs in normal reading mode is that there the viewport is set to the full size of the screen and the user-selected margins are added by changing the body margin, so the bug is only seen when the margins are set to minimum. In full-screen mode the body margins are supposed to be zero and the margin slider changes the size of the viewport instead, so the bug is seen at all slider positions.

(That is just what I think based on looking at code in the firmware, I don't know all the details.)

This slider problem which you mentioned (and which I have already encountered):
Is it a consequence of the added CSS, or is this a bug Kobo should fix in another firmware update?

It is not affected by the CSS. It is a bug in the KePub reader (one that doesn't exist in the ePub reader), but since it is a bug that only arises in full-screen mode, and full-screen mode is not an officially-supported feature, it is unlikely to be a priority for being fixed. I wouldn't hold out any hope that it will be fixed in the future unless Kobo decide to make full-screen mode an official feature available by default, but it is always possible that it will be fixed by accident, i.e. some other change to the code results in the buggy code being removed.

In practice the problem with the margin slider stoppng working after a chapter boundry is crossed is not a major annoyance because once you set the margin slider for one book it becomes the default for the next book and you don't often need to change it again.

[Katsunami]

Originally Posted by GeoffR

The second line adds a small amount of padding (an amount proportional to the currently selected font size) to the wrapper div named "book-columns". If no such wrapper div exists then it does nothing. That little bit of padding gives enough room to allow glyphs with side bearing positioned at the edge of a line to be rendered without being clipped by the edge of the viewport.

...

The reason that the bug isn't usually noticed in KePubs in normal reading mode is that there the viewport is set to the full size of the screen and the user-selected margins are added by changing the body margin, so the bug is only seen when the margins are set to minimum. In full-screen mode the body margins are supposed to be zero and the margin slider changes the size of the viewport instead, so the bug is seen at all slider positions.

Thanks for the clear explanation.

(That is just what I think based on looking at code in the firmware, I don't know all the details.)

How can you see the firmware code? Is it uncompiled Java, or Python running on top of an interpreter or something; i.e., not natively compiled to a binary?

It is not affected by the CSS. It is a bug in the KePub reader (one that doesn't exist in the ePub reader), but since it is a bug that only arises in full-screen mode, and full-screen mode is not an officially-supported feature, it is unlikely to be a priority for being fixed. I wouldn't hold out any hope that it will be fixed in the future unless Kobo decide to make full-screen mode an official feature available by default, but it is always possible that it will be fixed by accident, i.e. some other change to the code results in the buggy code being removed.

In practice the problem with the margin slider stoppng working after a chapter boundry is crossed is not a major annoyance because once you set the margin slider for one book it becomes the default for the next book and you don't often need to change it again.

Indeed. After I decide what the margins should be (either the smallest, or next to smallest), I'll probably never touch the slider again.

[GeoffR]

Originally Posted by Katsunami

THow can you see the firmware code? Is it uncompiled Java, or Python running on top of an interpreter or something; i.e., not natively compiled to a binary?

It is mainly compiled C++, so you need to disassemble the executable code and read assembly language, but there is also a certain amount that can be learned from the CSS strings embedded in the executables.

[Katsunami]

In that case, it's a miracle you get your patches to work correctly. A lot of people have enough trouble getting normal C/C++ code they are writing themselves to run crash free, let alone having to inject new code into an existing binary

[jackie_w]

@Katsunami,

If I may I'd like to respond to this statement you reported in the 'Kobo Aura One owners thread'. It's probably more technically detailed than the general readers of that thread want to hear about with their new toys.

edit: an orphans/widows addition completely destroys the rendering of the EPUBs I've tested.

Would I be correct in thinking that you are using the 'Modify CSS' option in the KoboTouch/KoboTouchExtended drivers to add the following to the kobo_extra.css file?

body { widows: 0 !important; orphans: 0 !important; }

If so, your main problem probably isn't that you've used 0 rather than 1 (although 1 is more correct, I think), it's that you've included those !important. I haven't figured out why the combo of !important and enabling 'Modify CSS' is so destructive, but it is. I first noticed it a few years ago. Since then I haven't allowed !important to remain in any of my epub css files and I don't use it in kobo_extra.css either. I haven't had a problem with standard epubs since.

For your extra info, you may not be aware that widows, orphans and @page statements are treated as special cases by the calibre drivers if you include new statements for them in kobo_extra.css. All existing widows/orphans/@page CSS code in your epubs will be completely removed before appending your new values. So !important wouldn't achieve anything anyway.

ETA: In case I haven't been clear, all the above refers to dealing with standard epubs not kepubs.

[Katsunami]

Originally Posted by jackie_w

Would I be correct in thinking that you are using the 'Modify CSS' option in the KoboTouch/KoboTouchExtended drivers to add the following to the kobo_extra.css file?

Yes.

If so, your main problem probably isn't that you've used 0 rather than 1 (although 1 is more correct, I think), it's that you've included those !important. I haven't figured out why the combo of !important and enabling 'Modify CSS' is so destructive, but it is. I first noticed it a few years ago. Since then I haven't allowed !important to remain in any of my epub css files and I don't use it in kobo_extra.css either. I haven't had a problem with standard epubs since.

!important and kobo_extra.css have nothing to do with one another with regard to being destructive or not. "!important" *is* destructive.

!important means: "Use these values, whatever comes after." A cascading stylesheet overwrites values of properties, so if you set "X" to 15 on an element, and then you set it to 20 on the same element (further down in the same stylesheet, or in one linked after the one that has "X" at 15), then the value will be 20. If you set "X" to "15 !important" however, the value will not be overwritten. The "!important" value will be the one used, independently of where it appears in the stylesheet. (Maybe it can be overwritten by a later defined, new "!important" on the same element; I don't know that.)

For your extra info, you may not be aware that widows, orphans and @page statements are treated as special cases by the calibre drivers if you include new statements for them in kobo_extra.css. All existing widows/orphans/@page CSS code in your epubs will be completely removed before appending your new values. So !important wouldn't achieve anything anyway.

Oh, OK. If the driver removes all @pages and all existing widows/orphans properties everywhere, then indeed "!important" for that property wouldn't achieve anything.

[nabsltd]

Originally Posted by Katsunami

The "!important" value will be the one used, independently of where it appears in the stylesheet. (Maybe it can be overwritten by a later defined, new "!important" on the same element; I don't know that.)

You also have to take selector matching into account. !important on a general selector (like "div" or "p") won't be applied if there is a selector that matches better (like the div#book-columns in the thread). The reason that this works so well is that ID selectors are the most specific, as there can be only one element with that ID on the same HTML page.

So, in this case, it works, but in the general case, !important can be overridden, depending on where and how it is applied.

[Katsunami]

Thanks for the extra information Always something new to learn