Kindle Paperwhite 2-Voyage Software Update 5.6.5

[cvkemp]

Originally Posted by HarryT

Cannot be removed yet, just as it couldn't be removed from books with Adobe DRM a few years ago. The tools for doing this don't spring fully-formed from the brow of Zeus, they take time to develop.

That is for sure.

[Anthem]

Originally Posted by HarryT

The tools for doing this don't spring fully-formed from the brow of Zeus, they take time to develop.

Well, there goes my wonderful fantasy about how software development works!

[TimW]

Originally Posted by Anthem

Well, there goes my wonderful fantasy about how software development works!

The answer springing from Alf's brow like a fully armored Pallas Athena sounds like an even cooler fantasy to me. For what I know about software development, it's all mythology. Whatever works, I'm glad someone is clever enough to sort it.

[Rizla]

Originally Posted by HarryT

Cannot be removed yet, just as it couldn't be removed from books with Adobe DRM a few years ago. The tools for doing this don't spring fully-formed from the brow of Zeus, they take time to develop.

One must wonder why Amazon insisted on creating an entirely new and encoded file format when it had a perfectly functional format already. It certainly didn't need a new format to introduce new typographical features that would have functioned perfectly well with their old formats. What with the encoding of kfx, one can only come to the conclusion that the new format was introduced to increase control.

[eschwartz]

KFX does not automatically contain DRM, at least in the sense that books are bound to a user account or device. I would like to remind everyone that the following has been definitively proven:

A DRM-free (indie/TOR/etc.) book that has been downloaded as KFX can be read on any other Kindle which supports KFX, whether it is logged in or not.

It appears to be true that the format itself is obfuscated (a type of DRM), but seemingly in a uniform way across all KFX books. As such, I would think of that more as a file format than a DRM.




