Placing images into ePubs has always been an issue. At the heart of the problem is the myriad ways that device and app manufacturers have programmed image handling. While Amazon have remained consistent with their sensible shrink-to-fit approach, ePub device and app programmers have been all over the map. And it is only getting worse. So bad, in fact, that I stopped providing conversion services for clients with image-laden ebooks. It’s not that the work is impossible, only that the work involved to optimize and test everything is not worth the money the typical indie author is willing to pay.
To give you an idea of how inane things have become, let me share with you what I went through trying to build the third edition of The Global Indie Author. The book makes use of 51 images of different shapes and sizes: 18 are definitively vertical, 23 are definitively horizontal, and the rest are squarish. Most are screenshots, used to illustrate steps in Word or Sigil, or the results displayed in Adobe Digital Editions or Kindle Previewer/Kindle for PC.
Screen Shots (and Other Small Images)
The screenshots were the first challenge. Such images are by their nature small: a Word dialogue box may be as small as 360 pixels wide, a screen shot of Kindle Previewer only 900 pixels high. While that was sufficient in the early days of ebooks, the advent of larger screens with dimensions of between 1920 and 2560 pixels high, and between 1080 and 1600 pixels wide, means those screenshots would display at their native size at less than 50% of the screen of these larger devices.
Thus, the first order of business was to upsize these images in a specialty program called Perfect Resize. While the results were acceptable, upsizing is never the best option. Publishers must now, whenever possible, start with a large image file (up to 2500 pixels on the long side). This makes producing software manuals and similar how-to books (like The Global Indie Author) that use screenshots increasingly difficult.
Large Images
Conversely, some of my custom images (and cover) were large; one image, for example, was 1600 x 2015 pixels, or 3,224,000 pixels, and 1.51MB. Although this put it well below the maximum recommended size of 3MB for Kobo, the pixel dimensions exceeded the 3.2 million pixels allowed by Apple. Thus I had to reduce many images to fall within Apple’s 3.2 million-pixel limit, which seems to be the lead that the app Aldiko is following: when I embedded my 5.2M-pixel cover in my ePub, Aldiko couldn’t display it even though the file size was under 2MB: all I got was an empty white screen.
What is particularly irritating about Apple’s image limit is that their new Retina screen requires 50% more pixels in the file than what is displayed on screen (it has to do with the way pixels are rendered on Retina screens). For example, if you want an image to display at 900 pixels high, you need to embed an image of 1350 pixels high.
Where this gets really stupid is that the Retina screen on the iPad Mini is 1536 x 2048 pixels, or ~3.15 million pixels, the limit for images embedded in an ebook sold on Apple. But since images must be 1.5x the display size, an image coded to display at 100% would need to be 2304 x 3072 pixels (less margins), or about 7 million pixels, more than twice the maximum allowed.
What that means is that images in your ePub will be upsized on a Retina display, and publishers have reported that such images look “mushy.”
[UPDATE: Apple now allow for 4M pixels in their ebooks. However, that is still well below the 7M pixels you ideally need for a Retina screen.]
Note, too, that with the advent of larger screens, and therefore larger image files, the old limit on image file size in ePubs — 260KB — has fallen by the wayside. If someone has a really, really old device, images larger than 260KB may not display, but the likelihood is low and that market share insignificant.
End of the SVG Wrapper
The next problem was also courtesy of Apple. In the early days of ebooks, the way around differences in image handling was a handy bit of perfect code called the SVG wrapper. In a nutshell, the wrapper allowed the ebook designer to force an image to fit on the screen regardless of the screen size, regardless of whether the image was vertical or horizontal, and regardless of whether the user was reading in portrait or landscape mode. The SVG wrapper also maintained the image ratio, preventing image distortion, and it also allowed the ebook designer to limit the pixel dimensions of the image when displayed; without that restriction, small images might be upsized by the device, which results in dreadful pixellation and image degradation.
Best of all, the SVG wrapper worked in pretty much every ePub device and app except Apple (and a few older Sony readers), where a bug caused images to split over two screens.
Rather than fix the bug, Apple outlawed the SVG wrapper. Publishers who wanted to distribute a single ePub file through an aggregator to the different retailers including Apple found themselves stripped of their best friend. It is also worth noting that Kobo (and others I suspect) also screwed us by programming their newer devices to ignore the SVG wrapper; instead, Kobo’s new large-screen devices upsize images to fit and subject them to an anti-aliasing filter. This filter removes the pixellation that degraded images in the past, but the downside is that the images then become noticeably softer. In all fairness the results are not bad for most photographs, but for image-centric ebooks where the photographs are the selling feature, or for text-based images, having one’s images noticeably softened sucks.
With the SVG wrapper now all but gone from the ebook designer’s arsenal, images have once again become a nightmare. If one simply embeds an image and adds no other coding to it, the result is that the image will display at its native dimensions in many ereaders and apps. This means that the large images you produced for the larger screens are now cut off (cropped) in smaller ones: a 600 x 800-pixel screen only displays approximately 15% of a 1500 x 2000-pixel image.
Using the Height Attribute For Vertical Images
The simplest way around this is to add a height attribute with a value of 100% to the img tag. For example:
<img alt="cover" height="100%" src="../Images/cover.jpg" />
This img attribute forces the image to be displayed at 100% of the screen height regardless of the screen size; this gets around the issue of images being cropped. Unfortunately, some devices and apps will not force the width to fit the screen while maintaining the image’s aspect ratio. This means that if your image is too wide to fit on the screen when the image height is 100%, either the aspect ratio is maintained but the sides of the image are cropped (e.g., in the app Aldiko), or the aspect ratio is ignored and the sides pushed in to fit, elongating the image (e.g., Kobo Arc).
Using the Width Attribute for Landscape Images
With landscape images, one can add a similar width attribute to the img tag:
<img alt="cover" src="../Images/cover.jpg" width="100%" />
Here, images are much less likely to be distorted because most users read in portrait mode. But rotate the screen and now the bottom of the image may be cropped if the image height exceeds the screen height, or the top and bottom sides of the image will be squished to fit, causing distortion. Now, one might argue that readers can just view the landscape images in portrait mode. But what if, like in The Global Indie Author, there are screenshots with text the user needs to read? Turning the screen to increase the image size is the only option.
Bear in mind, too, that if viewed on a computer screen, which is horizontal, some apps stretch width="100%" landscape images all the way across the screen; users must decrease the window size to view images properly.
No Dual Value
One cannot add both a width="100%" and a height="100%" attribute to the img tag because images are then stretched both ways if necessary to fit the screen.
The Auto Value
One can supposedly get around this problem and maintain the aspect ratio by using “auto” for the opposite attribute’s value:
<img alt="cover" height="100%" src="../Images/cover.jpg" width="auto" />
Unfortunately, many ePub devices and apps ignore the auto value and just behave as already illustrated.
Image Captions
The other problem with using the 100% value is if your images have captions. If the image is coded to be displayed at 100% of the screen height, then any caption is automatically pushed to the next screen.
What one can do here, then, is to decrease the image height. I have found that, for short captions, an image height of 85% usually leaves the image and caption together on the screen, at least in devices — some of the apps for PC that I tested ignored image attributes altogether, displaying all vertical images at 100% and therefore pushing all captions to the next screen.
With landscape images, whether or not the caption remains on the same screen depends on where the image falls on the screen. If the image sits at the top, no problem; but if the image falls after text and lands at the bottom of the screen, the caption will be pushed to the next screen. The only way to prevent this is to code your images so that they always have a page break before them, something that is often not ideal for images that serve to illustrate the text.
One theoretical workaround is to put your images in divisions, with the image and caption contained within the division; in your CSS you then put “page-break-inside:avoid” as an attribute of the division class. Unfortunately, none of the ePub apps and devices that I tested respected this attribute.
Square Images
This is where things become even more complicated. Should you code square images using the height attribute or the width? Logic would seem to dictate using the width attribute because most screens are rectangular: when viewed in portrait mode, square images would then not be cropped. But what I found was that, when viewed on my laptop in the Adobe Digital Editions app and Nook for PC app, many images had their bottoms or sides cropped, while the Kobo Arc displayed a distorted image. Rotating the screen compounded the problem.
I therefore switched to using the height attribute for many of the images, but of course they could not have a value of 100% because then a good chunk of the sides would be cropped or the images heavily squished in on the sides. In many cases even a value of 85% (to accommodate the caption) was insufficient to prevent cropping.
Using Pixel Dimensions
In the meantime, Kobo published their latest guidelines on GitHub. Regarding images, the guidelines state:
Image widths in the Cascading Style Sheets (CSS) should be set in pixels instead of percentages. Images with widths set by percentages may stretch in landscape orientation on tablets or other devices. Kobo reading platforms insert max-width and max-height CSS for images and video. This ensures they’re not split over multiple pages.
Now, this is in the CSS, not in the img tag, but either way if you set any dimensions to a fixed pixel value, older Kobo devices crop any images larger than the screen; if you set the pixel dimensions smaller to accommodate older readers, then the new readers display the image at those fixed dimensions when the user taps on the image (so instead of becoming larger, the image may become smaller). So I’m not sure how this is supposed to work, and my queries to Kobo went unanswered.
Solution
The solution, if one can call it that, was to look at the screen ratios of popular devices on the market, and to calculate a percentage for the height value that suited the dimensions of each individual image in The Global Indie Author.
For example, a device with a screen size of 728 x 1024 pixels has a screen ratio of 1:1.41. My Kindle Fire, with its 600 x 1024-pixel screen, has a ratio of 1:1.71 (and I run the Aldiko app for Android on my Fire). iPhones mostly have a ratio of 1:1.78, as do many Samsung Galaxy tablets. A ratio of 1:1.78 was the narrowest screen I found.
One of my images is 1600 x 1942 pixels and therefore has a ratio of 1:1.21. Taking the narrowest screen as my basis (because the narrower the screen, the bigger this problem of image cropping becomes), if I set a height value of 100%, approximately 32% of the image was cut off.
But if I took that same 1:1.78 ratio and reduced it by 5%, I could now fit an image with a ratio of 1:1.69. It followed thus:
- 95% = 1.69
- 90% = 1.60
- 85% = 1.51
- 80% = 1.42
- 75% = 1.34
- 70% = 1.25
- 65% = 1.16
Consequently, if I coded that 1600 x 1942-pixel image at height="65%" (1:1.16), the image (1:1.21) was no longer cropped in the ePub devices and apps that I tested.
However…
When I say “the ePub devices and apps that I tested,” I mean very few. I simply do not have the money to buy every ePub device on the market, or every Android device and the various ePub reading apps, both free and paid. And this is what author/publishers need to understand when they hire anyone to perform ebook conversions. Are you willing to pay what is necessary for ebook designers to buy all these devices to test your files on? Of course not. You want it cheap. And that is why the cheap designers are simply coding in height="100%" or width="100%" into the img tag and calling it a day. If your images get cropped or distorted, so be it. Most authors are not even aware of this problem, and so ebook designers take the ignorance-is-bliss approach to client care.
Apple (Again)
But then there is Apple. Again. Apple bugger us a second time (or is it third? I’ve lost count) by insisting that no attributes be added to the img tag. This has actually been going on for a few years now, the result of a bug in the iBooks app that causes any attribute in the img tag to be ignored (the anti-SVG wrapper dictum is related to the same bug). Instead of fixing the bug, Apple demand all images be placed in divisions, and then the divisions defined in the CSS. In Apple’s Asset Guide they provide the following example:
HTML:
<div class="image-container">
<img src="images/bears.jpg" alt="three bears peer at goldie locks"/>
</div>
CSS:
img {height: 100%;}
.image-container {height: 100vh;}
What this means is that if you need to reduce the size of any images, you have to create a class for each size. Oh, and by the way, that vh stands for viewport units, which is the newfangled way to say % in responsive design HTML. Of course, most ePub devices and apps other than Apple’s are not programmed to read viewport units, though Apple devices will read percentages. So why fix it if it ain’t broke?
Oh, and while you are at it, Apple would also like you to use media queries to accommodate the different screen sizes of their devices.
This Apple method is really just an image frame; it is the frame that keeps the image from being split over two screens. It is a workaround, not a fix. Worse, it assumes all images are vertical. When I created a container class for a horizontal image —
.image-container2 {width: 100%;}
— and put in a landscape image, the height:100% of the img class countermanded the container code, and I ended up with the landscape image ballooned up to 100% of the height of the screen and cropped.
The only way to have both landscape and portrait images in an Apple book, then, is to delete the img class in the CSS and create two different classes that can be applied to the img tag:
.vertical {height:100%;}
.horizon {width:100%;}
and add that to the code so that vertical images are placed in a vertical container and horizontal images are placed in a horizontal container:
<div class="image-container">
<img class="vertical" src="images/bears.jpg" alt="three bears peer at goldie locks"/>
</div>
<div class="image-container2">
<img class="horizon" src="images/bears.jpg" alt="three bears peer at goldie locks"/>
</div>
Bloody convoluted if you ask me. And all just so Apple don’t have to fix a bug.
Vendor-Specific Files
If you see in this nightmare a means by which device manufacturers (in particular Apple) are coercing publishers to produce vendor-specific files, you would be correct. And if you see in this nightmare a means for retailers to coerce consumers into buying from and reading on a single platform, you would also be correct. And if you also see in this nightmare a means for device manufacturers to coerce consumers into constantly upgrading their devices, you would get another prize.
Which Leads To…
Some aggregators are now producing — or claiming to produce — vendor-specific files. But before you buy, if your file has images, ask a lot of questions about how the aggregator is handling the issues raised in this blog post, and if they are willing to provide you with a copy of each distinct vendor file for you to test if so able.
For the indie author/publisher able to produce their own files, you can distribute a single file coded using Apple’s convoluted method of image handling, but test as much as you can on competitor devices and apps.
If you decide to produce vendor-specific files, the obstacle you face is finding an aggregator willing or able to accept multiple file submissions under the same ISBN. (And, technically, if you code the ebook differently it needs its own ISBN, but screw that: it’s enough that we have to use individual ISBNs for each basic format.) Right now I only know of one aggregator who accepts multiple files: INScribe Digital.
Which is why, in the end, I didn’t bother to produce a file for Apple: I had already built my ebook using the standard coding for all my 51 images, tested it, got it to work and look good, and the idea of doing the ebook all over again differently to accommodate Apple was a non-starter: past sales of The Global Indie Author on Apple simply did not warrant the work. I produced a Kindle book for Amazon and an ePub for Kobo. And called it a day.
Unfortunately, Apple iBooks does not read the height value in the img tag. Which is part of the problem. What is an obvious solution for almost all other ePubs does not work for Apple, which is deliberate on the part of Apple.
This is why they have the PRE element.
The simplest way around this is to add a height attribute with a value of 100% to the img tag. For example:
(By the way, those should all be straight quotes, but an “upgrade” to my WP site now turns all straight quotes into curly quotes. Drives me nuts.)
Unfortunately, Michelle, some of those “most popular design elements” do not show up in the oldest Kindles, so I’ve learned to design without them. Maybe In another five to ten years, the reason for that will disappear.
I know you can paste smart quotes into Sigil, but that’s exactly what I don’t want to have to do. I revise my ebooks frequently, and I want to just write and have the quotes automated. If I want straight quotes, I just copy and paste the code into Word from my text editor, and those quotes are not altered. I can also just turn off the feature long enough to enter the straight quotes, and they stay they same when I turn the setting back on.
I’m sure it’s nice to have an NCX table of contents, but as long as there’s a menu link to the HTML one, I don’t see that as essential. And anyway, the last time I checked, Amazon had started to add the NCX one to Kindle books automatically, based on HTML headings.
An essential point for me is, how long does it take to create the files? Not counting testing time, I can go from a Word source file to completed files for both Kindle and EPUB in two or three minutes. I don’t want to adopt any process that discourages me from revising as needed.
Calibre is a consumer program, not a production one. But if you turn off all its optional conversions, it does just fine for EPUB. The way I have it rigged, it produces files that pass epubcheck and all of Apple’s checks and work exactly as I intend. So, I really have no complaint. Again, my chief market is Kindle, so being able to easily produce EPUB files is really just a bonus.
Hi Aaron,
I’m no advanced coder. My books use very simple code, which is what I share with my readers in The Global Indie Author. And media queries for older Kindles is also incredibly simple, and also covered in my book. I always tell people that building an ebook is like baking: you don’t have to know chemistry to bake a cake, you just have to be able to follow the recipe. So in The Global Indie Author I provide the recipes for all the paragraph basics as well as the most popular design elements: cascading indents, text boxes, lines, drop caps, tables, images, image frames, and internal and external links.
You can use smart quotes in Sigil; it’s just not automated. When you export your Word document to HTML and import that into Sigil, it brings the smart quotes in with it. All Sigil does is translate the Windows-1252 encoding to UTF-8. If you later need to edit and add a smart quote, you just cut and paste from elsewhere in your document. It’s important NOT to automate smart quotes because then you cannot build books like The Global Indie Author where you need straight quotes to illustrate code. I have that exact problem with this WordPress site: at one point after the site was updated it began automating smart quotes that I cannot turn off. Now anytime I illustrate code on this blog I have to explain why the quotes are not straight. It drives me mad.
My technique is as simple as it gets: write in Word, export to HTML, import into Sigil, follow the steps to turn it into a proper ePub, then tweak a copy for Kindle and convert. Users need only a word processor, the free Sigil, and Kindlegen and Kindle Previewer. Uploading HTML to Amazon (or converting to mobi from HTML using Kindlegen) is simply bad practice because it does not produce an NCX TOC and ebooks benefit from one: the NCX file is not just a table of contents but a navigation tool, necessary, for example, for the device to add “page” markers for academic referencing. Amazon have been asking for the NCX TOC for years now because newer Kindles have page marker capabilities. So while Amazon still accept HTML files, they really don’t want them. And it is soooo easy to build both the NCX TOC and the HTML TOC (which links to the Go To menu item in Kindle books) in Sigil: not only can you edit both tables of content, but with the click of a button Sigil builds an HTML TOC from the NCX TOC, which is also automatically built using headings. Sigil is a wonderful program. Calibre is complicated and crap in comparison. It’s designed to be too many things and to create multiple files types; Sigil makes one file type and does it well.
Michelle, I purposely keep my designs simple so they can work well on Kindles of any age (including Kindle apps on older iPads). Yes, that does limit me in some ways, but I’ve found creative ways to do what I need within that context.
Another reason I’ve purposely limited myself is as research for my series of books on Kindle formatting, which are targeted to non-coders. I want to show how Kindle books can be produced with limited tools and technical expertise. And I can’t write about that effectively without doing it myself.
And a final reason is that my workflow, I believe, is the best suited to someone like me who is first and foremost a writer. I can keep my source file in Word, revise as much and as often as needed in code-less text, and generate a new set of ebook files within a few minutes.
By the way, I did consider Sigil long ago. But I couldn’t adopt a program that didn’t have an option for smart quotes. Book typography is very important to me, even in ebooks, and Sigil was squarely based on Web typography. I even contacted the developer, and he told me that adding such an option was not practical.
Calibre is quirky but treats source HTML very well if you know what options to turn OFF.
But I understand that a simple approach like mine might seem simplistic to an advanced coder like yourself. You can certainly do things with your approach that I can’t do with mine.
I agree with what you say about monopolies, which is one reason I’ve tried intermittently to support alternatives. But it always comes back to the same thing: I get no results. If people don’t want to buy my books elsewhere, I can’t force them.
Michelle, I’m sorry to keep starting new threads, but the Reply links seem to disappear after a few responses, so this is the only way I can see to continue.
I now compose all my ebooks as a single Word file, export to HTML, and tweak the code in a text editor. It’s tweaked first to be converted by Amazon’s KDP Previewer into both Mobi7 and KF8 for testing, as Amazon KDP will do when I later upload the same HTML. I make sure that all my books work more or less well on all models of Kindle, no matter hold old or new, and as a result, Amazon does not restrict their sale to certain Kindle models. No, I don’t use media queries, I just design so I don’t need them.
I then untweak the HTML file and retweak it for the Webkit brand of EPUB, to serve Google and Apple. (All this tweaking and retweaking is done with macros, so it literally takes only a few seconds.) Then the retweaked code is fed to calibre. With the settings I’ve worked out, it takes only a few seconds more to generate the EPUB file, and that file is tested too.
Besides software for testing, I have three physical Kindle models, an iPad, and an iPod Touch. I’m not happy until my books work on all of them. And with my systems now worked out, that usually doesn’t take long.
Your friend certainly does seem to have a different situation than mine, so I can see how a PDF would work for her.
Hi Aaron,
I have to say I’m a bit perplexed that you would still be uploading HTML to Amazon. For one, you cannot create a separate NCX TOC. Uploading HTML is kind of old school. Have you not tried Sigil? It’s wonderful and way better for building ePubs than Calibre; Calibre makes for very convoluted code.
I don’t see how you can design without media queries except to avoid KF8 formatting, or limiting it in such a way that the mobi7 display is tolerable. Often that really does not work well. I did a book for a client that contained a number of shaded text boxes (that were sidebars in the print version); this was a while ago and I had to use graphics to delineate the sections for mobi7. Later a new designer redid the book, removed the graphics but did not replace them in any way; now in the mobi7 version those sidebars look like new sections and don’t make any sense. Not good. It all comes down to how complex the ebook is. There is no one-size-fits-all, except for novels maybe.
It appears that you have chosen to restrict your market to Amazon and Apple. I don’t believe that is a healthy approach to the market. Feeding into monopolies, even if currently that is where the bulk of your sales are, is in the long run counterproductive. It just cements the monopolies. But that’s just my opinion.
Ahead of the curve is certainly where I try to stay, at least in books. 😉 If you check out any of my children’s picture books on Kindle, you’ll see they work on anything from a full-size iPad to an iPhone, without need for zooming. But that does require a complete redesign for an older book. Better yet is if you can plan for it from the start, as I do with new projects.
Kids may be using full-size tablets in school, but they’re not the ones buying picture books. Those are bought by parents and grandparents who will be reading to the kids, often while on the go. So, a PDF really won’t work for them.
Forgot to mention: this particular book is not a children’s picture book; it’s a children’s comic book. What is hot with the kids is the new CBR/CBZ format (which is just an image archive); the comic book apps designed for the CBR/CBZ format are also designed to read PDFs, which function in much the same way as the CB format: zoom and scroll. Many of these comic book apps are not designed to read ePubs or Kindle books, for obvious reasons: publishers like Marvel want out of Amazon and for consumers to buy directly from the publisher.
As I said, Aaron, this client is not selling a picture book; she is giving it away for free to schools. The schools are using tablets. And she’s not in a position to redesign the book from scratch, which has been part of the decision process.
A PDF will not work for everyone. That’s true and obvious. But it will work in this case. And the libraries are responding to consumer demand, and libraries are asking for PDFs again. I would suspect those patrons are reading on tablets.
You haven’t mentioned what format your responsive design books are in. Mobi8, obviously, if you are on Kindle. Are you also including media queries in your Kindle books, or ignoring the mobi7 market? And what about ePub? I would assume it’s ePub3. Correct? Or is it IBA?
I did a mock-up of KCC for my client; she hated it. Of interest, too, was that when she did a survey of the schools (which is where she intends to offer the book for free), the kids were overwhelmingly using iPads and Surface tablets. So while they might be using their mobile phones for a great deal of their own reading, in the schools they are using tablets. It all comes down to where your market is. And it again raises the issue of having to produce multiple formats to please all demographics. If you can only afford to make one format, the PDF is the only solution. Moreover, responsive design appears also to be device specific: Apple have asked for responsive design files but they want them coded specifically for Apple devices. If you’ve come up with a way to code responsive design to work across all devices and apps, then you are indeed way ahead of the curve.
Oh dear, now I find myself disagreeing again. 😉 I held out for fixed format for a long time, and I was probably the first author to use the Kindle Comic Creator to produce a children’s picture book, which I imported into the app as PDF. But since then, I’ve seen readers moving to narrower and smaller screens, including the Kindle Fires and smartphones in general.
There is just no way to make fixed format work on such a wide range of screen sizes. So, I’ve devoted myself to devising layouts that let me produce children’s picture books entirely in flowing text. (I discuss my strategies in my new book “Adventures in Writing for Children.”)
Anyone who works this out has a great advantage over the big publishers, who are still trying to fit their two-page spreads onto tiny screens. The concept of responsive layout has not yet come to the big publishers!
Michelle, I think we agree in our general disgust with the antics of major ebook vendors. I long for the days of print only, when words stayed on the page where you put them. 😉
Which is also why the return of the PDF is so sweet and somewhat ironic: the advent of all these high-resolution, large-screen devices simply means that one can design a 5″x8″ print book and export to PDF for digital (you’ll get around a 1500 x 2400-pixel PDF). I had to advise two clients recently on what to produce for distribution from their own websites: for one client, they could only afford to produce one format, and for their particular book (a comic book), the PDF was the logical conclusion: Adobe have made Acrobat free for all O/S including Android and Apple (and users can zoom and scroll on smaller devices), Apple iBooks can read PDFs, and Microsoft have their own free PDF reader in addition to Acrobat. The new CBZ/CBR format for comics is just more of the same nonsense, with the user either having to buy another app, or the app is ad supported, or it’s retailer integrated (so junior can spend on Mommy’s credit card). I was also surprised to hear from my aggregator that libraries are keen to buy PDFs and many of their clients prefer them. So we seem to be coming full circle, with readers longing for the lovely design of the print book but simply wanting it in the more portable digital format. The reflowable ebook may just find itself relegated to those with visual impairments.
For my ebooks, I simply use Sigil to build them in ePub2 using standards set out by the IDPF. Problem there, of course, is that Adobe sit on the IDPF development board. Just more crap to deal with. In any case, I use Sigil, my code passes ePubCheck, and that makes my distributor/retailers happy. I tweak the file to make it Kindle-specific and convert from that. Works for me. For images, I control them in the img tag for Kobo and upload that directly, and then replace the images and code for Kindle differently. If I were to make Apple happy I would have to code all the images differently again, which is why I never produced a file for Apple of the third edition of The Global Indie Author: too many pictures, too many hassles, not enough sales to justify the time. If it’s a novel and it only has the cover, then that one file coded for Apple can be used across most of the others, but to be frank I’ve had just about enough of the nonsense (which is why I will no longer build image-laden ebooks for clients). Device programming is the new DRM: it’s just another way to force consumers into a single ecosystem.
The logic is that I’m able to test ebooks for Apple and Google thoroughly enough that I’m confident they’ll do what I want. Also, they’re based on Webkit, so they’re generally good at following modern standards of HTML.
Nook and Kobo rely mostly on antiquated, proprietary Adobe ebook software, which is notoriously quirky and buggy, and I don’t have those devices to test on. (And I have a prejudice against that software because I’ve suffered from Adobe DRM, which basically works like a computer virus.) Also, both of those retailers are known to modify the files you send, so you can really never know what you’re going to get.
Before I realized what a problem all that was, I did try selling on both of them through Draft2Digital, but I hardly sold anything there anyway. So, it’s not worth my time or expense to make my books work for them. Of course, that might not be true for other publishers.
I’m mostly focused on Kindle, because that’s where my sales are. So, I haven’t taken the time to figure out why Apple’s documentation makes picture formatting seem so difficult. I only know that the simple code I use in my EPUBs tests perfectly on all the Apple apps and devices I’ve tried. But maybe that’s due to something right that I don’t realize I’m doing.
Aaron
Thanks, Michelle. The upsampling for Retina mode only applies to images that don’t have enough pixels already. If you create an image at the pixel width of the Retina screen, it is not upsampled — and in fact, there would be no physical way to do it.
Images are certainly anti-aliased as they’re upsampled. But as I said, you don’t see any mushiness as long as the resolution remains high. Try it and you’ll see.
I understand that Apple (together with Google) needs different coding, which is why I pulled out of Nook and Kobo. I’m not sure, though, what you meant about Apple not reading any values in the image tag. My CSS code for width and height is included directly in the image tag, and Apple definitely uses it. It also reads the standard width and height non-CSS attributes, but uses them in non-standard ways, so it’s best to leave them out. Again, try it and you’ll see. (I assume you’re not trying to publish to Apple devices without having at least one to test on.)
Aaron
Thanks for the interesting article, Michelle. It makes me glad I decided to restrict my EPUBs to Apple and Google (the two formats based on Webkit). But I do have some different thoughts that might prove helpful.
“What is particularly irritating about Apple’s image limit is that their new Retina screen requires 50% more pixels in the file than what is displayed on screen (it has to do with the way pixels are rendered on Retina screens). For example, if you want an image to display at 900 pixels high, you need to embed an image of 1350 pixels high.”
I believe you’ve misunderstood this. The reason for the 50% more pixels is to enable the reader to zoom in without loss of quality. It has nothing to do with the normal display of the picture. So, the current image size limit is always adequate for anything but zooming.
“What that means is that images in your ePub will be upsized on a Retina display, and publishers have reported that such images look “mushy.””
That’s only true about mushiness when you start with a low-resolution image. A high-resolution image can take quite a bit of expansion before looking soft. Just try to keep it from going lower than around 150-200 ppi. Anyway, as I said, the image is not necessarily upsized in the first place.
“Bloody convoluted if you ask me. And all just so Apple don’t have to fix a bug.”
In my tests on Mac, iPad, and iPod Touch, I’ve found that all that’s really needed is a width of 100%, a height of “auto,” and no attributes for pixel dimensions. This has worked perfectly for me without any kind of special wrapper (though I do always place my images in a normal p or div to control horizontal positioning and spacing before and after). If I need the image to be less than 100% width, I use the padding trick suggested in “Pictures on Kindle.”
Hope this helps.
Aaron
The iBooks Asset Guide states: “In Flowing books, images can be sized by adding dimensions to a container element that contains the image. The dimensions must be added to the container instead of the image element because iBooks defines the image’s dimensions to ensure that the image will always fit on a page, no matter the page size. It is recommended to size the container using viewport units to maintain adaptability for various screen sizes.” The code they recommend is in my post.
I have no doubt that Apple’s devices can read the image tag code. I think the above is nonsense, and just part of Apple’s push for Apple-specific files. It’s all about keeping readers in the Apple ecosystem. But the code they demand can also be read by other devices; one can just as easily code the way Apple wants and use that across most retailers.
Why would the fact that Apple and Google need different code cause you to pull out of Nook and Kobo? What is the logic in that?
Hi Aaron,
Thanks for your comments. With regards to Apple, the Retina screen uses smaller pixels–78 micrometers wide–which are then highly condensed in the high-resolution screen, which reduces the appearance of pixellation. According to Wikipedia, “When an Apple product has a Retina Display, each user interface widget is doubled in width and height to compensate for the smaller pixels. Apple calls this mode HiDPI mode.” Another site explains it is more simply: “The goal of Retina Display is to make it so that the pixels cannot be seen with the naked eye (using two screen pixels to represent one actual pixel, thus making each pixel too small to be noticeable).” Since the screen uses two physical pixels to represent one pixel of data, you need twice the data to display the image at the same size as a regular screen.
With low-resolution images in ebooks, some of the mushiness may be due to the use of an anti-aliasing filter on small images upsized in the device; Kobo devices now do this and I suspect Apple devices may be doing it too.
The height=”auto” value may work on Apple devices but it does not work on all devices. Hence the need to create Apple-specific files. Also, you cannot put the value in the img tag; Apple devices do not read any values in the img tag.