KFX Format

[jhowell]

Originally Posted by eggheadbooks1

How bizarre. Will report to Amazon. Thanks for the sleuthing.

It is not all that surprising to me. Unlike KF8, which was released in pretty much its final form, KFX is being improved iteratively. Less commonly used features, such as table captions, have yet to be supported.

For some reason HTML table support is one of the last e-book features to be implemented in KFX. The initial Kindle firmware with KFX, 5.6.5, did not support tables at all. Subsequent firmware releases have have added support for table features incrementally. Even the Kindle firmware released this week, 5.8.8, has further improvements to table handling according to the release notes.

[eggheadbooks1]

Originally Posted by jhowell

It is not all that surprising to me. Unlike KF8, which was released in pretty much its final form, KFX is being improved iteratively. Less commonly used features, such as table captions, have yet to be supported.

For some reason HTML table support is one of the last e-book features to be implemented in KFX. The initial Kindle firmware with KFX, 5.6.5, did not support tables at all. Subsequent firmware releases have have added support for table features incrementally. Even the Kindle firmware released this week, 5.8.8, has further improvements to table handling according to the release notes.

Somebody mentioned way back in this thread that the conversion to KFX of ebooks already in the Amazon catalogue appeared arbitrary. But having read your post, I would think the selection is not arbitrary at all, that Amazon is selectively converting ebooks to KFX depending on which elements are present in the ebook. So it's likely they simply started with ebooks that did not make use of any special formatting, forgoing those with elements not yet fully supported. As more capabilities are added to KFX, more ebooks will be converted to the new format.

[AcidWeb]

Another batch of KFX only manga features landed today. And they increased speed of page turning and Panel View even more.

[jhowell]

I came across Amazon documentation for Ion, the data format that KFX is based on, at https://amznlabs.github.io/ion-docs/.

Reference implementations of Ion in Java, C and Python can be found at https://github.com/amznlabs.

[darryl]

Originally Posted by jhowell

I came across Amazon documentation for Ion, the data format that KFX is based on, at https://amznlabs.github.io/ion-docs/.

Reference implementations of Ion in Java, C and Python can be found at https://github.com/amznlabs.

Excellent. Hopefully it will help in overcoming the obfuscation/encryption.

[pirl8]

I've searched the thread but couldn't find an answer.

Among the KFX format "enhanced typesetting" there should be dropcaps.
The question is: how to use them?

I've tried with no luck with the CSS ::first-letter selector.

Of course it's possible doing it via simple CSS but the rendering is quite font-family (and device) dependent.

[jhowell]

Originally Posted by pirl8

I've searched the thread but couldn't find an answer.

Among the KFX format "enhanced typesetting" there should be dropcaps.
The question is: how to use them?

I've tried with no luck with the CSS ::first-letter selector.

Of course it's possible doing it via simple CSS but the rendering is quite font-family (and device) dependent.

There are instructions on how to format drop caps in the Amazon Kindle Publishing Guilelines section 9.3.5. The conversion to KFX looks for that formatting.

[Hitch]

Originally Posted by jhowell

There are instructions on how to format drop caps in the Amazon Kindle Publishing Guilelines section 9.3.5. The conversion to KFX looks for that formatting.

JHowell:

I haven't had a chance to look at that yet, but if that's the same-old, same-old coding for DCs that has been in now for some PGs, that doesn't work worth two craps when you cross the Device Line--from Fires to the KF8 eInks (PPW, etc.). The PPW, to be particularly capricious, basically requires the user to actively select "Publisher Font," and if they don't, it's nearly impossible to get the Drops to work, in that environment. As drops, that is.

We use about five million lines of code/HTML/CSS, with about 10 media queries, just to TRY to get those right. It's a royal pita. If the new KC somehow magically overcomes that, I'll be ripping those mobis/KFX/KPFs apart, to see what they're doing.

Offered solely FWIW.

Hitch

[pirl8]

Originally Posted by jhowell

There are instructions on how to format drop caps in the Amazon Kindle Publishing Guilelines section 9.3.5. The conversion to KFX looks for that formatting.

Thank you very much.

It seems to me that this is a "classical" CSS solution. I've tried to load sample (see attachment - it's in Italian but that shouldn't do any difference) either with Kindle Previewer 2 and Kindle Previewer 3. The suggested dropcaps solution works in both cases. In the latter the first letter is rendered as normal text if the font is too big.

Also, it seems to me that non-breakable-spaces are not honored in KFX.

P.S. I read somewhere that KFX would incorrectly break numbers with many digits across two lines but as far I can see this is not true (unless the number is wider than the screen).

[Hitch]

Originally Posted by pirl8

Thank you very much.

It seems to me that this is a "classical" CSS solution. I've tried to load sample (see attachment - it's in Italian but that shouldn't do any difference) either with Kindle Previewer 2 and Kindle Previewer 3. The suggested dropcaps solution works in both cases. In the latter the first letter is rendered as normal text if the font is too big.

Also, it seems to me that non-breakable-spaces are not honored in KFX.

