KFX Format

[eschwartz]

Originally Posted by HarryT

That won't display hyphens on the Kindle Voyage. It certainly doesn't use WebKit.

Originally Posted by Doitsu

You're most likely wrong about eInk Kindles not using a Webkit based rendering engine, because when I applied the following style to a h3 header, it was rotated by minus 3 degrees on my PW2:

h3 {
    text-align: center;
    -webkit-transform: rotate(-3deg);
}

Therefore, it stands to reason that Kindles have a Webkit based rendering engine.
Can you please test the attached KindleGen generated .azw3 file on your Voyage?

Amazon does indeed use a Webkit-based KF8 rendering engine on E-Ink Kindles, at least last time anyone checked.
The gory details can be discussed in the Kindle Developer's Corner.

[AaronShep]

Originally Posted by kovidgoyal

@AaronShep: Are you saying the KFX files do not hyphenate unless you set -webkit-hyphens: auto in the book css?

Because, unless that is what you are saying, -webkit-hyphens cannot be used to deduce that KFX does not have soft hyphens. The default value of -webkit-hyphens is manual, which means the rendering engine will break only at soft hyphens. auto simply means it will break preferentially at soft hyphens and otherwise at calculated locations. See https://developer.mozilla.org/en/docs/Web/CSS/hyphens

Kovid, I'm saying that hyphenation is turned OFF (except for hard hyphens) for paragraphs where I've set -webkit-hyphens to manual. So, as you say, that indicates there are no soft hyphens -- though I hadn't really considered that before as evidence.

I'm NOT saying that WE have to set -webkit-hyphens to auto to turn hyphenation on. Unless we've previously turned it off ourselves, we don't, because it's the default for KFX. But how and where Amazon is adding that CSS, I don't know. It could be in a stylesheet, or it could be a modification within Webkit itself.

[Notjohn]

Originally Posted by AaronShep

Kovid, I'm saying that hyphenation is turned OFF (except for hard hyphens) for paragraphs where I've set -webkit-hyphens to manual. So, as you say, that indicates there are no soft hyphens -- though I hadn't really considered that before as evidence.

Must we put that instruction in every style (if we want no automagical hyphens)?

[kovidgoyal]

Interesting, good to know. Although since I assume that your test is that you create an epub file send it to amazon and then test the resulting KFX file. In which case it is possible that kfxgen sees that instruction and decides to skip inserting soft hyphens while generating the KFX. Still, that seems rather unlikely so your evidence certainly makes it more probable that KFX does not use soft hyphens. For which I am grateful, in a technical sense, but saddened in a political one -- since it seems there is no remaining technical justification for KFX, making it more likely that it is just a walled garden play.

[HarryT]

Originally Posted by kovidgoyal

For which I am grateful, in a technical sense, but saddened in a political one -- since it seems there is no remaining technical justification for KFX, making it more likely that it is just a walled garden play.

Do you not consider the delivery of image sizes customised for the resolution of the target device to be a valid technical justification?

[pdurrant]

Originally Posted by HarryT

Do you not consider the delivery of image sizes customised for the resolution of the target device to be a valid technical justification?

Not when that can be done so easily with the existing formats, since each is already customised for the individual device it's delivered to.

[HarryT]

Originally Posted by pdurrant

Not when that can be done so easily with the existing formats, since each is already customised for the individual device it's delivered to.

It's more logical to do as KFX does, though, by separating the images from the remainder of the book. That way there's a logical separation between the "fixed" and "device dependent" portions of the book, which makes a great deal of sense.

[pdurrant]

Originally Posted by HarryT

It's more logical to do as KFX does, though, by separating the images from the remainder of the book. That way there's a logical separation between the "fixed" and "device dependent" portions of the book, which makes a great deal of sense.

Amazon already do that sometimes with the azw3/azw6 split. A new format wasn't necessary for that.

[jhowell]

Originally Posted by HarryT

It's more logical to do as KFX does, though, by separating the images from the remainder of the book. That way there's a logical separation between the "fixed" and "device dependent" portions of the book, which makes a great deal of sense.

