kepub vs. epub

[TechniSol]

I'm a big proponent of the KISS method. Keep It Simple, Stupid! Epubs for me.

That said, if I found anything particularly compelling about the alternative, Kepubs it would be.

[davidfor]

Originally Posted by rashkae

The only limitation to Kepub that bothers me (which was not mentioned) is that the page number and position slider (if you are trying to use for the whole book rather than by chapter) goes completely out of whack for books that do not have a ToC entry for every html file. This is a problem with Calibre generated Kepubs only, AFAIK, but it would be nice is ACCESS reader was fixed so book progress followed the epub 'spine', the same as moving forward or backwards does.

Kepubs are supposed to have a one-to-one relationship between the ToC and the files. If someone uploads an epub to Kobo that is missing ToC entries, they are generated from the first line in the file. I suppose the extended driver could do this as well, but I can understand why the developer didn't want to.

[GERGE]

Originally Posted by dordale

I do wish there was some way to turn off the header. It doesn't really bother me, but I'd rather use that space for reading material--I don't need to have the name of the book I'm reading displayed--that's something I already know.

There are. Check this: https://www.mobileread.com/forums/sho...48&postcount=2

Full screen reading mode removes the header and the footer. But be aware that instruction here are for 3.12.1.

[jackie_w]

For anyone still following this thread ...

I have found that including the following in the CSS file makes ligatures display in kepubs for me. Of course the results are only as good as the font you're using:

text-rendering: optimizeLegibility;

or alternatively:

-webkit-font-feature-settings: "liga", "dlig";

I don't know if one has a significant advantage/disadvantage over the other. I'm currently using the first one to see how it goes.

I don't want to add special code to my calibre master version epubs so I applied it using the kobo_extra.css file of the 'Modify CSS' option in the calibre KoboTouch/KoboTouchExtended driver. As I don't know what (if any) effect this code would have in the Adobe renderer when added to a standard epub CSS file I made sure the code would only ever be used in kepubs by using this code in kobo_extra.css:

body > div#book-columns > div#book-inner {text-rendering: optimizeLegibility}

Here are a couple of screenshots to demo the slight difference with (left) and without (right) ligatures.

ETA: I should probably also add that this was all done on a KA1 with fw 4.1.7729. I have no reason to believe it won't work on earlier models with earlier firmwares but I haven't tested it because my other Kobos only contain standard epubs at the moment.

[ZodWallop]

Originally Posted by jackie_w

For anyone still following this thread ...

I have found that including the following in the CSS file makes ligatures display in kepubs for me.

Thanks! Can't wait to try it when I get home.

[GERGE]

Now, let's reconvert all library =)

[mathil]

I tried with my H2O updated to its latest firmware, 3.19.5761, and it's working thank you so much jackie_w! I'll have to resend all of my Calibre library now

[jackie_w]

Originally Posted by mathil

I tried with my H2O updated to its latest firmware, 3.19.5761, and it's working thank you so much jackie_w! I'll have to resend all of my Calibre library now

Thanks for testing the earlier model/firmware. That's saved me a job

Do report back if you notice any non-ligature typography which actually looks worse with this setting.

[GeoffR]

That's a great discovery jackie_w. In the developers forum I've made a patch `kePub optimizeLegibility default` that adds that style to the device's built-in kePub stylesheet.

[GeoffR]

I've been testing with the optimizeLegibility style on my Glo with firmware 3.19.5761 but I've also noticed these good and bad effects when using full justification:

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.

Overall I think it is an improvement, but still not as good as in ePubs.

Edit: Also tested with -webkit-font-feature-settings: "liga", "dlig"; and all the effects are the same as with text-rendering: optimizeLegibility.

Edit: These screenshots show the differences on my Glo with the built-in Amasis font selected, reading a DRM KePub synced from Kobo. In the first screenshot, note the word "But" at the beginning of the second paragraph, and the justification of the last line on the page. In the second screenshot, note the spacing of the seventh line from the bottom reading "soon enough. Crusty, lichen-dotted carapaces":

[jackie_w]

Originally Posted by GeoffR

That's a great discovery jackie_w. In the developers forum I've made a patch `kePub optimizeLegibility default` that adds that style to the device's built-in kePub stylesheet.

Even better

[ZodWallop]

Worked for me using Geoff's patching advice and Google Noto Serif as my font.

I only did a spot check and didn't notice the spacing issues. I may not see them for a bit as currently I'm using Kobo's Nickle font, which told me where I could shove my ligatures.

[mathil]

I did some more reading today and I noticed the 'extra-wide letter spacing at the beginning of the line' problem that GeoffR reported, only once. It was on the second half of a hyphenated word. Turned off justification so that the word would not be hyphenated anymore, and the problem was gone. Changing to another font (built-in Amasis) also seemed to fix the problem. I will keep reading with the justification off and see if it appears again.

EDIT: Read some more with the justification off. In my experience so far, when the justification is on the first problem (extra wide letter spacing) appears very occasionally; when it is off, this doesn't happen but I see irregular spacing in some lines that is consistent with the second problem that GeoffR reported, and much more often.

[GeoffR]

After reading for a few hours with the text-rendering:optimizeLegibility feature I'm finding the irregular word spacing quite distracting, I think it is worse than the lack of ligatures and the em-dash justification problems that occur without it, so I've gone back to how it was before.

I think I can see what the problem is, and the uneven word spacing and the wide letter spacing in some words are actually symptoms of the same problem:

If all the words in the line are in the same <span> then there is no problem with spacing. But if there are words in different spans then instead of adding an equal amount of space between each word to justify the line, space is being added to each span without regard for the number of words in the span.

So, if there is only one word in the span then the result is that space is added between letters, and if one span has two words and other span has three words then the word spacing in the first span will be wider than in the second span. And no space is added between words in adjoining spans.

The reason for the narrower spacing between sentences is just that Kobo add a span around each sentence, so each sentence gets different word spacing and no extra space is added between sentences.

[jackie_w]

Originally Posted by GeoffR

After reading for a few hours with the text-rendering:optimizeLegibility feature I'm finding the irregular word spacing quite distracting, I think it is worse than the lack of ligatures and the em-dash justification problems that occur without it, so I've gone back to how it was before.

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