Some serious issues with kepubs

[jgoguen]

Originally Posted by Sharkus

Lightfleight Content Protection

That sounds like a really fancy way of saying "Digital Restrictions Management"

I won't have time to give this draft spec a good read for a few more hours at least, in the meantime could anyone give a high-level overview of what this draft spec proposes that isn't covered (or improves upon) the current EPUB specification for DRM using META-INF/rights.xml?

[Sharkus]

Originally Posted by jgoguen

That sounds like a really fancy way of saying "Digital Restrictions Management"

Worth reading Jim's blog post on eBook DRM and unDRM here.

Originally Posted by jgoguen

I won't have time to give this draft spec a good read for a few more hours at least, in the meantime could anyone give a high-level overview of what this draft spec proposes that isn't covered (or improves upon) the current EPUB specification for DRM using META-INF/rights.xml?

I know a man who could I'll give him a prod.

[Sharkus]

Originally Posted by jgoguen

I won't have time to give this draft spec a good read for a few more hours at least, in the meantime could anyone give a high-level overview of what this draft spec proposes that isn't covered (or improves upon) the current EPUB specification for DRM using META-INF/rights.xml?

As if by magic, the Shopkeeper appeared.

Originally Posted by Jim Dovey

Simple answer: EPUB only specifies that a file called rights.xml might exist, and says nothing whatsoever about its contents[1].

rights.xml is an Adobe-specific thing, used by ACS/ADE, and it's in the standard because it's left over from the original definition of EPUB (well, OEBPS back then) that came out of Adobe. Its contents aren't standardized by anyone except Adobe, internally.

The draft spec covers a few things, and a quick overview can be found on the W3C site[2]. The basics are:

• Encryption via XML-ENC 1.1/2.0 for content protection/locking.
• Digital Signatures via XML-DSig 1.1/2.0 for content verification and potentially device/user verification.
• An XML schema describing chained authentication methods (use built in account info, if that fails prompt for email/password, etc.)
• An XML schema specifying individual rights in a granular and openly extensible manner, including support for both personal and institutional lending.

Howzat!

[1]: http://www.idpf.org/epub/30/spec/epu...inf-rights.xml
[2]: http://www.w3.org/2012/08/electronic..._submission_26

[taming]

Jim's article Introducing the Readium is also worth a look. http://blog.alanquatermain.me/2013/0...e-readium-sdk/ especially for folks who are wondering if Kobo has skin in the game for epub3 implementation.

[jgoguen]

As if I didn't have enough to read for tonight!

Thanks, you guys rock

[DNSB]

Originally Posted by jgoguen

As if I didn't have enough to read for tonight!

Thanks, you guys rock

In case you are interested....

[Sharkus]

Originally Posted by taming

Jim's article Introducing the Readium is also worth a look. http://blog.alanquatermain.me/2013/0...e-readium-sdk/ especially for folks who are wondering if Kobo has skin in the game for epub3 implementation.

Jim is involved to ensure we do have skin in the game. He's a great guy (I've known him quite a long time )

[93terp]

Originally Posted by pidgeon92

I have used it to send a handful of books to the Aura. It works just fine, there aren't any noticeable problems. However, I haven't loaded the corresponding epubs to look and see if there are format differences. I suppose I shall have to load them both and compare on a few titles.

This has been my experience too. I have exclusively side loaded books (~ 500) to my Aura using the KoboTouchExtended plugin so that I have kepub functionality. So far I'm loving it!

[jgoguen]

Awesome! Maybe there was just some initial pains with a new device. Wasn't any change I made though, there's been no release since the Aura came out, must be changes davidfor made

BTW, 93terp I love your "big books" image... I may have to go make a poster out of this now

[93terp]

Originally Posted by jgoguen

BTW, 93terp I love your "big books" image... I may have to go make a poster out of this now

Thanks, but I can't take credit for it! I found it online somewhere (maybe GoodReads??) and it fits me to a tee!!

[Barty]

Originally Posted by samhy

Everywhere on the forums, people seem to want options with their ereaders. And here, Kobo give you the choice between two renderers. You don't have to read epub ebooks if you don't want to. You don't have to read kepub ebooks if you don't want to.

I have no problem with choice. But, from the first post, kepub looks broken where ePub displays correctly. How is this good? Improper scene break is a pet peeve of mine.

Okay, you say, so use ePub then. But what if I like having the reading stats? In fact, it's the one kobo feature I wish my current reader had. I'd really like to know how long I've been reading a book, how many books I've read this past years, etc. OTOH, with kepub, I'm stuck with the title taking up space at the top. So neither choice is good to me.

[DNSB]

Originally Posted by Barty

I have no problem with choice. But, from the first post, kepub looks broken where ePub displays correctly. How is this good? Improper scene break is a pet peeve of mine.

The "scene break" will depend on how the ebook publisher (not Kobo in most cases) created that piece of code. I've seen multiple ways of doing a blank line and some of them do not work on different devices. Some of them work for Adobe's Reader Mobile (epub) but not for ACCESS Netfront (kepub). Some of the more popular ways of inserting a blank line I've seen follow:


<p class="foobar">&nbsp;</p> works quite well unless you are reading on an iDevice which seems to disbelieve in non-breaking spaces.

<p class="foobar" /> which works on the occasional reader. Most of the time it does not work but seems to be popular with many publishers.

<br /> is another that works once in a while. Not something I would depend on across multiple devices but

<p class="foobar"><br /></p> is another which works quite well in most cases. Sigil uses this when you insert a blank line.

Then there are the ebooks where the paragraph before the blank line uses a css style with a larger bottom margin or the paragraph after the blank line used a larger top margin.

