![]() |
#76 | |
Still reading
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 14,089
Karma: 105211945
Join Date: Jun 2017
Location: Ireland
Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper
|
Quote:
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! Last edited by Quoth; 06-30-2019 at 07:34 AM. |
|
![]() |
![]() |
![]() |
#77 |
Bibliophagist
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 46,288
Karma: 169098402
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
|
KFX doesn't get split into css, etc. unless you are unpacking it on your computer and even there, quite a bit of information is lost from the original input to the KFX generator. The way I see it, KFX is more like an old bytecode compiler's output than the compressed archives that epub/azw3 use.
Last edited by DNSB; 07-01-2019 at 01:57 PM. Reason: Corrected naked s to is |
![]() |
![]() |
Advert | |
|
![]() |
#78 |
Still reading
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 14,089
Karma: 105211945
Join Date: Jun 2017
Location: Ireland
Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper
|
Something in the Kindle ereader or a kindle app has to read the KFX and then render the book the same appearance as azw/KF8. So while there isn't an archive with human readable content, it can't be losing anything or the book wouldn't look the same. I've compared the visual appearance of "direct by WiFi from Amazon KFX" on a PW3, with the "Download to PC, Transfer via USB for <device target>" which at last use was still and AZW and it looks identical. So obviously the KFX has two aims at least, stronger DRM and dramatically reduce traffic cost for Amazon if someone has the 3G model of a Kindle. They'd not care about broadband + Wifi, or people using WiFi points with a mobile dongle, only their own account traffic. Obviously the KFX has not obvious archive text files, however it must have the same structure of content, styles, images and index.
|
![]() |
![]() |
![]() |
#79 | |
Bibliophagist
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 46,288
Karma: 169098402
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
|
Quote:
|
|
![]() |
![]() |
![]() |
#80 | |
Still reading
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 14,089
Karma: 105211945
Join Date: Jun 2017
Location: Ireland
Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper
|
Quote:
Obviously you can't open a KFX and see the same thing as in an AZW, it's encoded. However ultimately there is only storage space saving. The data has to be interpreted to produce the same results. It's originated as css, HTML, index (all no doubt in an intermediate stage encoded to XML, but I don't know). The images will be separate blocks of data. Then no doubt some sort of tokens for the non-image data and encryption for DRM. It's absolutely not a program, just a different representation of the data. Like bytecode/p-code to Java, J++, C#, VB or UCSD-Pascal, you can get back a human readable source, but it will have lost all non-essential to the page content and rendering information and be hard to read. At "run time" the Kindle or Kindle app must be converting KFX data to the equivalent of text, styles, index and separate blocks of images. Nothing else makes any sense. It's ENCODING, not byte code or p-code in the sense of a program. It makes it VERY much more compact than general purpose zip archiving can and thus any encryption (DRM) is more effective. I totally agree there in no concept of "seeing" NCX, CSS, HTML and JPEGs in a KFX, nevertheless it's encoded and thus might have a higher CPU load than AZW/KF8, epub, kepub as the aim is lower transmission cost and more security. The original point was that kepub certainly isn't any significant reduction in reader cpu requirement, neither is KFX. Probably the reverse as they are newer formats to aid distribution. |
|
![]() |
![]() |
Advert | |
|
![]() |
#81 | |||||||||||
Wizard
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 2,804
Karma: 7025947
Join Date: May 2016
Location: Ontario, Canada
Device: Kobo Mini, Aura Edition 2 v1, Clara HD
|
Overall, I feel the Kobos have more pros than cons. I would always choose a Kobo over basically any other brand.
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
|||||||||||
![]() |
![]() |
![]() |
#82 | ||
Grand Sorcerer
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 24,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
|
Quote:
![]() There are also some other impacts. I think one of the recent releases was for some other product release or change, possibly "Kobo Plus" in the countries that have it. I think they had planned to include the Parental Controls with that, but couldn't finish it in time. So they hid it, and had another release when they were happy with it. Quote:
|
||
![]() |
![]() |
![]() |
#83 | |
Wizard
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 2,804
Karma: 7025947
Join Date: May 2016
Location: Ontario, Canada
Device: Kobo Mini, Aura Edition 2 v1, Clara HD
|
Sometimes, yes
![]() Quote:
|
|
![]() |
![]() |
![]() |
#84 | |
Wizard
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 1,086
Karma: 6719822
Join Date: Jul 2012
Device: Palm Pilot M105
|
Quote:
![]() |
|
![]() |
![]() |
![]() |
#85 | ||
Bibliophagist
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 46,288
Karma: 169098402
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
|
Quote:
![]() ![]() That same chipset with different microcode chips, sold as the MCP-1600, was the basis for PDP's LSI-11 computer. Ahhh... the good old days of microcomputing. ![]() |
||
![]() |
![]() |
![]() |
#86 |
BLAM!
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 13,506
Karma: 26047202
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
|
@geek1011: See this PR for an example of that kind of behavior in KOReader.
(It could be polished to apply to the initial selection process, instead of only the edit of an existing highlight, and to re-position the popup so it doesn't intrude on the actually highlighted content. But, yeah, the concept works pretty well, and definitely makes sense.). Last edited by NiLuJe; 07-02-2019 at 05:07 PM. |
![]() |
![]() |
![]() |
#87 | |
Grand Sorcerer
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 13,534
Karma: 78910202
Join Date: Nov 2007
Location: Toronto
Device: Libra H2O, Libra Colour
|
Quote:
Sent from my moto g(7) power using Tapatalk |
|
![]() |
![]() |
![]() |
#89 | |
Wizard
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 2,804
Karma: 7025947
Join Date: May 2016
Location: Ontario, Canada
Device: Kobo Mini, Aura Edition 2 v1, Clara HD
|
Quote:
![]() |
|
![]() |
![]() |
![]() |
#90 | ||
Pain in the arse
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 758
Karma: 77856
Join Date: Apr 2013
Device: Kobo Aura One, Kindle 4
|
Quote:
Quote:
--- About KFX, for what I know it's not HTML+CSS anymore. It's simply JSON: https://wiki.mobileread.com/wiki/KFX I think this is an absurdity. HTML and CSS are mature languages for displaying the content of a book. Epub 3 has more than enough to be a better competitor of KFX: 1. It's based on HTML5, so you can add videos or audio files. You can have a text and audio book at the same time. 2. Supports comic books, no more need of CBZ. 3. it supports annotations internally, so you can read the epub with the same annotations even on another device. This IMMENSELY useful. If I want to share a book, I'm interested to share my annotations too. 4. For scientists and geeks, it supports SVG and MathML. I think that if Calibre will finally support the conversion to the Epub 3 format, there will be no story for Amazon closed and proprietary formats. For now you have to edit the book, click Tools and Update the internals. Not so intuitive. PS: well, Epub 3 has also JS. Nothing is perfect ![]() Last edited by Lucas Malor; 07-06-2019 at 06:23 PM. |
||
![]() |
![]() |
![]() |
Tags |
kobo bugs annotation |
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Kobo Aura H2O - Dictionary sucks | machoman121 | Kobo Reader | 35 | 11-13-2018 07:10 AM |
Aura HD it's HERE! gawd the stock firmware sucks. | sambo. | Kobo Reader | 7 | 04-11-2014 09:45 PM |
Amazon Sucks | georgiworld | Kindle Developer's Corner | 55 | 05-18-2011 05:44 PM |
DR800 DR 800 and Firmware 2.0 sucks | schai | iRex | 15 | 04-14-2010 06:09 AM |
PDF Sucks and see here why... | TadW | 15 | 01-25-2007 04:24 AM |