It is still not clear how much image customization by device is being done. I have only seen two variants, one grayscale and downrezed for e-ink and one full color and resolution for iOS apps and Fire tablets. And in all cases I have seen, comparing the same book between devices, all of the files that make up the KFX book are different sizes (and therefore have different content), not just the ones containing images. To me that eliminates the justification for splitting the images into separate files.

It is still not known whether the same book sent to a Voyage/PW3 would have different images from its PW2 counterpart. I wanted to test this, but no one was willing to help.

[Little.Egret]

Originally Posted by HarryT

But location numbers are related to file size, so if the file had become larger through adding additional information to it, one might reasonably expect the number of locations in the book to increase.

But if the file type that the Amazon server delivers to a device can be AZ3, KF8, KFX depending on device type nevertheless a location number must still refer to the same point ?

How is this done ?

[JSWolf]

I agree that there is no reason Amazon could not have had the different sized images in the existing KF8 format. I also agree that KFX is an attempt at yet another walled garden.

[Hitch]

Originally Posted by JSWolf

I agree that there is no reason Amazon could not have had the different sized images in the existing KF8 format. I also agree that KFX is an attempt at yet another walled garden.

Not to be a Zon-pologist, but let's face it: we don't yet know enough about KFX to know what we're talking about. For all we know, we may be looking at the advent of more-sophisticated media queries, surrounding images and/or typography. We don't KNOW. Therefore, we don't know if we're dealing with more "walled garden," or something that most of us actually want or that some of you have been asking for.

Just pointing out what I think is the obvious.

Hitch

[AaronShep]

Originally Posted by Notjohn

Must we put that instruction in every style (if we want no automagical hyphens)?

Notjohn, no, I've done the opposite. I put the instruction for no hyphens in the body tag, so that it applies to ALL styles. Then I turn hyphens back on for the few styles where I do want them. Those instructions go in the embedded CSS for each style in the document header or in the stylesheet. Since these instructions are more specific, they override the body tag instruction, even though they're read earlier.

Generally, I think hyphenation is a good idea for general text, especially when it's read in narrow columns like on a phone. But I don't want it for headings, tables of contents, verse, or a host of other specialized styles. The way I do it, it's off by default.

[AaronShep]

Originally Posted by kovidgoyal

Interesting, good to know. Although since I assume that your test is that you create an epub file send it to amazon and then test the resulting KFX file. In which case it is possible that kfxgen sees that instruction and decides to skip inserting soft hyphens while generating the KFX. Still, that seems rather unlikely so your evidence certainly makes it more probable that KFX does not use soft hyphens. For which I am grateful, in a technical sense, but saddened in a political one -- since it seems there is no remaining technical justification for KFX, making it more likely that it is just a walled garden play.

Kovid, my test is to submit new HTML files for books that are already listed with Enhanced Typesetting enabled. These files are immediately processed as KFX, no waiting. The next day, I ask Amazon to replace my purchased copy with the latest version, and that shows me the new file with the latest KFX processing. It's cumbersome, but it allows at least limited testing.

I think the reason for KFX is to be able to add and modify "secret sauce" ingredients and make them hard for competitors to copy -- though, so far, they've made a royal mess of it. I do like the new JPEG XR format. I have no doubt there are more changes coming, and they're just setting up the groundwork. And I also know they're working hard to get the bugs out.

[JSWolf]

Originally Posted by Hitch

Not to be a Zon-pologist, but let's face it: we don't yet know enough about KFX to know what we're talking about. For all we know, we may be looking at the advent of more-sophisticated media queries, surrounding images and/or typography. We don't KNOW. Therefore, we don't know if we're dealing with more "walled garden," or something that most of us actually want or that some of you have been asking for.

Just pointing out what I think is the obvious.

Hitch

If this was true, there's no reason it could not have been added the KF8. True, Amazon may be doing things we don't know about, but what we do know about could be done with KF8 instead of a new format.

Until we get more information saying that KF8 cannot do what Amazon is trying to do, then I'm still of the mind that KFX is an attempt to keep people living in a new walled garden.