epub vs kepub

[cct1]

Originally Posted by anacreon

I very much prefer kepubs:
* for all books the page looks better to me with a header and footer, whether the screen is 6" or 6.8" - but this is obviously subjective
* annotated books don't work well with epubs on kobo (they were okay with sony)
* the zoom possibilities for pictures are convenient
* the page number by chapter felt strange at first, but I wouldn't go back to the page number by books. This is especially true for complete works, or collections of short stories, and I jump page for each poem in poetry collections. If I want to know where I am in the whole book, I tap bottom centre to get the % top centre. Also I add the number of pages as a first line in the metadatas to have the information at hand.

Couldn't agree with this more. I was going to get rid of the header, and keep the footer, but I'm getting so used to it I think I'll probably keep it. The page looks like a book page rather than part of a book page. Silly I know, but I really like it.

[Joques]

I agree 100 % with anacreon and cct1 on the aesthetic impact.

In addition, I tend to like footnote-heavy books, and the popup footnotes are awesome.

[arspr]

Originally Posted by Ripplinger

That's one of the issues I dislike about kepubs as well. But even when I purchase a kepub from Kobo, it still had everything aligned left and not centered, so I really don't think it's from converting epub to kepub. I think if you select justified text in the settings, it overrides everything as you said and not just the main body of text.

Yes, I agree with you. I also think that justify/left settings shouldn't be applied to centered/right aligned texts... But IIRC, (I'll test it ASAP), this trouble also happens in Kobo implementation of RMSDK, I mean, in epubs.

(More over: remember that, as a completely unexpected and unasked for side effect, when you force text justification through GUI in ACCESS, hyphenation is also turned on by default...)

Originally Posted by Jellby

