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:
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
• 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:
• 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:
• 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:
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.
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.
Published on October 29, 2014 18:57
No comments have been added yet.


