R. Scot Johns's Blog, page 4

iBooks Image Size Increased

Although they have not yet updated their iBooks Asset Guide to reflect the change, Apple has just announced an increase to the total pixel limit allowed for interior images in ebook files published through iTunes Connect, upgrading it from 3.2 to 4 million pixels.

This follows the increase in August of last year from 2 to 3.2 million pixels, and at long last brings the overall image size allowed more in line with the actual size of the device on which they are intended to be viewed.

The increase to 3.2 million from 2 million pixels was itself, of course, a long overdue attempt to address a contradiction in Apple's recommended image size as given in the iBooks Asset Guide. With a resolution of 2048 x 1536 since the 3rd generation iteration of the full-size iPad (giving it a total pixel count of 3,145,728), the long-standing limit of 2 million pixels was nowhere near enough to fill the screen with a full bleed image in portrait orientation, let alone to zoom in for greater detail, as the Asset Guide somewhat ironically recommends:

Apple recommends providing images that are at least 1.5 times the intended viewing size up to a maximum of 3.2 million pixels.

A quick bit of math will show that 1.5 times the standard iPad display resolution is 4,718,592 pixels. So while the new 4 million pixel limit does not provide for quite that much leeway, it gets us very nearly there, and at least allows for full bleed images that can be zoomed to some degree without completely losing fidelity. The official announcement for the newest update reads as follows:

Increased Pixel Limit for Book Images
The pixel limit for all images within a book has been increased to 4 million pixels. This limit does not apply to images delivered separately from the book, such as cover art or screenshots.

Amazon, of course, has also recently increased the allowed image size in Kindle ebooks (see post here), although they use an overall image file size in megabytes rather than a pixel dimension limit. This allows for a much higher image resolution to fill the bigger 2560 x 1600 HDX 8.9 device, which boasts over 4 million pixels, before zooming (4,096,000 to be precise). By comparison, that would require an image containing 6,144,000 pixels in order to zoom to 1.5 times without interpolation! This is why the individual image limit in Kindle files has been increased to 5 MB. Converted mobi files for upload to KDP, however, are limited to an overall file size of 650 MB, which puts something of a practical limitation on the included image files (130 5Mb files to be precise, which is admittedly more than ample for most projects).

Conversely, by employing a pixel limit, Apple are restricting the total image dimensions, but not the image quality itself, which can be embedded with no compression whatsoever, if so desired, up to a total ebook file size limit of 2 GB (which is a limit imposed by the zip format itself). So while the new 4 million pixel limit does not quite allow for full 1.5 times zooming with pixel-perfect accuracy, it does come very close, and the absence of a file size limit for individual images allows for the highest quality setting possible, which might be of great benefit for art books and photography collections (in case you want to see those brush strokes on the Mona Lisa, for example).

UPDATE: By the way, for those wanting to know, 2309 x 1732 would be the largest dimension image you can now insert into an iBooks file at the standard 4:3 aspect ratio of the iPad display. That gives you an image containing 3,999,188 pixels. Just one pixel bigger at 2310 x 1733 puts you over at 4,003,230 pixels. A nice round numbered 2300 x 1725 gives you an image with 3,967,500 pixels.

BISG Field Guide to Fixed Layout Update Errors

The Book Industry Study Group (BISG) this week released a revised edition of their Field Guide to Fixed Layout for Ebooks (Version 1.2), but it is still fraught with errors not fixed from the last edition, as well as adding new confusion via poor editing and worse research. You can download it for free from the link above (once you register for an account), which is worth doing, as it does contain some useful information in among the rest; you just have to know which is which.

A new section has been added, for example, called "Authoring Tools & Limitations" which, since Tools is plural, would presumably purport to outline a number of the primary applications currently in use for the production of fixed layout ebooks, such as iBooks Author, Jutoh, CircularFlo, MadeFire, or at the very least the two free programs offered by Amazon, Kindle Comic Creator and the Kindle Kids Book Creator. But in fact, the only tool actually discussed is InDesign CC's ePub export feature. No other program is discussed, or even mentioned. That said, the extensive list of InDesign's limitations is well worth a read, since it details exactly the reasons why I do not use InDesign for ebook production, nor recommend it, at least for the creation of Kindle fixed layout source files.

And on the topic of KF8, the following are just the primary errors to be found in the section on the Kindle fixed layout format...

