I used KindleGen2 to convert some of my fixed layout EPUBs to mobi, and then I opened up the mobi files with mobi_unpack to see what had happened. (Well, I looked at them in the Kindle Fire too, and though they did open, I'm almost embarrassed to show you screenshots here. Certainly, not acceptable for sale.) So much for "easily portable with minimal effort".
Original on iPad:
After conversion with KindleGen2 on Kindle Fire, that single page is displayed on several:
So what happened inside? Mobi, from what I'm learning (just a beginner still), is a database, with no individual files, and thus no individual file names. mobi_unpack is a Python script that goes through the mobi database and generates what would be individual files from the data.
There are a couple of interesting things here. First, there are non-KF8 mobi files and KF8 mobi files. I'm guessing that's so your mobi file will work in both KF8 compatible devices as well as legacy ereaders. Second, the original EPUB is also included (shown at the bottom, in a zip file), completely unaltered, which presumably means it sits unaltered in the actual mobi file as well, and adds to its size. Finally, there is an EPUB file that is generated from the KF8 files which is a lot smaller than the original EPUB because KindleGen reduces the size of the images. The mobi_unpack script generates this standard-format file so that you can use it to create new versions of the book. It's not an Amazon thing.So, let's really look inside. The new specs say require a lot of things I don't see in the file that KindleGen2 created. My intepretation of that is that KindleGen2 doesn't create a fixed layout KF8 mobi from my fixed layout EPUB, it just creates a flowing KF8 mobi file.
But what if you create your own fixed layout file?
First of all, Amazon wants you to add a bunch of meta tags to the OPF file (and not to the com file, as Apple and Kobo do). These meta tags determine if the book is fixed layout, what the viewport size is, and in which orientation it should be locked, as well as what kind of book it is (for children?), and whether or not you're using "region magnification". The first three are required, which means that you can't have a book that can be viewed in both portrait and landscape modes. You have to choose.
Next, and most inexplicable of all, it says you should create a single page for pages in portrait mode, and a single HTML page for a two page spread in landscape mode. (Again, this necessitates completely redoing your original Fixed Layout book.) OK. What I completely don't understand is, if you're designing a two page spread in a single HTML page, why on earth do they want you to create it in two separate blocks that you then float next to each other? It seems like a lot of busy work.
Why not just create a single image on your single HTML page for the two page spread? Is there some benefit to dividing it up into two chunks of code on the single HTML page? I don't see it, if there is.
After much wrangling, I was able to manage to create a Fixed Layout in KF8 format and view it on the Kindle Fire. Here's the original on the iPad:
Here's what it looked like after I recoded it to work on the Kindle Fire. Note that the Javascript does not work but the link to Google Maps does. And you can't miss all that lost white space due to the letterboxing.
And let me tell you, it was a pain.
And led to my post from yesterday about aspect ratio (what timing, huh?) Because there was no way I was going to crop all of my pictures from that book so they would fit an entirely new aspect ratio, they simply would not have fit. Indeed, when I think of the way most people take pictures in 4:3, or similar, I consider the Kindle Fire's aspect ratio to be very problematic for the kind of books that might showcase photography in fixed layout. I'm not sure if kids' books are often found in an aspect ratio of 1.7, like the Kindle Fire.
So yeah, I'm disappointed. Just the same, I probably will get around to explaining how to do it all. And I promise more on regular flowing books for KF8 as well. Soon.
I also don't understand the need to break 2 page spreads into separate blocks, unless it is supposed to display in portrait as well at some point (which would be nice). I wonder if the eInk Kindles will be able to consume fixed layout KF8 when they are updated to support it. Maybe that's where the separate blocks will come into play. (eInk would be fine for B&W manga etc.).
ReplyDeleteYour observations about aspect ratio are pertinent. But fixed layout is fixed layout. I don't see how you can design for one aspect ratio and expect it to work just as well on another. Kobo and Apple may agree on the markup used, but you still face the aspect ratio issue, so you can't have one fixed layout ePub that works equally well on both.
1.7 is better for most video, 4:3 better for most photography. Kindle Fire (and Vox) are optimized for video. No doubt Greek philosophers would advocate something in between, i.e. the Golden Mean (1.61...).
You probably noticed that the Kindle Publishing Guidelines have a plug for your HTML/XHTML/CSS book. You gotta love 'em for that... :^)
ReplyDeleteThe other issue is that the spec, after the long and inexplicable delay in releasing it (while major publishers cranked out kf8 books week after week), is incomplete.
ReplyDeleteNo instructions on the additional code required to create comics or rundown on how to do "panel views."
Page 28 of the guide:
3.13 Authoring Fixed Layout Graphic Novels/Manga/Comics
Graphic Novels/Manga/Comics, while similar to Children’s books, require additional instructions which will be released shortly. If you are interested in publishing this type of content for Kindle, you'll find updated guidelines (when available) at www.amazon.com/kindleformat.
Can't say this is much of a surprise. If Amazon wanted the coding to work the same, they would have just adopted epub3. They want control. The moral is, do the coding by hand. Don't run your epub file through a meat grinder like KindleGen. Is it more work? Yes. But if you want to put out a quality product, get coding. It is what it is.
ReplyDeleteHi Dan:
DeleteI agree with your conclusion (we just have to code), but I want to note that Apple's Fixed Layout specs are no more a part of EPUB 3 than Amazon's. I think they're better and more robust, but they are not more "standard".
It is true, however, that there's not much point in running an Apple Fixed Layout through KindleGen in hopes of getting an Amazon Fixed Layout. It doesn't work. You have to code them all by hand.
I'm very disappointed by the total lack of pan and zoom with fixed format. My book, which is full of photography coupled with dense instructions on the book's subject, is completely unreadable without the ability to zoom.
ReplyDeleteI think what I really need is "Amazon Print Replica," but I haven't been able to find out how to publish that way.
Print replica is essentially PDF. It's not available on KDP, at least not currently. You can pan and zoom PDF (including any photos in the layout).
DeleteBut if you want pan and zoom, what's wrong with reflowable KF8 (or even mobi)? Why make your users read 'dense instructions' in a fixed text size?
The format of the pages, and the close proximity of the illustrations and photos to the instructions they pertain to, are important to the reader's experience.
DeleteI spent several days trying to format just one section as a reflowable epub. I even had several subject matter experts take it for a test drive. The overwhelming consensus was that it just didn't work in that format.
I am publishing it with Apple, as their fixed format allows for pan and zoom. This allows for the pages to retain the same format as the print book, and yet enlarge the section they are currently reading. The subject matter experts greatly preferred this version.
One lives and learns, and hopefully does better in the future.
Liz,
ReplyDeleteI too was so disappointed with KF8. But it appears hand coding is still the way to produce a quality piece. I hope for the day for Epub3 to be adopted across the board -- would make our lives so much easier.
I am looking forward to your insights on Fixed Layout for the Kindle. I really appreciate the help you provide -- it is truly invaluable. -- Thank you
I've been eagerly awaiting the release of the Kindle Panel Views documentation and it came out yesterday (at least that's when I noticed it). You'll find it in the guidelines.
ReplyDeleteThat said, it's still a massive pain to code KF8 books. And when you submit them to KDP and then download the preview to test it, it only downloads the MOBI without the fixed layout version, so you can't see if your layout is intact. I ended up having to publish without a preview so I can download the preview on my Kindle and see if it worked. If not, I'll yank it. Hardly the most professional way to go…
And thanks, Liz, for your fixed layout tutorials for iBooks EPUBs! I've released seven graphic novels on iBooks and they work great. And the most recent one is being revised to include a bonus documentary. :-D
ReplyDeleteMa'am there are so many resources about region magnification Kindle FL books but no information is available about RM for ePub!!
ReplyDeleteIs RM not possible in ePub?
If yes....then how?
It used to be automatic, that a simple double-click would result in magnification of the clicked on area. However, and unfortunately, Apple seems to have changed it recently. I'm investigating.
Delete'Used' ?!
DeleteOk. Thanks. I did not know that!
Means its still automatic on other devices?
No, meaning that in earlier versions of iBooks, a double-tap resulted in a zoom of the clicked area, and in the current version it only sometimes does.
DeleteSo should we publishers continue to write codes for FL for ePubs without taking responsibility for RM?
DeleteI don't have a definitive answer for you yet. I can tell you that there is currently no non-JavaScript way of controlling region magnification in EPUB, except that which is afforded by iBooks.
DeleteYes Ma'am that is the problem. Only iBooks detect JS.
DeleteThankYou so much for the helpful replies.
:)