kepub vs. epub

[icallaci]

Originally Posted by jackie_w

The occasional weird word/letter spacing is a bit distracting, however I'm going to persevere with it for now. Perhaps it's just the book I'm currently reading. I only ever read full-justified and it makes heavy use of m-dashes. If I don't set optimizeLegibility the random space often inserted after m-dashes (but not before) distracts me even more. It makes the text look "broken" because it's not symmetrical. It might not be so bad for a book which uses n-dashes which already have spaces on both sides. First world problems, eh

Agreed. For some reason, the weird spacing of em dashes and ellipses is more distracting to me than the (very) occasional wide letter spacing. The only time I noticed a problem was when the text read "12:4 5 a.m." (note the space between the 4 and the 5), but that's been the only real oddness so far, after about two hours of reading with the new patch. I am a convert. Thanks to everyone who figured this one out.

[GERGE]

Spacing is really a problem for me.

[sherman]

Tried this out, ligatures are nice and all, but I still went running back to RMSDK due to word/letter spacing.

My ideal epub reader would have the features of a modern web browser (HTML5 + CSS3), which I believe the Kepub render has, with the typography of TeX and its variants. Kerning, ligatures, Knuth & Plass (TeX) linebreaking, microtype (as used in pdfTeX and LuaTeX)? Yes please!

Unfortunately, no one seems willing or able to create such reading software

Typographically, RMSDK seems to be the best available software... just a shame about the lack of features.

[JSWolf]

What I would like to see is the ability to use the features in a OTF font. So for example, being able to use smallcaps in an OPT that has smallcaps as a feature.

[chrisridd]

What does the underlying HTML actually look like in the cases of strange spacing?

[jackie_w]

Originally Posted by GeoffR

Good:
* Ligatures work.
* The problem with lines containing em-dashes, ellipses, etc. not being properly justified is fixed.

Bad:
* Some words at the beginning of a line have extra-wide letter spacing.
* The spacing after the end of a sentence is sometimes much smaller than the spacing between words in the sentence.

Extra info for anyone who decides to go ahead and use the optimizeLegibility option despite its niggles, here's an extra item for the 'Good' side:

Good:
* optimizeLegibility seems to be able to access your font's kerning info (if it has any), even if you haven't forcibly added Old-style Kerning pairs.

[jackie_w]

Originally Posted by chrisridd

What does the underlying HTML actually look like in the cases of strange spacing?

I don't think there's a simple answer to that. Someone feel free to correct me if the following isn't right.

The KoboTouchExtended plugin's format-shift from epub to kepub 'fragments' the HTML text content and wraps each fragment in a Kobo span, e.g <span class="koboSpan" id="kobo.2.1">The cat sat on the mat.</span>.

Understandably KTE tries to match the algorithm Kobo themself use, which appears to be, basically, a simplistic attempt to fragment into sentences. Unfortunately there are many ways for this algorithm to create over-aggressive fragmentation. For example, the Kobo-style algorithm would result in the single sentence (admittedly contrived )

<p>“It’s 1:05 p.m. on Friday ... already too late!”</p>

becoming

<p><span class="koboSpan" id="kobo.1.1">“It’s 1:</span><span class="koboSpan" id="kobo.1.2">05 p.</span><span class="koboSpan" id="kobo.1.3">m. </span><span class="koboSpan" id="kobo.1.4">on Friday .</span><span class="koboSpan" id="kobo.1.5">.</span><span class="koboSpan" id="kobo.1.6">. </span><span class="koboSpan" id="kobo.1.7">already too late!”</span></p>

It has been split into 7 fragments where 1 would probably be sufficient. If a couple of words in the original sentence had had italic tags around them the fragmentation would have been even worse.

I don't think this aggressive fragmentation helps the kepub renderer's attempts at attractive full-justification. As GeoffR demo'd, it seems to be even less attractive when optimizeLegibility is enabled. In addition, the larger your preferred font-size, the worse it's likely to get. Standard epubs don't have any of these koboSpans getting in the way.

