That being said, it’s quite amazing to witness Kindle going from zero (mobi7) to hero (KFX) so quickly.
Kindle in Motion
Jiminy Panoz
192

Clarification since “hero” is quite a strong word there.

Notwithstanding the KFX architecture (basically, encrypted JSON fragments injected into iframes), what they are currently achieving is nothing short of spectacular if you’re a little bit familiar with Reading Systems’ long-standing limitations.

With enhanced typography, it was not just about drop caps, ligatures and hyphenation, much more important features were added at the same time:

  • their algo can determine if it is really a drop cap or anything else like, say, a raised cap;
  • drop caps are actually “smart caps”: they are perfectly aligned no matter what and, even better, removed when the font size hits a ceil as they would cripple legibility;
  • when the font size hits this ceil, floating images don’t float anymore (readability);
  • when the font size hits this ceil again, text is automatically aligned left (and not justified anymore);
  • a minimum contrast-ratio of 4.5:1 is enforced when there is a background-color (accessibility).

And now, it looks like they’ve achieved something super difficult, the “holy grail of the reflowable-eBook-as-is”: threaded frames with smart reflow (with anchored objects which position is relative to the spine).

It’s like one day they decided to typeset a book in InDesign, made a list of features and then started implementing the items they deemed important—BTW, something tells me they are working on page breaks.

It’s like CSS regions featuring CSS figures on an industrial scale, with good performance on mobile. And if you take a look at Google Play Books, which is somewhat conceptually-alike, you can see how difficult this is.

So difficult, as a matter of fact, that I was stating this in “Image Wizardry”…

Truth is you’d better add those divs depending on pagination and dimensions of the actual page; it should be in sync with the Reading System. As a bonus, you then would be able to keep the relationship between the figure and the text contents since the proof of concept is just about placing an image relative to the column/page.
Now, considering simple JavaScript to check overset is already a huge performance hog on a desktop, it should probably be managed at the RS level. But that would not solve performance hoggery, just move it higher in the food chain.

The funniest thing of all in this is that all of this was hidden in plain sight, in the Kindle Cloud Reader we didn’t pay attention to (hints: ipa = zip, renderer.min.js).

But then, it is closed tech and I kind of doubt we could use that as-is with HTML/CSS instead of JSON fragments.

To be honest, the idea of building a barebone paginator using CSS Regions (+ Adobe polyfill) and implementing float:top/bottom in it has grown on me this week-end. But I also know Regions are really tricky when it comes to performance…

So I’ll pass but I’m cool with it because if Kindle in Motions makes me want to achieve “InDesign in the browser”, it will probably inspire others, maybe people thinking outside the box. And quite frankly, we needed this.