This was only a guess. But what I mean is that when the user selects "justify", the reader could apply it (on top of the book's CSS) in different ways. A possible way is adding an implicit "body { text-align: justify }" rule. Another way is a "* { text-align; justify !important }" rule, and yet another is ".normal-text { text-align; justify }". The first would be my preferred one, the second overrides some alignment which is not meant to be overriden, the third requires the class "normal-text" to be used in the code. I don't know which are the chosen ones in the different renderers, but it seems to me they are different, and I'm used to work with ADE's one.

Because of the shown behaviour I really think it's the second one (with !important)...

The first one would only apply for text free any kind of CSS text-align setting, and that's not what we get.

On the other hand, I would like to know how to code jackie_w's preference (and also mine). I mean a CSS setting which weren't apply to any paragraph with right/center but which where applied to any paragraph with left/justify, no matter how those values were previously set in the book CSS styles.

Originally Posted by Jellby

If you are interested, could you try this test?

Why not?

Downloaded both books just now from your own thread. I'll test them converted into kepubs when I have some free time.

[davidfor]

Originally Posted by arspr

(More over: remember that, as a completely unexpected and unasked for side effect, when you force text justification through GUI in ACCESS, hyphenation is also turned on by default...)

That's exactly the behaviour I expected. With left justification, I don't expect any hyphenation. But, when the text is justified, I expect to see hyphenation. Without it, the gaps between words could be bigger than the words.

[arspr]

Originally Posted by davidfor

That's exactly the behaviour I expected. With left justification, I don't expect any hyphenation. But, when the text is justified, I expect to see hyphenation. Without it, the gaps between words could be bigger than the words.

Ok, maybe that's your preference as mine is hyphenation always off and others may prefer always on even in left alignment... (and others may want hyphens in left in order to fill the ragged left endings at the maximum possible ratio, but not in justified text because they prefer wide spaces to broken words).

The issue is that they are TWO different features not absolutely related, so merging them and more over WITHOUT explicitly saying it (AFAIK) is not a good decision, at least IMO.

[sherman]

I prefer epub over kepub myself.

The main reason for this is that IMO the ACCESS renderer just does not justify text as well/nicely as the RMSDK engine.

Which is a shame, because I otherwise quite like ACCESS, and RMSDK does have some annoyances. For example, it is 2014, and adobe STILL doesn't support smallcaps font variants

[Smallpox]

Originally Posted by yayo

The main advantage, some claim, is that the H2O processes kepubs faster than epubs. I can't confirm since all I have is kepub, converted onthe fly with the KePub Output Plugin for Calibre. Also you get page header and footer with kepubs (at the expense of text) and the option to chose either book or chapter page count.

Can we modify the Kepub format with calibre to have:
Book page count in the header and chapter page count in the footer?
Could be a great option for kepub plugins....

[davidfor]

Originally Posted by Smallpox

Can we modify the Kepub format with calibre to have:
Book page count in the header and chapter page count in the footer?
Could be a great option for kepub plugins....

No, the header and the footer are put there by the reader application in the firmware. The header is simply the title from the metadata in the book. You can modify this, but, once it is set on the device, it is fixed.

[PeterT]

Originally Posted by Smallpox

Can we modify the Kepub format with calibre to have:
Book page count in the header and chapter page count in the footer?
Could be a great option for kepub plugins....

That has NOTHING to do with the book itself, but rather with the READING software.

[aceflor]

Thank you so much for all your answers ! That has helped me a lot and now I am experimenting with kepubs, and seeing more differences than I first thought.

[arspr]

After playing with Jellby's test book in epub an kepub flavour:

I re-re-confirm everything I had previously told.

More differences / issues:

• ACCESS always has a slight margin. Even at 0 in book and GUI your text does not reach the left-right margin of the screen. RMSDK is much more aggressive. (In fact I feel ACCESS is better, althugh it suffers the trimming letters issue which is not good...)
• As already said if you force justification through GUI, ACCESS overrides any kind of setting in the kepub.
  In RMSDK that forced justification seems to be set as a BASE setting on <p> (and maybe <div> sections?).
  So any paragraph which has an in-book setting through classes applied to <p> is not going to be affected. So if your book paragraph is explicitly set to text-align: left; it is never going to be justified.
  OTOH if your justification is set in the book through <body> and then inherited over <p>s, it seems to be overriden (because as I said it seems that RMSDK just adds a p{text-align: GUI-setting;} style). As example the NoMargins.xhtml is modified through GUI settings but the paragraphs in Justification.xhtml aren't (but the intro paragraphs in that Justification.xhtml file are).
  I think this behaviour is much better than ACCESS one.
• ACCESS has as a side effect that hyphenation is enabled when justified through GUI... RMSDK has the opposite behaviour. Its default hyphenation is disabled when left justification is forced (yes I'm getting some hyphens in that test book).
• As expected RMSDK is not epub3/CSS3 capable in any way.
• cm absolute measure unit is FUBAR in both systems (at least in my H2O) but is much more FUBAR in ACCESS (5 cm rendered as 1.8 cm) than in RMSDK (5 cm rendered as 4.4 cm).
• OTOH full height is pretty strange in RMSDK because it draws a full screen rectangle BUT it's splitted. In the first page you get "one line" even when you have a lot of available free space, and in the second you get the rest. In ACCESS it seems to be ignored.
• RMSDK ignores "oeb-page-xxx".
• SVG support is somehow incomplete in both. (The rotated text is not displayed in both renderers and there are always some paging issues).
• Links through images do not work in ACCESS (wild guess: because of the built in image viewer?)
• I think that Lobster slanted font is not correctly rendered in RMSDK. In ACCESS all three Lobsters look the same, in RMSDK only first and third ones.
• RMSDK supports ligatures, ACCESS doesn't (if the used font supports them, obviously).
• RMSDK supports right to left texts, but they are left aligned... ACCESS seems to work fine. (Nevertheless there are missing unicode chars...)
• I really don't care about named entities... I agree with Kovid Goyal, unicode chars should be used instead... It's just safer.
  Nevertheless ACCESS does not allow to re-define standard entities like &mdash or &hellip. It also fails in &ap but not in the rest (wild guess: because it's a two letter entity ?????).

[dixieknits]

How do you get book page count instead of chapter page count.. I hate the chapter only page count.. My biggest complaint with Kindle also..Thanks

[aceflor]

Originally Posted by dixieknits

How do you get book page count instead of chapter page count.. I hate the chapter only page count.. My biggest complaint with Kindle also..Thanks

It's not in the patch, it's in the normal reading settings, second page if I remember correctly...

[arspr]

Ok, I've updated the v2 test book Jellby posted here with three extra tests:

• Trimmed fonts in left/right margin when justifying (ACCESS issue).
• The drop of white-space: nowrap; support that RMSDK has suffered at least in Kobo implementation. (It correctly works in my old Sony PRS-650).
• The strange spaces ACCESS adds around a lot of punctuation marks which also break justification.

Maybe Jellby should polish the syntax (I'm not native English speaker) and/or internal html/CSS code but I think it can be a good enhancement over the original test epub. Feel free to edit and change whatever you think.

Enjoy.

[Nick_1964]

Originally Posted by Josieb1

On the odd occasion I have sent an epub to my Kobo when I display it I get text right at the top of the screen and a big gap at the bottom. If the Full Screen Reading hack worked okay it wouldn't be an issue but as it has a few bugs I now prefer to have a header and footer and they display perfectly with kepubs.

I also use the Kepub Output Plug in which works seemlessley.

The full Screen Reading hack and the hack to change the footer ,works perfect on My Glo and Aura HD so I think there is something wrong with your settings rather than the hack itself which are perfect.

In general,referred to the question:
I only use sideloaded epubs and I see no advantage of the kepub format, only that it displays more information about the chapter but I am only interested in on what page I am in the book and I am not interested in how many percentage it is or when I finish the chapter.
Information about percentage of the chapter isn't in a paper book and It doesn't give more reading experience when I do know it.
Thinks in my screen that adds something to the story in the book,okay.. but if I want stats I can look it up,i don't want it all the time visible, I am interested in the story of the book,want to read it,that is where a book is for, it is like turning on the EPG on the tv all the time to see how many minutes are left of the program until the next one start,it distracts from the real story.
The books in the kobo store are way to expensive compared to Google or Amazon and when I do a sync I get all the books back that I buyed at Kobo (1) and have to log in to put that off.
I can't say or deny that kebubs do load faster..the one I have and the two I converted (from epub to kepub) to test them,are not.
I don't like the format in means of wasting space by always visible headers and footers with information that does not add anything to the story itself,but then, I have always read only epubs on Sony since the 5 series.
A normal paper book only gives me information about the page I am, and I can look how big the part that I have to read is by it's size and when u are in the middle.
As I said,I am not interested how many percentage I still have to read,to have the title on my screen all the time at the top ( i do know what book i am reading and I need no device to tell me that all the time) it doesn't sync between 2 readers what book and page I am like Kindle does, I have more then 1800 books on Calibre but I send 20 books or so to my reader and change them at the moment I finished them, no need to have 500 books on the reader with 100 read already..the ones I already read only occupied space so I delete them and I see no advantage of the kepub rather then waisting space on my pages that can be used for txt.
With Calibre I always convert epubs in a way that they are lined up on the left, disable justify (hate that) and disable all alignments, I hate jumping txt all over the place leaving gaps,or stretch all txt to have full lines but a lot of spaces in it, so no empty spaces at every <p> tag.
My personal opinion,not for debate.