P.S. I read somewhere that KFX would incorrectly break numbers with many digits across two lines but as far I can see this is not true (unless the number is wider than the screen).

I've never seen a solution that actually works in a foolproof way on a Paperwhite. The simple expedient of the two margins almost always screws up the Drop. Of course, you've kept it simple here--using the SAME font as the body style, so that helps, but typically, IME, they don't work on all devices (and especially not on the iOS devices).

Once you use a specific font for the Drop, all bets are off.

BUT, good luck to you with it!

Hitch

[pirl8]

Originally Posted by Hitch

I've never seen a solution that actually works in a foolproof way on a Paperwhite.

Mee to.

The solution I'm using is the one suggested in the "Amazon Kindle Publishing Guidelines" and ... actually is not a definitive solution at all. It's simply a CSS trick.

As far as I can see, dropcaps are rendered almost the same in AZW3 and in KFX.

Since amazon claims that KFX has an enhanced dropcaps support I'm simply wondering what it does look like.

[jhowell]

Originally Posted by pirl8

It seems to me that this is a "classical" CSS solution. I've tried to load sample (see attachment - it's in Italian but that shouldn't do any difference) either with Kindle Previewer 2 and Kindle Previewer 3. The suggested dropcaps solution works in both cases. In the latter the first letter is rendered as normal text if the font is too big.

From the Previewer 3 - Frequently Asked Questions:

Q2. What is Enhanced Typesetting?
A2. Kindle books with Enhanced Typesetting enable a better reading experience by providing a series of typographical and layout features that are automatically enabled on Kindle books. It provides smoother word spacing with better hyphenation, drop caps that dynamically adjust with font size, kerning and ligature improvements, adaptive page layout and margins, allowing faster reading with less eyestrain. Visit http://www.amazon.com/betterreading for more information on Enhanced Typesetting.

Perhaps your finding about how large font sizes are handled is the only significant change in dropcaps for KFX. Amazon does not provide any details.

Originally Posted by pirl8

Also, it seems to me that non-breakable-spaces are not honored in KFX.

There was some discussion about nbsp characters in KFX earlier in this thread. My understanding is that they are honored as long as they are not over used.

[jhowell]

Kindle Previewer 3 version 3.11 beta is now available.

New in Kindle Previewer:

You can now preview Indic language books on Kindle Previewer.

We have added support for previewing books in Word format (English only).

Includes better floating elements support in Enhanced Typesetting.

[Hitch]

Hi, kiddles:

Well, are we having fun yet?

You all know how often, here at MR, we're seeing that John or Jack or Harriet is trying to solve some typographic issue, and s/he decides to use "display: inline-block?" Well, guess what? That is ixnay with Advanced or Enhanced Typography.

We actually received our first-ever KQN, for formatting, today. 3500+ books, and we get this BS:

Error Category: Formatting-Others; Comments: We noticed that your eBook which is currently in high demand with the customers is not enabled with enhanced typesetting.

Issue: The epub file consists of tag/property "display: inline-block;" that is not currently supported in Enhanced Typesetting conversion.

Issue location: The tag/property is present in CSS file inside the Epub.

Associated Class: .spa2, .spa1, .spa.

Proposed Solution: The "display: inline-block" property has been used to give block property to an inline entity. Change the property from "display: inline-block;" to "display: inline;". Adjust the margin to retain the alignment as of the source. This will solve the issue and enable with Enhanced Typesetting feature.

So, kids, display:inline-block is NOT supported, and moreover, you can get slapped on the wrist for using it.

We'd used it to create bulleted lists, with the obligatory hanging indents, for this person's book, that didn't use the ;bull character, but used squares, some little faces, and a directional sign, instead. But, IXNAY on the Inline-Block-ay.

Needless to say, the client is underwhelmed. He's being reasonable, thank GOD, but he's not a happy camper.

We also got a rasher of s**t about using line-heights, but I explained that we use varying fonts, and those use different x-heights, and have different tail/descender and ascender heights/sizes. I mean, are they KIDDING? I replied, "thank GOD that they can't adjust the damn line heights!" As most of you know, if you set the line-height, in MOBI, the end user can't adjust the line-heights, on the K4PC/K4Mac, etc., apps. Now, I'm all in favor of the user being able to do that, for the BODY fonts and main narrative, but for special elements, like headings and the like? Eff, no!!!

I thought that you kids may want to know this!!! Interferes with enhanced typography. I checked--just in case I'd missed something--I ran the source through KP 3.10, again, just to see if a warning came up, or anything like it, and it sailed through.

You'd think that if there's CSS that's going to interfere, with ET, they'd bloody well tell you, wouldn't you?

BU**ER!!

Spoiler:

Oh, yeah, and how MANY books do we have, out there in the wild, that have or use display: inline-block? How many? About a thousand, unless I'm mistaken. It's giving me the yips.

Hitch, whom, today, is (grumpity, grump, grump grump)

[badgoodDeb]

Originally Posted by Hitch

BU**ER!!

Why is "BUTTER" a redacted word?

PS Sorry it is giving you so much grief.....