MobileRead Forums - View Single Post

Tango Mike · 07-17-2012, 11:08 AM

I'm joining the conversation a little late, but reading the comments has raised a question. Please pardon me for a little background first.

I'm a do-it-yourselfer using a MacBook Pro with OS10.6.6, Photoshop Elements 8, Word 2008, Sigil 0.5.3, and Calibre 0.8.6. I use Adobe Digital Editions and Kindle for Mac to check my epub and mobi conversions. I know little or nothing about code, so I've used the point-and-click approach with lots of trial and error to publish three books for sale on Amazon, Barnes&Noble, Smashwords, and Apple's iBookstore. The new cover requirements driven by Apple and recently announced by Smashwords have me looking at my current workflow:

1. Build the book in Word, including a cover image as the first page and graphics for each chapter heading page and scene break.

2. Save as filtered html, open in Sigil, add the chapter breaks and generate the TOC.

3. Open the epub in Calibre and convert to mobi.

4. I upload the original doc file to Smashwords and the epub and mobi to Barnes&Noble and Amazon. I've uploaded one book directly to Apple and let Smashwords distribute the other two.

All my previous covers have been built on the 600x800 model (or close to it, depending on slight differences in requirements). After the Smashwords announcement, I researched the cover requirements for KDP and PubIt to see if they had changed. PubIt's appear to be the same, but KDP had confusing information and at least one direct contradiction. I sent them a message and received the following:

— TIFF (.tif/.tiff) or JPEG (.jpeg/.jpg) format
— 1000 pixels on the longest side accepted
— minimum 2500 pixels on the longest side recommended
— Ideal height/width ratio of 1.6
— 72 dpi limitation no longer applies and there is no restriction on the dpi
— 600x800 is recommended for images embedded within the content file
— they will be compressed to 127 KB during the conversion process
— this is not related to the catalog image you upload on KDP, which will be used as the thumbnail on the detail page of your book
— you don't have to embed the cover image within the content file, because during the conversion process, the catalog image you upload on KDP will automatically be resized and embedded in the very first page of the content file

I have just resized all of my covers to meet the new requirements and uploaded them successfully. I did not change the cover images embedded within the files, which are the original 600x800 versions. The average file size for these covers is about 500KB, which means that KDP has been resizing them to a maximum of 127KB all along.

I agree with the comments in this thread regarding a realistic view of the role a cover plays in an eBook. That said, if anyone takes the time to look, I'd like the viewer's screen to be the limiting factor rather than the quality of the image I provide. Including a cover image as the first page in the content file puts it in front of the reader at least once following purchase.

I'm doing this by inserting the image in the source doc file before saving as htm and opening in Sigil to save as an epub and then converting to mobi. This has always worked well, and I just finished converting a friend's doc file using a cover image that meets KDP's requirements almost exactly: 1572 x 2514 @ 300ppi (1.6 height to width ratio). When viewed in Adobe Digital Editions and Kindle for Mac, the cover looks terrific. But it's also a hefty 1.5MB.

As a test, I decided to embed this cover in the content file rather than let KDP resize the one uploaded for the thumbnail and the detail page of the book. I expect them to resize it to the maximum of 127KB. I don't know what PubIt, Smashwords and Apple will do with it, and that's one reason for conducting the test.

If you've stayed with me so far, here finally is the question: Ignoring for a moment the issue of whether readers pay any attention to covers once they've purchased the book, what is the downside of meeting the new requirements the way I've described? Does it fill an eReader with unnecessary data and slow it up or cause any other problems with rendering the book?

Thanks in advance for any viewpoints you care to offer.

07-17-2012, 11:08 AM	#16
Tango Mike Enthusiast Posts: 33 Karma: 20 Join Date: Jun 2011 Device: none	Dealing with the new cover requirements I'm joining the conversation a little late, but reading the comments has raised a question. Please pardon me for a little background first. I'm a do-it-yourselfer using a MacBook Pro with OS10.6.6, Photoshop Elements 8, Word 2008, Sigil 0.5.3, and Calibre 0.8.6. I use Adobe Digital Editions and Kindle for Mac to check my epub and mobi conversions. I know little or nothing about code, so I've used the point-and-click approach with lots of trial and error to publish three books for sale on Amazon, Barnes&Noble, Smashwords, and Apple's iBookstore. The new cover requirements driven by Apple and recently announced by Smashwords have me looking at my current workflow: 1. Build the book in Word, including a cover image as the first page and graphics for each chapter heading page and scene break. 2. Save as filtered html, open in Sigil, add the chapter breaks and generate the TOC. 3. Open the epub in Calibre and convert to mobi. 4. I upload the original doc file to Smashwords and the epub and mobi to Barnes&Noble and Amazon. I've uploaded one book directly to Apple and let Smashwords distribute the other two. All my previous covers have been built on the 600x800 model (or close to it, depending on slight differences in requirements). After the Smashwords announcement, I researched the cover requirements for KDP and PubIt to see if they had changed. PubIt's appear to be the same, but KDP had confusing information and at least one direct contradiction. I sent them a message and received the following: — TIFF (.tif/.tiff) or JPEG (.jpeg/.jpg) format — 1000 pixels on the longest side accepted — minimum 2500 pixels on the longest side recommended — Ideal height/width ratio of 1.6 — 72 dpi limitation no longer applies and there is no restriction on the dpi — 600x800 is recommended for images embedded within the content file — they will be compressed to 127 KB during the conversion process — this is not related to the catalog image you upload on KDP, which will be used as the thumbnail on the detail page of your book — you don't have to embed the cover image within the content file, because during the conversion process, the catalog image you upload on KDP will automatically be resized and embedded in the very first page of the content file I have just resized all of my covers to meet the new requirements and uploaded them successfully. I did not change the cover images embedded within the files, which are the original 600x800 versions. The average file size for these covers is about 500KB, which means that KDP has been resizing them to a maximum of 127KB all along. I agree with the comments in this thread regarding a realistic view of the role a cover plays in an eBook. That said, if anyone takes the time to look, I'd like the viewer's screen to be the limiting factor rather than the quality of the image I provide. Including a cover image as the first page in the content file puts it in front of the reader at least once following purchase. I'm doing this by inserting the image in the source doc file before saving as htm and opening in Sigil to save as an epub and then converting to mobi. This has always worked well, and I just finished converting a friend's doc file using a cover image that meets KDP's requirements almost exactly: 1572 x 2514 @ 300ppi (1.6 height to width ratio). When viewed in Adobe Digital Editions and Kindle for Mac, the cover looks terrific. But it's also a hefty 1.5MB. As a test, I decided to embed this cover in the content file rather than let KDP resize the one uploaded for the thumbnail and the detail page of the book. I expect them to resize it to the maximum of 127KB. I don't know what PubIt, Smashwords and Apple will do with it, and that's one reason for conducting the test. If you've stayed with me so far, here finally is the question: Ignoring for a moment the issue of whether readers pay any attention to covers once they've purchased the book, what is the downside of meeting the new requirements the way I've described? Does it fill an eReader with unnecessary data and slow it up or cause any other problems with rendering the book? Thanks in advance for any viewpoints you care to offer.