Kindle Touch & KF8 eek! (maybe)

[jswinden]

Originally Posted by Strether

No problem with either. It shows up fine on both devices, though IMO, way better on the Fire. But no black pages on the KT.

Jim

Thanks. Then that is good news as it shows that well formatted KF8 compiled by Kindle Previewer does display on the KT. Tomorrow I'll take a closer look at your book to see if I can find what the issue is.

[Strether]

Originally Posted by jswinden

Thanks. Then that is good news as it shows that well formatted KF8 compiled by Kindle Previewer does display on the KT. Tomorrow I'll take a closer look at your book to see if I can find what the issue is.

I suspect others would be interested in your results, too.

For the heck of it, try loading the copy of Kim that I made from my Fire book, if you would.

Jim

[jswinden]

Originally Posted by Strether

I suspect others would be interested in your results, too.

For the heck of it, try loading the copy of Kim that I made from my Fire book, if you would.

Jim

Sorry, my Fire doesn't recognize that file either.

[Strether]

Weird.

[victauria]

Originally Posted by jgaiser

Mostly I do ignore Jon. He's managed to make me ignore complete sub-forums.

[tomsem]

Originally Posted by AnemicOak

Have you heard of a single problem with a KF8 book that's been downloaded by a Touch user from Amazon? Seems to me you're looking for a problem that so far hasn't shown itself. Yes there appear to be a few problems with some KF8 stuff output by Calibre, but Calibre's support for the format is very young and still being developed is it not?

EDIT: I see from another thread you're talking about 'Kim' conversions that aren't working. It does indeed seem that the Touch isn't reading that correctly from either Calibre or KindleGen.

Umm, actually yes, I have had such problems:

Wool Omnibus Edition

It looks fine on my Fire but on Kindle Touch the text size is about 4 sizes too small. Download a sample to see. A disaster.

Another case study is Umberto Eco's Prague Cemetery (which is priced 81% below the paperback edition BTW). The font sizes for titles (meaning h1/h2... tags) are much different between KF and KT (KT's are too small). On KF, you can only change the typeface of the titles, and the typeface of the text alternates between serif and sans serif (the latter used for quotations). On KT, typeface selection affects everything, and there's no alternation of typeface. The latter result makes it difficult to identify the quoted text as quoted text (in mobi it would have had an indent via quote tag; I think the designer in this case would have done better to use some means other than typeface to signal this, but still: it sort of works on KF, but not on KT).

It seems KT's line spacing is a bit bigger than KF's with the 'same' setting, as well. 'medium' looks a little too large on KT.

These are virtually the only KF8 books I've tried on KT so far. They both have some issues. So yes, I have some concern about the KT implementation of KF8.

I would like to do more experimentation with my own KF8 creations. Perhaps the above were created with pre-release, buggy versions of kindlegen. But even if that's the case it would not account for the differences seen.

Also while media tags can be used to distinguish between CSS for mobi vs kf8, I don't think they can distinguish between two KF8 implementations (nor should they be able to: KF8 CSS should be 'the same' for all KF8 features the implementations have in common).

[Update:] As it happens, I've downloaded a couple more KF8 files, and these have been fine on both devices. I'm getting used to the slightly larger leading on KT.

[kovidgoyal]

This thread is hilarious.

FYI: The problem with the Kim ebook is that it sets height: 100% on the html and body elements in the css. This breaks amazon's KF8 renderer on the Touch whether you create the KF8 with calibre or with kindlegen. Just remove that line and you will no longer get the black pages.

@JSWolf: Every epub renderer has quirks. ADE has quirks, calibre has quirks. And now Amazon's epub renderer has quirks. http://oldbugs.calibre-ebook.com/wiki/ReaderQuirks

@jswinden: Amazon's KF8 renderer is based on webkit (a browser) and it is not true that it requires "stricter" markup. What is true is that the renderer has lots and lots of bugs and quirks, *some* of which amazon know about and have documented in kindlegen warnings. Off the top of my head:

No support for line-height on the Touch
Setting height: 100% on body causes black pages on the Touch
No support for position:relative
Kindle Previewer requires the compiled guide items in KF8 to be sorted aphabetically by type or it wont work

