Quote:
Originally Posted by violent23
Widows and orphans have to be manually set through conversions, hacks on the device or editing each individual .ePubs css. Otherwise the default setting of the firmware will display .ePubs with pages where half the page has no text quite often.
|
Ummm... widows/orphans with any definition in the stylesheet/body will cause 2 lines plus a inter-paragraph space at the most. The default for the RMSDK is widows/orphans=2. The half blank page sounds more like the long paragraph bug which was fixed a couple of firmware revisions back. Even reading Tolstoy's
The Cossacks no longer triggers that bug.
Quote:
Originally Posted by violent23
The .ePub engine still ignores embedded fonts from the css.
|
I have seen this but only on poorly done epubs. Epubs where the @font-face definition is not pointing to the font file. Epubs where all the font/image/text files are stuffed into the root directory of the .zip file. A bit of work with Sigil and the embedded fonts work more or less happily. I've attached a sample of a page from an epub which uses two embedded fonts. My wife reads quite a few ebooks that come with embedded fonts and so far has had no issues other than the size (200K for the ebook, 1.4MB for the fonts).
Quote:
Originally Posted by violent23
With widow and orphans on there is still a problem with .ePubs where some pages have room for another line of text but it still gets pushed to the next page. This is not the long paragraph bug but does have something to do with widow and orphans and how they display on the device.
|
Yes, widows and orphans will push lines to the next page. That's the whole raison d'être for the widows/orphans setting.
Quote:
Originally Posted by violent23
Annotations still have the problem with reopening .ePubs on the main memory messing up the percent read and the chapter the book is in.
|
You can open and review the annotations without opening the book. If you open the book, it would seem to make sense that the percent read and chapter would show the point where you were in the book.
Quote:
Originally Posted by violent23
And there is still a lot of .epub3 features missing even though they seem to find their way into the .kepub engine just fine. Which was my whole point, Kobo is actively adding features at a much faster pace for the .kepub engine then they are for the .ePub engine. They are actively pushing their own proprietary format while keeping hobbled the other option, all to give themselves an unfair advantage. Most people don't even know that Kobo pushes their own format thinking all Kobos are mainly .ePub devices. Kobo of course does nothing to dispel this myth leaaving their users to figure out on their own that all Kobo's are mainly .kepub devices that read .ePubs as a secondary and widely less developed alternative/option.
|
Yawn. The ACCESS NetFront BookReader EPUB3 renderer has been part of Kobo's firmware for quite a while now. And, yes, it is, more or less, epub3. Perhaps an advantage for Kobo in the Japanese market where epub3 is needed to support the complexity of Japanese writing.
The epub renderer is Adobe's RMSDK. The main reason for it's existence is to support Adobe's ADEPT DRM so we can borrow/purchase DRMed epub ebooks. Adobe/Datalogics/whatever have been slowly moving towards epub3 compatibility. The release of RMSDK 11 has taken more steps in that direction through adding chunks of the Readium epub3 technology but RMSDK 11 is not yet available on Kobo's eInk readers. From what I've read, ADE 4.0 which has a similar code base to RMSDK 11 is best described as feature incomplete when it comes to epub3 support.
So I would characterize your belief that Kobo is slighting epub2 as being at best a paranoid fantasy.