If the ebook is not DRMed, I find myself breaking out Sigil and having fun hacking and slashing the styles, corrected the incorrect line breaks that amost every ebook seems to have, etc.

Regards,
David

[DNSB]

Originally Posted by Barty

Okay, you say, so use ePub then. But what if I like having the reading stats? In fact, it's the one kobo feature I wish my current reader had. I'd really like to know how long I've been reading a book, how many books I've read this past years, etc. OTOH, with kepub, I'm stuck with the title taking up space at the top. So neither choice is good to me.

As for the reading stats? You can get the number of books and hours read regardless of the type of book. The same reading stats screen will show the current book's progress and current chapter progress. It will not show you how to long it will take to finish the current chapter which in my opinion is a useless bit of information. Given that my current reading stats show 29 books with 41 hours read since April 27th, the displayed chapter remaining times on a kepub -- telling me it is going to take me 4 minutes to read the last 7 pages of a chapter, 14 minutes to read the next chapter and 14.5 hours finish reading the book are not even close to realistic numbers.

Regards,
David

[samhy]

Originally Posted by Barty

Okay, you say, so use ePub then. But what if I like having the reading stats? In fact, it's the one kobo feature I wish my current reader had. I'd really like to know how long I've been reading a book, how many books I've read this past years, etc. OTOH, with kepub, I'm stuck with the title taking up space at the top. So neither choice is good to me.

I agree with you as I wish the Kepub display to improve, no doubt here. My sort of rant was more to those who wish Kobo will ditch the kepub format altogether.

[Anak]

Originally Posted by Barty

I have no problem with choice. But, from the first post, kepub looks broken where ePub displays correctly. How is this good? Improper scene break is a pet peeve of mine.

Okay, you say, so use ePub then. But what if I like having the reading stats? In fact, it's the one kobo feature I wish my current reader had. I'd really like to know how long I've been reading a book, how many books I've read this past years, etc. OTOH, with kepub, I'm stuck with the title taking up space at the top. So neither choice is good to me.

Originally Posted by DNSB

The "scene break" will depend on how the ebook publisher (not Kobo in most cases) created that piece of code. I've seen multiple ways of doing a blank line and some of them do not work on different devices. Some of them work for Adobe's Reader Mobile (epub) but not for ACCESS Netfront (kepub). Some of the more popular ways of inserting a blank line I've seen follow:


<p class="foobar">&nbsp;</p> works quite well unless you are reading on an iDevice which seems to disbelieve in non-breaking spaces.

<p class="foobar" /> which works on the occasional reader. Most of the time it does not work but seems to be popular with many publishers.

<br /> is another that works once in a while. Not something I would depend on across multiple devices but

<p class="foobar"><br /></p> is another which works quite well in most cases. Sigil uses this when you insert a blank line.

Then there are the ebooks where the paragraph before the blank line uses a css style with a larger bottom margin or the paragraph after the blank line used a larger top margin.

If the ebook is not DRMed, I find myself breaking out Sigil and having fun hacking and slashing the styles, corrected the incorrect line breaks that amost every ebook seems to have, etc.

Regards,
David

I also have no problem with choice and I do not care which rendering engine is used except when it looks broken or it does not behave like expected. And that seems the case with the current kepub renderer on the e-ink devices.
I would not suprise me if this kepub is rendered correctly with the Kobo Android or iPhone apps. When I open this book with the Kobo Desktop it is rendered better. Centered text is actually centered. The bottom margin after every text line/paragraph is still there.

Regarding the "scene break" or a blank line added deliberately by the publisher in the original epub can be rendered differently depending on how it is coded. To some point I understand and except it.

Then there are the ebooks where the paragraph before the blank line uses a css style with a larger bottom margin or the paragraph after the blank line used a larger top margin.

This particular issue I have a problem with as it disrespects margins that are deliberately added to the text.

I've explored it a bit further.
FYI: the pictures in the first post are taken from an original kobo kepub and epub with drm. The kepub has the mentioned issues.

So I decided to
1. remove the drm of the epub and renamed this epub to .kepub.epub to force it to use the Kobo renderer (NetFront BookReader engine) instead of Adobes RMSDK. The result: the kepub is rendered exactly as the original epub. All centered text is displayed as such and the margin between each sentence is gone. The deliberate blank lines (like "scene breaks") are properly displayed.
2. but just renaming a epub to .kepub.epub may not unlock all special Kobo features (or make these work correctly) like annotations. But that is outside the scope of problems I mentioned in the first post.
But with just renaming the epub to kepub.epub I was able to change the font size, line spacing, margins (page margins left and right) and justification (default epub setting, left, justify). So the orginal epub was not "hard coded" that prevents to change any or some of these settings.

The overall conclusion is that not the NetFront BookReader engine causes the mentioned layout issues but the Kobo wrapper code.
The code below is from a different book as I can not download a preview of a book that I allready own.
The kobo.css is actually an empty css without any code. In some older book previews the kobo.css can contain code. That code is identical to inline css code added to every single xhtml file (<style type="text/css" id="kobostylehacks"> part) and making the kobo.css obsolete.

<!-- kobo-style -->
<link type="text/css" rel="stylesheet" href="css/kobo.css"></link>
<script type="text/javascript" src="js/kobo.js"></script>
<style type="text/css" id="kobostylehacks">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>
</head>

<body><div id="book-columns"><div id="book-inner">
  <div class="booksection" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns="http://www.w3.org/1999/xhtml">

So, are all "kobostylehacks" really necessary to give an epub the flexability for user input to change font size, line height, page margins …? Or should they be rewritten?
The kobo.js is necessary for annotations etc. just as <span class="koboSpan" id="kobo.X.X"> is added to every sentence in a html file to remember the last reading position and annotation location. But is outside the scope of this discussion.