All of these (except the last) are in contravention of the HTML5+CSS3 specs.

And I'm willing to wager any amount you like that there will be plenty more quirks coming to light in the near future.

[HarryT]

Thanks, Kovid. Informative and helpful, as always.

[jswinden]

There were several issues with the book, including an improper cover definition, which of course is unrelated to the black screens. I haven't looked at the CSS yet, but I'll take Kovid at his word. As I said to begin with, "Crap in, crap out." This was a sloppy book to convert and the results were expected. i respectfully disagree with Kovid on the stricter markup required for KF8 as far as the opf goes.

[JSWolf]

So is the Fire's KF8 renderer not based on web-kit and actually written from the ground up (as it seems to work better)?

[kovidgoyal]

Originally Posted by jswinden

Crap in, crap out.

Just so we're clear, setting the height of body to 100% is not crap. It is perfectly legal HTML/CSS. No other html renderer that I know of has any trouble with that bit of CSS, nor is it in contravention of any relevant spec.

[jswinden]

Originally Posted by kovidgoyal

Just so we're clear, setting the height of body to 100% is not crap. It is perfectly legal HTML/CSS. No other html renderer that I know of has any trouble with that bit of CSS, nor is it in contravention of any relevant spec.

I respectfully disagree. I could care less what other HTML renderers do. It is bad form to use certain format settings inside the CSS and then hope the renderer will correct your garbage. But then again I spent a quarter century as a technical writer so that probably explains why I disagree. Every time I inherited another TWs book I would typically have to spend a lot of time cleaning up formatting code so it would print/display correctly. This was especially important in the early years when printing was such a PITA. I'm talking professional printing, as in send your book to a professional print shop. And yes, if your files contain garbage and a renderer pukes out garbage it is your fault, not the fault of the renderer.

My philosophy is to make sure the formatting, and everything else, is as clean as possible. Sure the ePub and HTML renderers might be forgiving and turn out decent eBooks from your files, but occasionally you are going to come up against a renderer that doesn't. So clean is important. It is also important for when the book gets converted to other formats whether digital or print. And yes, if your book contains garbage and the renderer pukes out garbage, it is your fault, not the fault of the renderer.

[kovidgoyal]

When it comes to HTML, there are *different* renderers that render the same formatting instructions *differently*. That means that it is *not possible* to create HTML that will "render cleanly" in all renderers. Especially when you have created the book before the renderer that is failing to render it existed.

In the HTML world the closest thing to standardization that exists is the W3C HTML pseudo-standard. And if you write a book that is correct as per that standard, and that book is then rendered as garbage by renderer X, in contravention of that standard, then the fault is the renderers, not yours.

And let me emphasize, that *all* HTML renderers, not just Amazons, break the standard in many different ways. Not to mention all the behavior that isn't covered by the standard.

[JSWolf]

Originally Posted by kovidgoyal

Just so we're clear, setting the height of body to 100% is not crap. It is perfectly legal HTML/CSS. No other html renderer that I know of has any trouble with that bit of CSS, nor is it in contravention of any relevant spec.

And it is also valid HTML5/CSS & XML/CSS.

Since the Fire's KF8 implementation works with line-height at 100% and Kindlegen allows it to be part of the KF8, then it is valid. It's just the renderer in firmware 5.1 that's broken. Sure there is a work around that's easy to do, but I think a lot of people will not know this.

[jswinden]

Originally Posted by JSWolf

And it is also valid HTML5/CSS & XML/CSS.

Since the Fire's KF8 implementation works with line-height at 100% and Kindlegen allows it to be part of the KF8, then it is valid. It's just the renderer in firmware 5.1 that's broken. Sure there is a work around that's easy to do, but I think a lot of people will not know this.

According to the Amazon Kindle Publishing Guide version 2012.3, page 11, section 3.1.7, and I quote:

To ensure pagination, the Kindle Reader does not honor line-height value less than 1.2 em or 120%.

"Works with" and "should not do" are not the same thing. The Fire might allow it but Amazon says don't use it. Read the manual! As I said earlier, Kindle Previewer will render a book even with errors as long as they are not catastrophic errors. That doesn't mean the book will display correctly.