1.) In the information regarding the Orientation Lock options (page 26, item #3), it states that none is a valid option, along with portrait and landscape, but then later contradicts this with a paragraph stating (incorrectly) that "you cannot have a book that can be viewed in both portrait and landscape modes," which of course, is exactly what the none value is for. Moreover, the statement that "Orientation is a required value" is only partly correct, since it is optional in comics, and only required for children's ebooks, but in either case can be set to none (which is, in fact, the default value). Granted, auto-orientation does not function on many Kindle devices, but it does on some, and it is the none value that allows for this.

2.) Item #4 states incorrectly that the values of the "Book Type" entity "can only be set to children or comic." Since this entity is optional, it can also be left out (or set to none), in either case of which the effects of the fixed layout functions vary greatly from those of either of the other two book-types. See my Fixed Layout Functionality Chart for specific details on this, if you have not already. There is good reason not to include either book-type.
3.) The last sentence on the bottom of page 26 cuts off mid-steam at the top of the following page, but seems to suggest that two-page spreads are possible only with the comic book-type. This is incorrect, since it works on some devices and not on others for both children's and comics, as well as those containing no book-type value (or a value of none), as can be seen in item #2 in the Fixed Layout Functionality Chart referenced above. However, the comic book-type does support two-page spreads more widely than either of the other two options, though not consistently. While I am sure it is beyond the scope of the Field Guide to provide these specifics, such universal statements as those given tend to be misleading, and are therefore less than helpful.
4.) The Region Magnification entity is irrelevant, since the value is set automatically by Kindlegen based on the presence or absence of region mag code in the converted file itself. The value will be set to the correct value regardless of what the content creator enters in the OPF - even, in fact, if no value or entity is added to the metadata at all. Therefore, there is little point in adding it manually, one way or the other.
5.) The statement that "KF8 fixed-layout format lacks pan and zoom" is incorrect. No, you cannot pinch and zoom pop-up regions, but you can pinch and zoom background images inserted using the <img src= > embedding method after double tapping the image (while those referenced via CSS div id's are locked). This is shown by Amazon's own Comics Sample file, which uses the unlocked insertion method almost exclusively. Moreover, pinch and zoom is a fundamental feature of the Virtual Panels function for KF8 comics that don't include any custom magnification regions: the pinch and zoom is automatically applied by Kindlegen without any active effort on the content creator's part. Refer to Item #4, Notes 6 & 7, on the Fixed Layout Functionality Chart for specific details on this.
This is just a sample of the errors and misleading information found in BISG's Field Guide. For this publication to be truly useful each of the sections and sub-sections provided needs to be greatly expanded, with detailed discussions of each specific topic, and the particular details pertaining to each platform and format, particularly if they actually expect readers to donate up to $50, as prompted by the "Pay What You Want" radio buttons on the download page. I'm not sure who in the publishing world would feel satisfied paying that much for so little rudimentary information when much more detailed data is available on blogs such as this for free. But it's your money, you can spend it as you like. I recommend the free option.

Kindle Publishing Guidelines 2014.2

Amazon has recently issued a revised edition of the Kindle Publishing Guidelines, bringing it to Version 2014.2. Although the changes are few, some are fairly significant, so I thought I'd post a quick rundown here.

According to the Revision Notes, there are five updated sections, plus one new addition:

I'll point out the changes to each section one by one.

• Updated 3.1.1 Text Guideline #1: Body Text Must Use Defaults

The first bullet point given heretofore in this this section has been removed:

• Body text must not have a forced alignment (such as left aligned or justified).

This section applies to reflowable ebooks, and the removal of this line presumably implies that forced alignments are now allowed, otherwise the prohibition would not have been removed. Forced alignments have actually been accepted previously, regardless of the restriction, but the rule has only now been officially expunged.

By the way, I've always thought the inclusion of the parenthetical "left aligned" was somewhat pointless, since left aligned is the default setting, and requires no forced alignment style. It should have read "right aligned" instead. But since it's been deleted I suppose the point is mute.

• Updated 3.2.2 Cover Image Guideline #2: Internal Content Cover Image Is Mandatory

Two sections of the previously existing code have been underlined, with the addition of the parenthetic statement that the

 (underlined elements are mandatory)

These two elements are contained in the OPF cover references, the first being the more recently added EPUB3 "properties" attribute for the cover image entry in the manifest (the new underlined elements have been highlighted below for the sake of clarity, although of course they're not in the Guidelines):

<item id="cimage" media-type="image/jpeg" href="other_cover.jpg" properties="cover-image"/>

The second is the standard Kindle metadata entry that's been used as long as mobi files have been in existence (so far as I recall, at any rate):

<meta name="cover" content="my-cover-image" />

This latter method has always been required in Kindle ebooks, while the former has been optional until now, since its additional a year or so ago. Note, however, that it is now a required element of the manifest entry for the cover image, if the EPUB3 cover reference method is employed. You only need enter one or the other, not both.

• Updated 3.2.3 Cover Image Guideline #3: Internal Cover Must Not Appear Twice

In the immediately following section a huge chunk of text has been removed, all of which provided for the one previously allowed exception in which an HTML cover might be included in a Kindle ebook along with the required cover image itself, as referenced above.

This removed section of text provided for a spine entry for the cover "page" using the mandatory linear="no" attribute (which has never worked correctly), and the epub:type="cover" Landmarks element or type="cover" Guide item attribute. All of this has now been rescinded, and the only remaining content in this section is explicit statement not to add a cover image in any other way than by simply referencing the cover image itself directly in the OPF.

For those of you who have read this blog awhile, or have studied my tutorials or formatting guidebook on the subject, you will know that I have long advocated against adding an HTML cover image, for the very reason that Amazon themselves have stated in this section of the Guidelines, which is that it causes the cover image to appear twice in the reader (and not might as the Guidelines state, but always, in every case on every Kindle device and app).

• Updated 3.6.1 Image Guideline #1: Use Supported Input Formats

A single line has been added to this section, which is clear enough:

Use RGB as the color profile when saving your files. Kindle does not support CMYK or sRGB.

Obviously the KDP ingestion system has been having issues lately with images employing incompatible color spaces. This provides the necessary clarification to correct the issue, so take heed.

• Updated 3.6.2 Image Guideline #2: KindleGen Performs Automatic Image Conversions

In this section a single word has been changed, which makes a world of difference:

The maximum size of an epub is 650 MB.

has been changed to:

The maximum size of a mobi is 650 MB.

Uh, yeah, that would make a big difference. This means that Kindlegen (and by extension KDP) can input epub source files larger than 650 MB (as I have already pointed out as functionally possible, both here and in the latest edition of my book), but that the resulting mobi file cannot be larger than that size, giving an upper file size limit to publishable Kindle files. Whether or not Kindlegen will, in fact, actually produce a mobi file bigger than that is unknown, as I've never attempted to produce one. But my guess is this is more a KDP restriction than an actual production limit.

• Added 3.10.9 HTML Guideline #9: File References Must Match Case and Spelling of Source

This is an entirely new section, which again apparently addresses some errant file production practices:

Per WC3 HTML standards, all file references (fonts, images, etc.) must match the case and spelling of the name of the source file exactly.

Again, the statement is clear enough that it requires no elaboration, except to say that it's unfortunate a statement such as this even needs to be made. But I suppose that's bound to happen when non-professionals attempt to produce professional level work, without first taking the time to learn the craft.

All in all this revision to the Guidelines is mostly for the sake of such technical clarifications as this, but the few alterations made to the standard rules are each important in their own way, and can in fact be quite significant in many cases.

Why I Don't Use eBook Creation Apps

Why I don't use ebook creation apps(but you might want to anyway) 
 Many years ago I built my first website, using Dreamweaver. It was Version 8, I believe, back when it was still by Macromedia. The website was very basic, the program very complex. It suited my needs at the time, and had plenty of potential for expansion...if I wanted to learn how to code a complex website, that is.I didn't.So instead, when it came time to add a store with shopping options for buying print and ebooks to my site I switched to Yahoo SiteBuilder, since Yahoo were the top web hosting service at the time, and offered a simple add-on shopping cart package (for a fee, of course). But since Yahoo used their own proprietary code for web page layout and functionality, I had to rebuild the site from scratch, being unable to import the current site and build on that. However, after much tedious effort (not to mention learning an entirely new software interface) it resulted in a nice website that filled my current needs...for a while.But web technology moved on and Yahoo did not. Eventually I wanted to upgrade my site to include some of the nifty new features made available by HTML5 and CSS3. But that could not be done in Yahoo.So I moved my site to another 3rd party web platform...and built it all again from scratch, since Yahoo's super secret code matrix could not be transferred to another platform.That new 3rd party service went out of business within a year (Yahoo has fared only slightly better treading water).So once again I started over and rebuilt the site from scratch (that's four for those keeping track). This time I decided to use the popular "open" platform Wordpress, with its highly customizable theme-based structure, thinking it would be more "universal," since there were seemingly endless theme and expansion packages available for it.But Wordpress proved to be slow and balky, crashing frequently and losing data with nearly every update. And because all but the basic layout functions are handled by adding third party plug-ins for each new feature, these tended to conflict with one other more often than not (not being tested for compatibility with anything but the base platform), causing features or entire sections of the site to malfunction (or not function at all), and crashing the site when any one of them were updated, even locking it up in a perpetual feedback loop on more than one occasion - a cycle which could only be broken by deleting one or more of the expansions, which naturally took all of my data with it.Moreover, due to the very nature of this "plug-in" methodology, the site was once again not exportable to any other platform. So yet again I was faced with the seemingly inevitable task of rebuilding my site from scratch.So after building the same site five times, I am now back to where I started, using Dreamweaver to build all my site content with universally recognized web code based on standard HTML and CSS. It is infinitely expandable, limited only by my time and willingness to learn, and can be transferred from one hosting service to another as I see fit. And it's the best site I've built yet. More importantly, the underlying code can be read and edited using any standard text editor. I can fix it if it breaks, and add new features as I learn to implement new code. If I see something I like on another website I can view the source code in my browser and see how it was done. I'm not limited by what the software can do, but what I can do.You might be asking yourself at this point what this has to do with ebooks.An ebook is, in essence, simply a portable website, designed as fixed or responsive page layouts, and based on a subset of the very same HTML and CSS that websites use. In general, if you know how to make a basic web page you can make an ebook too. You just need to learn the specific bits of code that makes the ebook work, and the rest is left to your imagination.And best of all, the only thing you really need is a text editor.The very same issues that plagued my web building experience for so many years also apply to building ebooks, so take heed. Programs that build your ebook for you do so by using their own proprietary code that often can't be understood by mere mortals such as we (unless you have the patience of a saint, or the wisdom of a god, which I do not). For example, they change the names of all your input source files, so that rather than having page23overlay2.jpg, you might find img000172.jpg instead, in your new HTML page called split0000159.xhtml. Good luck finding the correct file for page 23. Or the images it contains, if you happen to want to change one.This is made all the worse by the fact that all of your carefully labelled CSS entries will have been changed in just the same manner, so that your styling instructions for #page23panel1 is now called data-app-amzn-ke-created-style0126, or some such nonsense. And more than likely all of your neatly organized HTML will be run together in an endless stream of code. Needless to say, this is not helpful in the least.Unless you're a machine. And a very specific machine at that.This applies not just to Amazon's proprietary Comic and Kids ebook creator tools, but also in varying degrees to iBooks Author, InDesign's ebook export function, and ebook editors such as Calibre and Sigil. The code they create can only be effectively read by them, thus locking you into using that same platform for all future updates to that file, until such time as their usefulness runs out, they become incompatible with your now-outdated file (or operating system) after an update, another software offers better features, or the company goes out of business.Then you'll face the same dilemma I did building websites.You'll have to build your ebooks all over.From scratch.Again.
For more in-depth reviews of Amazon's Kindle Comic Creator and the newer Kindle Kids Book Creator (for those still intent on using them), follow those links to my posts on the subject. But don't say I didn't warn you.

Kindle Kids' Book Creator - An Analysis

Amazon today released something of a companion to their Kindle Comic Creator application that, like its predecessor, allows for relatively easy graphic layout of Kindle illustrated ebooks, this time geared toward producing children's content rather than comics. Like Kindle Comic Creator (KCC), the new Kindle Kids' Book Creator (or KBC for short) presents a very stripped down interface with a rather limited array of tools. However, this is somewhat deceptive, since users also have access (in both programs) to direct HTML/CSS editing within the application, which makes it useful both for those with some coding skills and those who only want a basic drag-and-drop style interface. For those without, however, the options for styling are somewhat slim, though they should suffice for most cases.

A companion User's Guide is available from the KKBC home page, which details in the usual sketchy technical outlines how to use the program, so I won't go through that here, but suffice it to say that the user guide isn't really necessary, since there's very little that you'll need to learn to use this thing, and most of it is fairly self-explanatory from a cursory glance at the menu bars and buttons; a half dozen random clicks will teach you all you need to know in fifteen minutes.

I ran a quick and dirty test to see how the program fared, and for the most part I was pleasantly surprised, although not without a healthy handful of caveats. Foremost of these right from the get-go is the lack of support for epub as an input source: KBC only accepts PDFs and image files, which means that if you have a nice layout to export from InDesign your only option is to make a PDF and start over from there. You can import pages with text embedded and create text pop-ups to cover them up, or import image-only pages and create both the base text and magnified text from scratch, and then move it around and size it all to fit. If you cut and paste text from another document any styles applied in the original will not transfer, since the underlying CSS will not be copied as well, but any tags you've added to the code still will be in the HTML, so you can manually add the CSS rules to the KBC file easily enough. This, of course, implies the need to delve into the underlying code, which somewhat defeats the point of using a program such as this. But that's the last we'll see of that necessity if you actually want to add some style to your work.

Unfortunately, even though you can add text as a separate layer in KBC, the "childrens" book-type that is automatically added to the output OPF renders the text inactive in the Kindle readers, so that dictionaries, highlights and word search will not work, rendering it essentially the same as text embedded in the image. This is why I discourage the use of a book-type value in fixed layout files as a general rule, but that's a choice each content creator must make for themselves. You can, however, delete the book-type entry from the OPF manually and all the text will then be active. Why Amazon has crippled this ability in children's books and comics is beyond me.

If you create the base text from scratch KBC will automatically add it to the pop-up at 150% magnification (if you add a pop-up, that is, since you don't have to), but you can "unlink" the pop-up from the base text and add any other content to the magnified region that you want. It will still be magnified at 150% of the base text, however, so if you simply want to have the base text change you'll have to learn to do some custom coding in the HTML/CSS editors to make it work (for example, if you want to produce a bi-lingual ebook, or use the pop-up like a question/answer flashcard). Unfortunately, KBC's behind-the-scenes code is a little balky, so unless you already know your way around a KF8 fixed layout file archive pretty well you'll be looking at a lot of gibberish, and even for those of us who do it's pretty messy in there. Also, to create clever tricks like using mag regions to replace one image with another isn't something that can easily by done in KBC. If you're wanting to add that kind of interactivity into your project, KBC is not the tool for you.

Other detracting factors against using KBC for anything but very simple projects are its lack of an Undo button (!), so you better be sure you want to make a change before you do, because there's no way to get it back once it is gone. You can "re-link" a base text box to a pop-up, but this deletes any other custom changes that you've made to the pop-up, replacing them with the default text, and that change cannot be undone, so whatever you had created will be lost. This is a horrendous oversight on the programmers' part, and truly unforgivable in this day and age.

Even though you import images of a given size (that you have no doubt chosen for a reason), KBC will automatically re-size them to a seemingly random dimension of its own choosing, over which you have no control. In my sample test file, for example, all my images were 1118 by 1788 in size. This was chosen as the largest size for which I could achieve the highest quality setting in Photoshop and still come in at just under the "standard resolution" image file size limits the Kindle has in place for older devices (which KBC apparently does not support - only the Fire devices are listed as supported, and available for previewing). At any rate, KBC arbitrarily assigned a landscape layout page size of 1920 wide by 1535 high for my test project, making each half page image only 959 by 1535 rather than 1118 by 1788. Curiously, however, the auto-generated "scaled-images" folder contained both the original, unchanged images, as well as "thumbnail" versions scaled to 625x1000 pixels and compressed to down around 100 kb in size, rendering them utterly atrocious in quality. Which ones the reader will see is anyone's guess, but since KBC files are apparently not compatible with the eInk devices (even though those devices do support fixed layout KF8 files) my guess is that the larger ones will be delivered to the Fire devices and the smaller ones to Android and iOS apps for phones. But I'm only guessing there, so don't quote me.

You can add single pages in portrait or landscape orientation, or two-page spreads in landscape using either two image stitched together or one image spanned across both pages. This is very nice feature made very easy during the image import stage. However, auto-orientation is unfortunately not an option here; you must choose one or the other. I should also mention that you can add or create additional pages at any point in the process, and insert them anywhere in the page sequence, and even re-sequence pages already added simply by dragging them to a new location. You can also delete pages, but once you do they are gone for good along with any content you included in them, and again this cannot be undone.

You cannot open mobi files that were not created using KBC, even if they're KF8 format children's book-type files. So KBC can import a PDF but not it's own native KF8 format. Go figure.

Above is a snapshot of the formatting toolbar available in KBC, and as you can see the options are somewhat limited. The "Add Pop-Up" button creates a mag region with no underlying text, while the "Add Text option creates both at one go. Just add your text to the base layer text box and it is automagically magnified at 150% in the pop-up box, both of which can be moved around and re-sized to your liking. You can embed custom fonts easily enough using an Add Font menu option, with any added fonts appearing in the drop down menu here. You can also change their size and color very easily here, which is a plus. There is also the slightly unexpected line height and character spacing options to help you make your text fill up the page just right, but be aware that these apply to all text in a single given text box and no others, so if you want all the text throughout the book to look the same you'll once again need to dive into the code and create a custom CSS rule for your base text. It's also not possible, of course, to only change the character spacing for just one line without embedding that line in a separate text box, thereby breaking any pop-up windows into pieces also.

Other than that you have the basic bold, italic, underline, and four standard text alignment options to choose from, and nothing else. There is no way to wrap text around images as in iBooks Author, or even to automatically align text boxes to a standard margin without resorting to advanced CSS editing. Text boxes can be moved and re-sized easily enough by dragging on their corners or edges, but there is no ruler or grid system by which to align them. Also, unless I'm blind I'm finding no color picker to alter the background color in the magnified text boxes, so again you'll need to learn some CSS to use this tool that Amazon is hyping in their promos as being designed for those who don't know any HTML or CSS, and theoretically don't need to learn. In other words, KBC is fairly dismal as a graphic design tool, and if you're used to using Adobe products or iBA for your layout work you'll feel as if you've been drugged and had your arms chopped off while trying to produce something genuinely inventive here.

There is a Console panel available that shows the log file which Kindlegen produces during conversion, but if you're advanced enough to understand that you don't need to be using this kid's toy. Honestly, I was hoping for an adult app at some point from Amazon that can create advanced layouts and complex motion graphics, but all they've given us so far are simple widgets only good for making very basic layouts. And that's probably good enough for beginners, but it's not something professional ebook formatters will ever use.

So to summarize:

PROS:
Easy user interface for a quick and simple learning curveEasily create magnified text pop-ups from base textText layers isolated from background art (for potential live text upgrades)Editable CSS/HTML code from within the programTwo-page spreads with facing pages made super simplePDF / image input for really simple import most users can manageGenerates the necessary file structure, including OPF & NCX, which can be edited externally
CONS:
No epub or mobi file inputCannot edit mobi files not originally created with KBCVery limited layout and formatting toolsOnly basic text interactivity (pop-ups) without advanced HTML/CSS coding skillsNo support for eInk devices (exports only to "Fire-compatible" KF8 according to the guide)Auto-Orientation not available (locked to landscape or portrait)Auto-resizes images without your input (cannot select your own "original-resolution" value)No Undo!Previews only available for Kindle Fire devices currentlyDid I say No Undo?

A few notes for the more advanced users:
There are a couple of new "ke-" prefixed entries in the metadata section of the OPF that are interesting:

<meta content="doublepagespread" name="ke-layout-type"/>
<meta content="start-right" name="ke-start-side"/>
<meta content="true" name="ke-hd-images"/>

The first is what allows two pages to be knit together into one page spread or a single image to be spanned across two pages, but I haven't had the chance to dive into the generated CSS to see what's being done just yet to know what all the options are, or why this is necessary when the KF8 code already has the ability to create facing pages from two images. In this case it's a two-page spread consisting of two individual images, so "doublepagespread" is the value. The value is for a two-page spread made from a single image is, not surprisingly, "singlepage".
Second up we have the "start-side" which for the first time allows a Kindle fixed layout file to have a single standing first page on the right side (or presumably left in rl-horizontal writing mode ebooks). Previously this was attempted with the page-id "layout-blank" value, which never worked correctly, and single pages always appeared centered in the viewport rather than to one side or the other.
Finally, we have an "hd-images" entity that I presume is part of the new "standard resolution" versus "high resolution" image distribution for old model versus HD devices. Here the value "true" tells me that only the HD images are going to be transferred to whatever device the file is destined for, regardless of the model. Or perhaps it means that only HD devices are supported for this file, as implied by the absence of any mention of eInk screens in the documentation. But if "false" is also a legitimate value for this entity it begs the question of just what the heck is going on here. Of course, each of these is generated automatically by KBC, so you really aren't intended to alter them outside of the settings found in the program menus, and there isn't one for this third entry. But here they are for what it's worth.
Incidentally, KBC only produces a toc.ncx rather than a nav doc with landmarks, and the OPF contains none of the EPUB3 additions that had previously been implemented in KF8.
Well, that's all I've got for now after a quick first look. I'll ponder on it more and maybe play with it a bit tomorrow. But I doubt I'll ever use it much, except for previewing my HTML/CSS code on the fly. And honestly, that's the best use I can see right now for this thing.

Kindle Kids' Book Creator Released

Amazon today released something of a companion to their Kindle Comic Creator application that, like its predecessor, allows for relatively easy graphic layout of Kindle illustrated ebooks, this time geared toward producing children's content rather than comics. Like Kindle Comic Creator (KCC), the new Kindle Kids' Book Creator (or KBC for short) presents a very stripped down interface with a rather limited array of tools. However, this is somewhat deceptive, since users also have access (in both programs) to direct HTML/CSS editing within the application, which makes it useful both for those with some coding skills and those who only want a basic drag-and-drop style interface. For those without, however, the options for styling are somewhat slim, though they should suffice for most cases.

A companion User's Guide is available from the KKBC home page, which details in the usual sketchy technical outlines how to use the program, so I won't go through that here, but suffice it to say that the user guide isn't really necessary, since there's very little that you'll need to learn, and most of it is fairly self-explanatory from a cursory glance at the menu bars and buttons (a half dozen random clicks will teach you most of what you need to know).

I ran a quick and dirty test to see how the program fared, and for the most part I was pleasantly surprised, although not without a healthy handful of caveats. Foremost of these right from the get-go is the lack of support for epub as an input source: KBC only accepts PDFs and image files, which means that if you have a nice layout to export from InDesign your only option is to make a PDF and start from there. You can import pages with text embedded and create text pop-ups to cover them up, or import image-only pages and create both the base text and magnified text from scratch. If you cut and paste text from another document any styles applied in the original will not transfer (although any tags you've added to the code will be, so you can manually add the CSS rules to the KBC file easily enough).

Unfortunately, even though you can add text as a separate layer in KBC, the "childrens" book-type that is automatically added to the output OPF renders the text inactive, so that dictionaries, highlights and word search will not work, rendering it essentially the same as text embedded in the image. This is why I discourage the use of a book-type value in fixed layout files as a general rule, but that's a choice each content creator must make for themselves.

If you create the base text from scratch KBC will automatically add it to the pop-up at 150% magnification (if you add one, that is), but you can "unlink" the pop-up from the base text and add any other content to the magnified region that you want. It will still be magnified at 150% of the base text, however, so if you simply want to have the base text change you'll have to learn to do some custom coding in the HTML/CSS editors to make it work. Unfortunately, KBC's behind-the-scenes code is a little balky, so unless you already know your way around a KF8 fixed layout file archive pretty well you'll be looking at a lot of gibberish. Also, to create clever tricks like using mag regions to replace one image with another isn't something that can easily by done in KBC. But then, if you're adding that kind of interactivity into your project, KBC is not the tool for you.

Other detracting factors against using KBC for anything but very simple projects are its lack of an Undo button (!), so you better be sure you want to make a change before you do, because there's no way to get it back. You can "re-link" a base text box to a pop-up, but again, this deletes any other changes that you've made to the pop-up, replacing them with the default text, and that change cannot be undone, so whatever you had done will be lost.

Even though you import images of a given size (that you have no doubt chosen for a reason), KBC will automatically re-size them to a seemingly random dimension of its own choosing, over which you have no control. In my sample test file, for example, all my images were 1118 by 1788 in size. This was chosen as the largest size for which I could achieve the highest quality setting in Photoshop and still come in at just under the "standard resolution" image file size limits the Kindle has in place for older devices (which KBC apparently does not support - only the Fire devices are listed as supported, and available for previewing). At any rate, KBC arbitrarily assigned a landscape layout page size of 1920 wide by 1535 high for my test project, making each half page image only 959 by 1535 rather than 1118 by 1788. Curiously, however, the auto-generated "scaled-images" folder contained both the original, unchanged images, as well as "thumbnail" versions scaled to 625x1000 pixels and compressed to down around 100 kb in size, rendering them atrociously horrible in quality. Which ones the reader will see is anyone's guess, but since KBC files are apparently not compatible with the eInk devices (even though those devices do support fixed layout KF8 files) my guess is that the larger ones will be delivered to the Fire devices and the smaller ones to Android and iOS apps.

You can add single pages in portrait or landscape orientation, or two-page spreads in landscape using either two image stitched together or one image spanned across both pages. This is very nice feature made very easy during the image import stage. However, auto-orientation is not an option here; you must choose one or the other. I should also mention that you can add or create additional pages at any point in the process, and insert them anywhere in the page sequence, and even re-sequence pages already added simply by dragging them to a new location. You can also delete pages, but once you do they are gone for good along with any content you included in them, and this cannot be undone either.

You cannot open mobi files that were not created using KBC, even if they're KF8 format children's book-type files. So KBC can import a PDF but not it's own native KF8 format. Go figure.

Above is a snapshot of the formatting toolbar available in KBC, and as you can see the options are somewhat slim. The "Add Pop-Up" button creates a mag region with no underlying text, while the "Add Text option creates both at one go. You can embed custom fonts easily using an Add Font menu option, with any added fonts appearing in the drop down menu here. You can also change their size and color very easily here, which is a plus. There is also the slightly unexpected line height and character spacing options to help you make your text fill up the page just right, but these apply to all text in a given text box and no others, so if you want all the text throughout the book to look the same you'll need to create a custom CSS rule for your base text. It's also not possible, of course, to only change the character spacing for only one line without embedding that line in a separate text box.

Other than that you have the basic bold, italic, underline, and four standard text alignment options to choose from, and nothing else. There is no way to wrap text around images as in iBooks Author, or even to automatically align text boxes to a standard margin without resorting to advanced CSS editing. Text boxes can be moved and re-sized easily enough by dragging on their corners or edges, but there is no ruler or grid system by which to align them. Also, unless I'm blind I'm finding no color picker to alter the background color in the magnified text boxes, so again you'll need to learn some CSS to use this tool that Amazon is hyping in their promos as being designed for those who don't know any HTML or CSS (and don't want to bother to learn). In other words, KBC is dismal as a graphic design tool, and if you're used to using Adobe products for your layout work you'll feel as if you've been drugged and had your arms chopped off while trying to produce something coherent here.

There is a Console panel available so you can see the log file that Kindlegen produces during conversion, but again, if you're advanced enough to understand that you don't need to be using this baby toy.

So to summarize:

PROS:
Easy user interface for a quick and simple learning curveEasily create magnified text pop-ups from base textText layers isolated from background art for potential future live text upgrade Editable CSS/HTML code from within the programTwo-page spreads with facing pages made super simplePDF / image input for really simple import
CONS:
No epub or mobi file input (!!!)Cannot edit mobi files not originally created with KBC"Simple" (i.e. lame) layout and formatting toolsOnly basic text interactivity without advanced coding skillsNo support for eInk devices (exports to KF8 only according to the guide)Auto-Orientation not availableAuto-resized imagesNo Undo!Previews only for Kindle Fire devices currently

A few notes for the more advanced users:
There are a couple of new "ke-" prefixed entries in the metadata section of the OPF that are interesting:

<meta content="doublepagespread" name="ke-layout-type"/>
<meta content="start-right" name="ke-start-side"/>
<meta content="true" name="ke-hd-images"/>

The first is what allows two pages to be knit together into one page spread or a single image to be spanned across two pages, but I haven't had the change to dive into the generated CSS to see what's being done just yet to know what all the options are, or why this is necessary when the KF8 code already has the ability to create facing pages from two images. In this case it's a two-page spread consisting of two individual images, so "doublepagespread" is the value. The value is for a two-page spread made from a single image is, not surprisingly, "singlepage".
Second up we have the "start-side" which for the first time allows a Kindle fixed layout file to have a single standing first page on the right side (or presumably left in rl-horizontal writing mode ebooks). Previously this was attempted with the page-id "layout-blank" value, which never worked correctly, and single pages always appeared centered in the viewport rather than to one side or the other.
Finally, we have an "hd-images" entity that I presume is part of the new "standard resolution" versus "high resolution" image distribution for old model versus HD devices. Here the value "true" tells me that only the HD images are going to be transferred to whatever device the file is destined for, regardless of the model. Or perhaps it means that only HD devices are supported for this file, as implied by the absence of any mention of eInk screens in the documentation. But if "false" is also a legitimate value for this entity it begs the question of just what the heck is going on here. Of course, each of these is generated automatically by KBC, so you really aren't intended to alter them outside of the settings found in the program menus. But here they are for what it's worth.
Curiously, KBC only produces a toc.ncx rather than a nav doc with landmarks, and the OPF contains none of the EPUB3 additions that had previously been implemented in KF8.
Well, that's all I've got for now after a quick first look. I'll ponder on it more and maybe play with it a bit tomorrow. But I doubt I'll ever use it much, except for previewing my HTML/CSS code on the fly. And honestly, that's the best use I can see right now for this thing.

"How To Make Kindle Comics" Update 2.0

A newly revised and updated "2.0" edition of "How To Make Kindle Comics & Children's Books" has just been published, with additional content and revisions to include the recent changes made by Amazon to the allowed image file size limits in Kindle fixed layout ebooks for HD devices, as well as other details uncovered during file testing since the first edition was released.

I have also taken the opportunity to make some editorial changes, textual polishing, and adjustments to the relevant charts and sections affected by these recent changes. Much of this has been documented on this blog, but it is now all housed together in the published guide.

In addition, an ePub edition is now included in the downloaded zip archive for no extra charge when purchased through my website (along with an updated PDF). The ePub and PDF are not available if bought through Amazon! However, the Kindle edition sold there has also been updated, so you should see an "update available" button for this title in the "Manage Your Content" page at Amazon (or you will as soon as they approve it, at any rate).

For those of you who have already purchased the book directly from my site, you can download the updated files via the link you received when purchased. If you no longer have that link, drop a line via the Contact page and I'll resend it. Be sure to include your full name and the email address you used when you bought the book.

The sample pdf download has also been updated, so for those who have not yet acquired a copy, you can click the "Read Sample" button on the product page (or just click that link) to read a 40+ page excerpt of the book.

Kindlegen "-dont_append_source" Option

I discovered this week that there is a command line option for Kindlegen that keeps the source file zip from being added to the compiled mobi archive. It was hidden in the Kindle Publishing Guidelines under the "Building Dictionaries" section (7.5), appearing first in Version 2014.1 back in January, and was not specifically listed in the Revision History, where it simply said "Dictionary Overview (and all subsections of same)." I went through that section, noting all the changes but this one. Go figure.

At any rate, if you add this option to your kindlegen command it will bypass the addition of the source file archive to your output file:

-dont_append_source

Kindlegen will output this message as the first line in the conversion log:

Info:I9018:option: -donotaddsource: Source files will not be added

I tested a fixed layout file to be sure it worked, and what I found was that a 19.6 Mb source epub which normally converts to a 44.9 Mb file, resulted in a 25.2 Mb mobi when appending this conversion option. Extracting the contents using KindleUnpack showed that the source zip file was indeed absent.

So for those who have been using KindleStrip to remove the bulky source files from your files, you can now just add this option during conversion instead. KindleStrip is no longer necessary.

Bear in mind, however, that with the larger image file size allowance, if you're including higher resolution images for HD devices that are over the standard definition limits (i.e. 127/256/800 kb), these source files may be required by Amazon in order to send them to the end user's HD device.

Kindle Image Size Test Results

I ran some further tests this morning to determine the effects of various image file sizes in different Kindle formats, on different Kindle devices. I did this in order to determine where the cutoff was for acceptable response, since the first test I did last week resulted in very sluggish behavior on the HD 8.9 device, which is the only one I tested then. I had also only tested a fixed layout file with the comic book-type on the actual device, so I did not know if these results applied to children's books or reflowable files as well.
For this test I created a jpeg image using a color gradient and pattern overlay in Photoshop to produce a range of sharp and soft edges across the spectrum, as well as an area of sharp black and white lines. Initially I made a file that was 4800 x 3000 pixels in size, since this is the largest image size recommended by Amazon in the Kindle Publishing Guidelines, in Section 5.2, where it deals with Zoom Factors.
However, I could not create a file at this size with this much color information at 100% quality that was under the 5Mb image limit. In fact, the file came in at 7.97 Mb, and even though it exceeds the limit by nearly 3 Mb, Kindlegen accepted it and did not abort. The resulting quality, of course, was horrible, even on the HD 8.9, and the image was clearly compressed to fit the limit. Moreover, after extracting the contents of the file, I discovered that Kindlegen will, in fact, actually reduce the dimensions of an image this size, even in a file with the comic book-type, contrary to my previous beliefs (though, of course, I had never tested an image file anywhere near this big, since it was not previously allowed). Therefore, apparently Kindlegen will no longer abort during conversion due to image file size, even when the image is bigger than the new limit.
I next created a new jpeg image file that was 3800 x 2376 in size and came it right at 5Mb with no compression applied (that is, a 100% quality factor in Photoshop). Images at this resolution did not have their dimensions altered by Kindlegen. From this image I then created a series of versions, each with successively more compression applied, right down to 10% "low" quality. These were the file size results:
100% - 5 Mb95% - 4.30 Mb90% - 3.8 Mb80% - 2.9 Mb "Very High Quality"70% - 2.4 Mb60% - 2.06 Mb "High Quality"50% - 1.39 Mb30% - 1.04 Mb "Medium Quality"10% - 807 Kb "Low Quality"
With these I produced a 10-page ebook (including a cover image using the 100% file, since this image is compressed differently than internal image files), with each page containing an image of greater compression than the one preceding it. I then created both a fixed layout "comic" and "childrens" book, as well as a reflowable file from this source archive. Total file sizes were 46.1 Mb, 44.7 Mb, and 40.3 Mb respectively. I tested each of these on the HD 8.9, HD 7, and the Kindle Fire 2. I did not bother with the eInk screens, whose image clarity is poor at best.
I should note here that Photoshop handled the compression of this image rather admirably, with "reasonably" acceptable results right down through the lower range, with minor amounts of blurring occurring from around 80%, and visible artifacting beginning at 60%, becoming plainly obvious at 30%, but never gravely intolerable (and I'm talking about a fairly small amount overall, visible only with close scrutiny). The quality of the images on the HD devices was, therefore, equally decent, with no overly glaring errors or corruption, even at the lowest level of 10%. But overall the images were vivid and pristine on the HD displays throughout upper quality levels, and quite good across the whole range. They would, of course, be even better with images of smaller dimensions, but I wanted to test the extreme limits of file size.
Ironically, on the standard resolution Fire these aberrations were less noticeable, due to an overall blurry appearance of the images at all levels, since on these devices the Kindlegen-compressed images are displayed rather than the full size hi-rez images, and thus they are all highly compressed (i.e. they all sucked more or less equally). The reflowable file was, of course, much less tolerable than the other two, with all images suffering from severe fuzziness and lack of crisp details. This is due to the fact that Kindlegen was forced to reduce the image dimensions down to around 575 x 920 (from 3800 x 2376) in order to achieve the 127 kb limit for reflowable files, requiring even the "low resolution" Fire screens to add back in additional pixel information that had been removed during conversion! Conversely, on the HD displays the reflowable file images were crisp and pristine, proving that the original resolution images were being displayed.
But this is nothing the average reader would likely even notice, aside from a general sense of mediocre presentation, as opposed to the sense of pristine clarity that comes across in hi-rez files on the HD screens. Without both devices sitting side by side for comparison the difference in detail would be far less obvious.
Of course, image quality was only part of what I was after here. This test was undertaken as much for the purpose of determining the effects of image file size on page load time. In my initial test last week the high resolution images I used caused the HD 8.9 to bog down to a crawl, but I did not know if this was due to the image size, dimensions, book-type, device, or combination of them all. So with the files I made today I loaded each one onto the devices mentioned above and swiped through the pages methodically, counting the seconds it took for each page to load, and then repeating it at least three times each, for each book-type on each device. Tedious, to say the least.
Interestingly, what I found was that in every instance - with the single exception of the comic book-type on the HD 8.9 - the results were more or less the same. The chart below shows the average load time in seconds, with the exception of the HD 8.9 comics in its own column:
File Size HD 8.9 Comics All OtherKindles 100% - 5Mb 5 2 95% - 4.3 Mb 5 2 90% - 3.8 Mb 5 1.5 80% - 2.9 Mb 5 1.5 70% - 2.4 Mb 4 1.5 60% - 2.06 Mb 4 1 50% - 1.39 Mb 4 1 30% - 1.04 Mb 4 1 10% - 807 Kb 3 1
As you can see, the load time more than doubles for the HD 8.9 device with the comic book-type, ranging from 3-5 seconds rather than the 1-2 second load time of all other instances. Moreover, response was buggy and caused the book to close unintentionally on numerous occasions. This is possibly due to the additional system feature of Virtual Panels that has to load with each page in comics, although this also occurs on the HD7 and Fire, just not at that resolution. But it is certainly not due to the image size itself, since this does not occur on that device with children's books or reflowable files that include the exact same images.
At any rate, from the chart you can see that in most cases the image load time is in the 1 second range with images of 2 Mb or less, while images from 2.4 to 3.8 Mb take slightly longer, and 4-5 Mb images requiring twice as long to load. For comics on the HD 8.9 there was a larger degree of variance throughout the tests, with more inconsistency in load times, but in general pages that contained an image larger than 2.4 Mb took on average a full 5 seconds to load - an excruciatingly long wait, during which time the device simply does nothing at all (on the HD 7, conversely, the page turns white and a circular "loading" icon appears, so that at least you know something is happening). The average dropped to an only slightly less annoying 4 seconds for 1-2 meg files, and only reached a 3 second best for the lowest quality image - one that only just exceeds the standard comic file size allowance of 800 kb!
Bear in mind, of course, that these are still also very large files in terms of image dimensions, so that regardless of the file size there is still an enormous amount of pixel data for the display to deal with. Moreover, these results will improve in time as processor speeds and onboard memory increase. But for now, as I've said on many occasions before, we have to deal with what we've got. My recommendation is to use much smaller dimensions (say, 2880 x 1800 max, which is 150% of the HD 8.9" resolution), and shoot for around 1.5 to 2 Mb for your largest image file size (and smaller if you can get away with it without compromising quality, bearing in mind overall file size and the subsequent delivery fees). And this all obviously only applies to images with a high degree of pixel information in them, such as complex maps and highly detailed artwork. Use your best judgement, of course, but be aware that a much higher degree of image quality is now possible on the Kindle than it ever has been before. Take advantage of it if you can. I, for one, look forward to seeing some truly beautiful artwork radiating from my HD Kindle screens.

Kindle Image File Size Increase Confirmed

After a lengthy wait, I finally received confirmation from Amazon this week regarding the increase in allowed image files sizes for Kindle ebooks listed in the newest version of the Kindle Publishing Guidelines, as discussed in recent posts.

While the image size limit is now stated to be 5 Mb per image, rather than the previous 128 kb for reflowable files and 256 or 800 kb for children's and comic fixed layouts respectively, there has been no official announcement from Amazon on the matter. Moreover, there has been no release of an update to Kindlegen that might incorporate this change, and files converted via Kindlegen or Previewer still compress the images to the previous levels, as revealed by extracting the contents using KindleUnpack.

How, then, is it possible for the higher 5 Mb image limit listed in the Guidelines to be true? Is this just a future upgrade waiting to be made? A simple typographic error? Or is there some unwritten information hidden between the lines?

In an email response to my query on the matter received this week, an Amazon rep said:

From Version 2.9 of Kindlegen, images up to 5MB are retained for High Definition devices. For Standard Definition devices, however, the images will be compressed.

The answer, then, is different images for different devices! In fact, Amazon has apparently been doing this for some time already without telling anyone. Since the converted mobi file contains both the compressed images and an untouched source file zip archive, Amazon is able to send alternate versions of each ebook to different devices, depending on their resolution.

Of course, I wanted to know for certain if, and how, this worked in practice, so I did some tests this morning to determine if it was, in fact, the case. To do this I created a fixed layout, comic book-type test file with 6 pages, each containing just one full page image, ranging in file size from 1.8 to 4.94 megabytes. This created a source file of 22.2 Mb in size, which Previewer converted into a mobi file of 48.6 megs. I also uploaded the source file to KDP, which resulted in a download preview file of an only slightly smaller 45.5 Mb. In addition, I tested variations with the children's book-type, and as a reflowable file, all of which resulted in visible artifacting in the compressed images when extracted. However, when these same files were side-loaded to my HD 8.9" Kindle, every image looked crystal clear, showing that the reading system was accessing not the compressed images, but the high definition source files instead!

Here is a screen-cap comparison of the high quality image file being rendered on the HD 8.9 (left) and the compression employed on the same image for the standard definition file (on the right):




The HD device is clearly accessing the uncompressed image from the source archive file, rather than the highly compressed version found in the mobi8 image folder. Now, bear in mind that this is a 128 kb image that has been compressed down from one nearly 5 mb in size, so an incredible amount of compression has occurred. Moreover, Kindlegen will shrink the actual resolution of the image in reflowable files and fixed layouts with the children's book-type, although not in ones with the comic book-type, so this comparison is between the two extremes and probably not a common occurrence. But you should know that this can happen, and is, in fact, happening to your ebooks already.

One more important note must be mentioned here with regard to including very high resolution images, which is that it severely bogged down the device response, causing delays in page turns, sluggish response to scrolling and zooming, and in general behaving in a most unpleasant way, much like the old days of eInk displays (oh, wait, they still have those, don't they!). What this means in practical terms is that, although you can now include very large images in your Kindle ebooks, you will want to carefully manage the ultimate file size at which each image can be delivered, since you can no longer assume Amazon will do this for you. If you include 5 Mb image files, they will now send those full size images to the end user's HD device, for good or ill.

Which brings me to my final point, and that concerns Amazon's delivery fees. One major concern with image file size increasing has been the prohibitive cost of a .15 cent per megabyte bandwidth charge incurred under the 70% royalty option, since a single 5 Mb image would therefore cost .75 cents to send! But surprisingly, this does not prove to be the case.

While the KDP preview file I downloaded today weighed in a 45.5 Mb, the "book size after conversion" listed on the product pricing page was only 3.36 Mb - the size Previewer's log listed as the "deliverable file size" after conversion. This makes the total download fee just .50 cents for the full size HD ebook, leaving $1.74 profit for a $2.99 list price title. Amazon has essentially decided to subsidize content for the HD devices by only charging for the lower file size. This makes perfect sense, since you cannot rightly charge the higher fee for files sent to lower resolution devices, and charging different rates for different devices is simply impractical (not to mention a bookkeeping nightmare). It's also probably why they haven't bothered to publicize this much. Or at all.