Just as an exercise (entirely non-scientific) I hacked my copy of KTE to try a simple, less aggressive fragmentation algorithm. You can see the results of a single page below. Kobo-algorithm on the left, less aggressive algorithm on the right. optimizeLegibility is enabled on both of them.

As you can see there are 3 lines (first, last, 8th-from-bottom) where the letter-spacing of the first word is no longer quite so odd. A sample of one page doesn't prove anything, of course. In addition I have no idea whether it would have a really bad effect on other things, e.g. annotations, bookmarks, text selection etc.

[GeoffR]

Originally Posted by jackie_w

Good:
* optimizeLegibility seems to be able to access your font's kerning info (if it has any), even if you haven't forcibly added Old-style Kerning pairs.

I wondered about that, because the kerning did look different in some places when I flicked back-and-forth between screenshots taken with and without optimizeLegibility. Generally it looked better with optimizeLegibility.

Edit: On second thoughts, the difference might just have been due to the presence of ligatures which were kerned differently to the individual letters. But it would still be handy not to have to add old-style kern tables to the fonts.

[GeoffR]

I tried using

body { text-rendering: optimizeSpeed; }

instead of

body { text-rendering: optimizeLegibility; }

and optimizeSpeed appears to fix the em-dash justification problem without the spacing problems caused by optimizeLegibility. It doesn't enable ligatures, Edit: and kerning no longer works.

[anacreon]

I don't know that this is the right place to mention it, but I had a strange experience with page numbers in kepubs. I usually like the page number per chapter, but I was reading a book with many htmls within each chapter, and I decided to go with page number per book, and it was strange: it went from 2 to 11 (without skipping any part in the book), and at the end the last page in the book was a few pages less than the total. I tried it with another kepub and it was the same. Anyone with the same experience? What is wrong, and is it possible to correct it?

[gilster]

Same experience here. In fact, I noticed just last night that pagination went from 3 to 11 with one page turn. I've seen this on three different books and don't have a clue about what's causing it.

[GeoffR]

I've seen page number and stats weirdness in some books caused by an inconsistency between the book's OPF spine and NCX toc, such as spine items with no corresponding item in the toc, toc items with no corresponding entry in the spine, or the order of toc items not matching the spine order.

For EPUB3 books the NAV toc probably has to be consistent with the NCX toc (if it has one) and spine too.

[JSWolf]

Originally Posted by GeoffR

I've seen page number and stats weirdness in some books caused by an inconsistency between the book's OPF spine and NCX toc, such as spine items with no corresponding item in the toc, toc items with no corresponding entry in the spine, or the order of toc items not matching the spine order.

For EPUB3 books the NAV toc probably has to be consistent with the NCX toc (if it has one) and spine too.

It's actually easier to delete the NAV ToC and convert the ePub 3 to ePub 2 than to edit the NAV ToC.

[jackie_w]

Originally Posted by JSWolf

It's actually easier to delete the NAV ToC and convert the ePub 3 to ePub 2 than to edit the NAV ToC.

I don't believe there's any need to do that for calibre users. The calibre TOC Editor automatically keeps the NCX and NAV files correct and in sync in epub3 books.

[DNSB]

Originally Posted by jackie_w

I don't believe there's any need to do that for calibre users. The calibre TOC Editor automatically keeps the NCX and NAV files correct and in sync in epub3 books.

Pretty much the same for those who use Sigil. The nasty bit is that this assumes that TOC entries are done use using header tags and not generated manually. Sadly manual TOCs are too common and often have weird errors in them. As in one recent ebook, where the nav.xhtml and toc.ncx were both present and both were incorrect and out of step with each other. This particular ebook also had the content split at random spots so it was easier to merge the whole futtering mess into one file and resplit it at chapter boundaries.