There is a fair chance that the DRM is not changed at all, we have no idea since no one has yet reverse-engineered KFX. (Nor have they done so for AZW6, which most people still don't realize exists...)
As HarryT said, wait a bit, and give it time. People are undoubtedly poking sticks at KFX as we speak, but these things take time. (Also consider, some people who would try to reverse-engineer the KFX format won't bother since they don't have a device capable of it.)
In the meantime, downoading via the browser is guaranteed to deliver a traditional MOBI/AZW3 which can be DeDRMed and/or converted.

[eschwartz]

Originally Posted by Rizla

One must wonder why Amazon insisted on creating an entirely new and encoded file format when it had a perfectly functional format already. It certainly didn't need a new format to introduce new typographical features that would have functioned perfectly well with their old formats. What with the encoding of kfx, one can only come to the conclusion that the new format was introduced to increase control.

MOBI was perfectly functional before they developed AZW3.

After sufficient poking, we now know what advantages AZW3 brings over MOBI, as well as exactly why a new format was crucial to the upgrade.



It is rather early to be pontificating about the redundancy of KFX, when for all we know it may do more than enable new typography.
And as already mentioned, processing the rendering information ahead of time on Amazon's servers in order to ease the load on the devices themselves, cannot be a bad thing, although one might debate how much value it actually brings.

[malligator]

Originally Posted by Rizla

One must wonder why Amazon insisted on creating an entirely new and encoded file format when it had a perfectly functional format already. It certainly didn't need a new format to introduce new typographical features that would have functioned perfectly well with their old formats. What with the encoding of kfx, one can only come to the conclusion that the new format was introduced to increase control.

Why must one wonder? One can wonder if they choose to, but there is absolutely no requirement that one must wonder about the underlying format of Kindle books. I have absolutely no idea what the format of my Kindle books are and I don't feel your (perceived) loss of control.

[tomsem]

Originally Posted by malligator

Why must one wonder? One can wonder if they choose to, but there is absolutely no requirement that one must wonder about the underlying format of Kindle books. I have absolutely no idea what the format of my Kindle books are and I don't feel your (perceived) loss of control.

I think most of the people who are concerned about this are using calibre to do various things, and this gets in the way. I only use calibre to manage and convert ePub files so I do not know all of the use cases that are affected when calibre is not able to understand 'kfx' files. I expect the situation is similar with Fire tablets, though there is no 'kfx' (or even prc) file there at all.

It appears that hyphenation is contingent on having soft hyphens inserted in the source before it is compiled to mobi. So you have been able to do that with calibre (using Hyphenate This! plugin) for awhile now, but Amazon has to go back and recompile existing content to do this (and maybe they can only do this if they have source files to work with). Likewise this is how they are 'normalizing' drop caps.

But kerning and ligatures should be rules that are declared in the font files themselves. My Paperwhite 1 doesn't do either, or maybe the font files on there have had these rules removed (noting that arabic and indic scripts require ligatures and these appear to render correctly). Meanwhile, the iPad app shows ligatures and kerning with all content, regardless of source. But on my Fire, I'm not seeing kerning or ligatures except with 'enhanced typography' content. So that's odd.

[DuckieTigger]

@tomsem: For arabic to work correctly on a Kindle you need KF8. Not sure if it requires ligatures to be hardcoded or not.

Only because a fontfile has kerning information and ligatures included doesn't mean the renderer that displays your text understands that.

[tomsem]

Originally Posted by DuckieTigger

@tomsem: For arabic to work correctly on a Kindle you need KF8. Not sure if it requires ligatures to be hardcoded or not.

Only because a fontfile has kerning information and ligatures included doesn't mean the renderer that displays your text understands that.

Right, KF8 is required for Arabic, not just for ligatures but for RTL display.

I'm just pointing out that the PW1 (and pre-'typography' update) renderer is capable of composing ligatures, but for whatever reason, does not (and apparently will never) compose them for English on that device. 'Crippled' font files is consistent with that behavior, but I am not claiming that is the only possible mechanism. In any case, it is kind of spooky behavior when compared to modern ePub renderers, which do this in their sleep.

Are there ebooks available here in mobi format that use embedded fonts? I'd like to do some experiments...

[HarryT]

Originally Posted by tomsem

I'm just pointing out that the PW1 (and pre-'typography' update) renderer is capable of composing ligatures, but for whatever reason, does not (and apparently will never) compose them for English on that device. 'Crippled' font files is consistent with that behavior, but I am not claiming that is the only possible mechanism. In any case, it is kind of spooky behavior when compared to modern ePub renderers, which do this in their sleep.

It's perhaps worth noting that ADE - by far the most common ePub renderer out there - doesn't support RTL languages at all, although the ePub standard does. Support for it is optional in ePub 2.

Are there ebooks available here in mobi format that use embedded fonts? I'd like to do some experiments...

The Mobi7 format does not support embedded fonts; for that you need KF8.

[tomsem]

Originally Posted by HarryT

It's perhaps worth noting that ADE - by far the most common ePub renderer out there - doesn't support RTL languages at all, although the ePub standard does. Support for it is optional in ePub 2.



The Mobi7 format does not support embedded fonts; for that you need KF8.

ADE 4 does support RTL, as does the current RMSDK. For ePub3.

I used 'mobi' in the sense of 'what kindlegen creates' (i.e., a file with a .mobi extension, with both mobi7 and kf8 segments). Sorry for the confusion.

[HarryT]

Originally Posted by tomsem

ADE 4 does support RTL, as does the current RMSDK.

This is true, but there are an awful lot of ePub devices out there - almost certainly the majority of them, in fact - that have older versions of the RMSDK that don't support RTL.

[JSWolf]

Originally Posted by HarryT

This is true, but there are an awful lot of ePub devices out there - almost certainly the majority of them, in fact - that have older versions of the RMSDK that don't support RTL.

Most Sony Readers have an older version RMSDK that will not support RTL. I'm not sure what version RMSDK the T3.

[Doitsu]

Originally Posted by tomsem

But kerning and ligatures should be rules that are declared in the font files themselves. My Paperwhite 1 doesn't do either, or maybe the font files on there have had these rules removed (noting that arabic and indic scripts require ligatures and these appear to render correctly).

5.6.5. firmware eInk Kindles display RTL text correctly in AZW3 files and files generated by KindleGen/Kindle Previewer.
However, they still don't display AZW3 Kindle books with embedded RTL fonts correctly: Arabic glyphs are being displayed as isolated forms and both Arabic and Hebrew vowel signs are being displayed next to letter instead of above or below them.
The Kindle for iOS app generally displays embedded fonts in AZK books fine, but has problems with some Arabic glyphs. (iBooks has the same bug.)

IMHO, the Kindle for Android app displays the embedded Arabic glyphs best.