Quote:
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.
|
Quote:
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"> </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.
Quote:
|
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.
Code:
<!-- 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.