Quote:
Originally Posted by Sarmat89
That's not stupidity. EPUB format is too complex to be parsed and rendered by an embedded device, so it must be preprocessed into a less taxing form, like predictable-structure kepub or lightweight binary KFX.
|
I think you don't understand epub or kepub, or the sort of HW in readers. Even 25 years ago a cpu less powerful than in any ereader since 2005 could render web pages (HTML) including graphics. The Kepub adds extras to epub. Both are a zip archive with essentially the ingredients of a web page as separate files for index (NCX), each image, the cover, subset of HTML for the content broken into many files (ideally) and a css file. There may also be font files.
There would be very little difference in speed or RAM usage for epub2, epub3, kepub, the mobi-KF8 or ordinary web pages. The mobi 6 or PRC probably needs less RAM and cpu, especially if there are no images.
The slowest bit is the eink screen rendering, especially if there is 256 shade grey images. The true-colour RGB simply adds RAM overhead per image.
It's recommended that epubs/kepubs of any kind have no more than about 280K per part. The images are separate anyway and ought not to be larger dimensions than about 5" x 6" at 300 dpi (which is lunatic big) and jpeg. Even a 3" x 4" RGB JPEG is
ten times more RAM than a typical "part" (< 0.3M), as that is 3 M uncompressed. The jpeg file has to be uncompressed, converted to 256 shades grey, then processed for the eink display (most only do 16 shades = Black, White and 14 x greys).
The original part files should split from the source at paragraph, heading, chapter or page boundary. Some books don't have chapter or page breaks in the source. Then the text is formatted according to the css file and possibly embedded fonts used. The part file may be many screen pages, the pagination is done according to styles, font faces, text sizes, margins etc. It's more work than what a web browser does. Actually older kindles used to process web pages like this.
So the differences of epub and kepub are some mysterious idea to suit Kobo, nothing to do with cpu / RAM load of parsing.
KFX (if's it's true about being smaller) would be MORE CPU work than any epub/kepub/mobi-KF8 of the same content. It would have to be unpacked into css, XML/HTML, images, fonts and index to be rendered for the screen.
I've not even addressed links, footnotes or javascript. Even ancient mobi/prc from Mobi-pocket creator mentions javascript support. The old PRC also could have an extra tag in HTML source that meant "You can't turn page past here". That meant subsequent parts could only be reached via internal links or the TOC/Index. I'd the idea of using this to build a "plot your own text adventure" book. I never did find out what javascript was supported. The original prc/mobi also supported some sort of database. I still might do a simple adventure ebook, using just links. I have written (in 1992!) a source text to build a PC graphic adventure. I found the barrier was getting artwork done. So I might do it as a text only adventure. Using the ebook formats is easier to build, more portable and easier to distribute than an Android version (basically Java apps in all but name).
As an aside, Codex means a book, i.e. instead of a scroll over 2000 years ago they hit on the idea of cutting up the material into pages, writing on both sides and binding. The way most software works on screen since the 1960s is a backward step. I'd love a web browser that worked like ereader page rendering, that you could view the huge scrollable web "pages" (should be called Web Scrolls?) as pages, using tap, swipe, volume up/down, PgUp/PgDn, or < > keys etc to flip the pages like an ereader app does. Maybe there is a plugin. I must look!