Archive for the ‘ Formatting ’ Category

Over the past three years or so since I first published my “Take Pride in your eBook Formatting” series of tutorials here on the site, a lot of people have asked if I would make the tutorials available as an eBook as well. For a number of reasons I never created an eBook on the subject, in part because I simply could not spare the time to put it together. If I wanted to release something like this as an eBook it would clearly have to be cleaned up and expanded upon in order to warrant any sort of price tag attached to it.

Well, over the past few weeks I took a look at the tutorials again and I have finally decided to create an eBook on the subject of eBook formatting. Since my tutorial series has become the de facto standard in the industry and is being used by countless authors to prepare their books for the market, I felt it was finally time to take it to the next level.

As I pointed out above, creating a mere reprint of the blog tutorials is not at all what I have in mind. Instead I have spend these past weeks reworking the instructions to give the entire process a clearer structure, but also to add many of the topics and elements that I did not touch upon in these tutorials. The tutorials were designed, really, to get people started, but with a book I feel it requires a lot more in-depth information to be of any value at all. It needs to be more complete, and as a result, the book will consist of a section with basic techniques that will get you to your first eBook, much the way the tutorials did, but in addition, the book will contain a section with advanced techniques in which I will describe how to achieve certain effects and how to handle certain formatting challenges that pop up every day, but require a bit more explanation and additional skill. Naturally, I am trying to keep it very accessible still to ensure readers can easily follow the instructions and examples.

Over the years I have seen many blogs that touch upon the subject of eBook formatting and some of the posts I came across were frightening—in the sense that they promoted techniques that are highly unsafe. While they achieved the goal for that particular individual, oftentimes the approach was nothing short of reckless, using very specific device capabilities without pointing out to the user that this behavior is not supported by other devices or that it can actually create unexpected behavior and lead to page corruption. Clearly, these authors never had the time to fully explore the techniques they were proposing, or didn’t have the foresight that their suggestion could create more problems than they actually solved.

In my book I have maintained my long-held stance that eBook compatibility is one of the highest priorities. The goal is to create eBooks that look good on any reader out there, whether it is a tiny cell phone or a large desktop computer. I am a professional eBook formatter (Click here for more information if you are interested in my services) and I have prepared more than 700 books for release in the market, by an enormously wide range of authors and styles. Of these 700 books not a single one has been known to cause formatting problems, clearly showing that with insight and forethought, it is possible to create eBooks that are compatible even in a market as fragmented as eBooks.

I am sure it won’t surprise you that many of the techniques outlined in my book will cover the subject of eBook formatting from that angle, offering up safe solutions, or, where no safe solutions are available, at least pointing out the risks and challenges and how they can be minimized by the formatter.

Filled with tips, tricks, techniques, examples, screenshots and plenty of code, the book will hopefully become a one-stop solution for all authors who want to dive in to the technical side of their eBook projects.


Would you like to use my services?

Need help with an eBook project? Check here for more information.

Do you need a cover for your book? Check here for more information.

In need of an author website or blog? Email me at for more information.

We are heading into year six of the digital book revolution and while there have been tremendous advancements in the sector, one thing has not changed a bit. There still is no magic bullet for eBook formatting. It’s not even anywhere on the horizon.

Dragonlance1In a time where eBook readers have become increasingly powerful and capable, and where more authors than ever put their content out in the market, one would think that formatting manuscripts to publish them as eBooks should be as trivial as exporting them from a word processor, but alas, that is not the case. Whether it’s releases from small indie authors or titles from major publishers, I continued to stumble across eBooks that are shoddy at best. Just a few months ago I was re-reading the Dragonlance Chronicles by Hickman/Weiss—a staple of high fantasy literature that has been in print for 30 years now, and yet, the eBook versions are an abomination in many ways. While it is evident that some work went into the books, they are nonetheless riddled with formatting errors that clearly show that no one at Wizards of the Coast took a single look at the books once they were formatted, let away read them before they went out the virtual door.

Is that truly the promise of the digital age? That we have to content ourselves with mediocre quality and sloppy presentations? It is just because it’s easy and cheap to produce and anyone with a computer can do it? Or is it because price points have come down so much, resulting in content creators and publishers no longer caring about the products the way they used to, because it’s all considered shovelware, anyway?

I’ve said it many times, but it is well worth repeating. The formatting of your eBook is every bit as important as your cover and your story. If your book becomes unreadable because line breaks are mutilated, margins jump all over the place, fonts get butchered, graphics become indistinguishable or errant page breaks destroy the flow, you are in trouble. I have put aside more than a handful of books after a few chapters because I found the reading experience too egregious — and I am sure that I am not the only one. (I remember vividly, the first one this ever happened to me was Charlie Courtland’s “Dandelions in the Garden,” for which I paid $9.99 on the Kindle and had to put down after two chapters because every single page was riddled with a multitude of typos, grammatical errors and formatting flaws-all of which the author herself considered a matter of personal taste and absolutely acceptable.)

Sure, the temptation is enormous as a writer. You have finally completed your book after a year’s worth of writing and—hopefully—tweaking, and without a publisher to hold you back for another year, you are eager to put your work out in the market, in the hands of readers. Nothing wrong with that. The problem really starts when you believe that the “Export as ePub” function in your word processor is your road to an instant release.

Kitt PirateWord processors are a great piece of software, but they are designed to write text and to do a bit of layout work, perhaps. All of it with your computer screen or a printed page in mind. Absolutely nothing in a word processor is designed for the requirements of eBooks. The famed “Export as ePub” function was nothing but an afterthought in that software, that has been included because someone thought it may help sell a few extra copies of the word processor or entice the growing army of aspiring digital authors to finally upgrade their software package.
eBooks have very specific requirements, capabilities and limitations, and they are not adequately represented by word processors. Things that look right on the screen or the printed page may not work the same way on an eBook reader.

While it is possible to create a good eBook with a word processor, it requires intimate familiarity with the software’s features. If, for example, you do not know what the difference between a soft and a hard line break is, let away how to create each, or if you do not know how to properly space text and paragraphs, the odds are, you won’t be able to create a solid eBook output. If you’re not familiar with your word processor’s style functions and are not religiously and obsessively using them, or if you do not know how to properly create an automatic bulleted list in your word processor, chances are that you are not ready to export your manuscript as an eBook using the “Export as ePub” feature. The list goes on like this.

I am not here to make you feel bad, because considering how complex word processors are these days, few of us truly master the software. But that’s not the point. You don’t have to, if you’re a writer. Your job is to write a cool story, pack it all up nicely in a suspenseful and engaging way that keeps readers glued to your words. Making sure it fits the technical limitations of an eBook reader is someone else’s job. Or rather, it should be. Someone with an understanding of the technical side of things, and with the ability to whip your writing into such shape that it works on any device. It’s a specialized field of expertise where the experience you purchase will save you countless hours of headache and will protect you from having to deal with potentially countless upset readers and customers.

It may be fulfilling to see your complex layout with text flowing around images and wonderfully elaborate drop cap initials on your iPad after exporting it as an ePub file from your word processor, but have you ever wondered, what the book may look like on another device? An early-generation Kindle, a Nook, perhaps, or the Kobo reader? What about a tiny cell phone or a retina computer retina display? Not all devices that people read your books on are equal. There are huge gaps in capabilities between various devices, and your software exporter cannot—and will not—accommodate them. It won’t even try. It will try to create what the programmer who wrote it deemed best, even if it means that in the real world you are leaving 90% of the market by the roadside.

Even within device families there are enormous capability differences. The Kindles, for example, by far the most popular eBook readers, range from a device that is barely capable of displaying an image (Kindle 1) to a full-blown tablet that can do virtually anything, including play games. Most Kindle devices have serious glitches and firmware bugs that got progressively worse with each generation. I made a blog post about the subject three years ago and it is frightening to see that Amazon never addressed as single one of these “10 Things Amazon should correct in the Kindle”. So, when you format an eBook, you definitely need to be mindful of these differences and idiosyncrasies at all times.

But back to even the general capabilities. Amazon for all the great stuff they’ve been doing for the eBook revolution, has completely dropped the ball on various fronts over the past years, clearly indicating that the company simply looks forward without ever trying to patch up previous mistakes. As a result there is no easy way to bridge these different capabilities in any workable way.

Ideally you would want the ability to create dedicated eBooks for devices with different capabilities, but sadly Amazon and every other distribution outlet does not allow for that. You have to have one build of your book that serves all devices. While Amazon allows a bit of conditional formatting, it is in reality very basic stuff that is so rudimental that it is mostly useless. Therefore you are forced to build your eBooks for a common denominator and you have to make sure it will work on all the devices out there.

No “Export to ePub” feature does that, which brings us back to the point that you should work with people who specialize on that kind of thing. As you may know, I have written an extensive eBook formatting tutorial some time ago, and I am offering eBook and print formatting as services. The truly amazing thing about the tutorial is that over time it has become the de facto standard for the industry and that that even now, four years after I wrote it, it is still valid and applicable in every single aspect. In a world where technology moves at such a rapid pace, it is clearly a testimony to the quality of the underlying fundamentals of the tutorial. Every book formatted following the tutorial still works on every device out there, and it is still the same general process I apply when formatting my clients’ eBooks.

On the IslandIf you would rather focus on your writing and leave the technical aspects of your ebooks to people like me, feel free to send me an email. I have formatted over 700 books, all of which are available in eBook stores worldwide, and many of them are full blown bestsellers selling hundreds of thousands of copies. And among these roughly 700 books, not a single one has caused any problems in the past!

If you want to make sure your readers are happy with the eBook you sold them, and if you want to make sure the books won’t be returned because of weird glitches or formatting errors, feel free to take a look at this page where I am outlining my services and my fees. I am happy to work with all sorts of authors and publishers, big and small, to make sure they can publish their books with confidence.

Forget about the promises of a magic bullet. It does not exist. Instead, take the proper steps to ensure the quality of your eBook from the inside out.

The announcement of the next generation of Amazon’s Kindle has set the eBook world abuzz once again. Not only are the new models more attractive than their predecessors, but they also expand the market in new, untapped territories. For authors, this is great news, of course, but often, where there’s light there’s also darkness.

Kindle PaperwhiteIn this case, the cloud on the horizon lies in the technical specs of these new devices. With a bit of worry I have observed over the past year or two that the eBook market is becoming more and more fragmented. In a very bad way, it reminds me of the mobile game space I have also been working in, where, at times, it was necessary for us to build up to 200 different versions of the same app to make sure it properly supports all the handsets in the market.

While the eBook market is not nearly as bad, of course, there is an increasing trend of changes – or call them features and improvements – that can work like sand in a ball bearing.

Fortunately we have to contend with only two generic eBook formats at this time – MOBI/KF8 and EPUB – and it is easy enough to build eBooks for both formats from the same sources.

However, since the inception of the iPad, problems have cropped up that force eBook publishers and formatters to think very hard about what it is they want to do and how to achieve the desired effect. Fixed-layout books and their particular quirks, and the lack of a general standard to create them, is just one of the issues publishers have to tackle these days, and it is exacerbated by the fact that even within the Kindle line of products, it is not possible to really create specialized builds for each platform. A fixed-format Kindle Fire eBook will inevitably make its way onto a regular Kindle – where it doesn’t belong – because Amazon does not give publishers the possibility to create specialized builds. As a result Kindle owners will look at a book that is horribly mangled and probably unreadable, while it looks mesmerizing on a Kindle Fire. I am not sure in whose best interest that is, but that’s the way Amazon does it.

The reason I am writing about this is because according to Amazon, the new Kindle Paperwhite line of models offers 65% more pixels. In plain English, it means it has a higher resolution than previous Kindles. That is really great news in regards to sharpness of the text, of course, but from a formatting standpoint it causes certain problems. An image that was perfectly sized for the Kindle’s 600-pixel resolution to date, will suddenly appear much, much smaller on the page. In many instances, this will not be overly dramatic, but if you use images deliberately as a design element, it will force you to rethink how you approach images in eBooks. Just image how tiny the image will look like when it’s being displayed on the new Kindle Fire HD with a resolution that is three times as wide as that of the original Kindle.


How would you like your artful chapter heading to look like?

In the past I have sized images to suit the 600 pixel screen. It helped keep the file size in bay – why bulk up a book’s footprint for no apparent reason, especially since the publisher is being charged for the delivery of the book based on the size of the file. This approach may no longer work, however, if you want high quality images across the board.

I’ve been therefore rethinking my strategy and going forward I am sizing images to a higher resolution and then determine their on-screen size, using scaling through my CSS style sheet. This allows me to make sure the image will always appear the same on the display, without degrading it on higher resolution screens. If anything, it may degrade the quality scaling images down to the older Kindle models.

If Amazon offered platform specific builds for their line of Kindles, this would not be a problem, but things being what they are, a one-size-fits-all approach is necessary, and hopefully, this will do the job.

In many ways, I wish that Amazon would make me part of their Kindle design team or at least would allow me to work with them. After all, I’ve had over 35 years of experience as a software engineer in arenas that were a whole lot more complex than an eBook reader.

Many of you may remember my post 10 Things Amazon should correct in the Kindle from a year ago, and it is rather disheartening to see that virtually none of these issues have been addressed. In fact, if you look closely, not a single one of the issues has been addressed to date. While I have not seen a Kindle Paperwhite at this time, I doubt there will be many changes in the firmware that would address these issues. It seems to be more of a change in terms of the form factor and a hardware upgrade than a rework of the actual reader implementation – but I could be wrong, of course.

To me as a software engineer, author, publisher and professional eBook formatter, the omissions are truly painful to behold. amazon has done great things for books, by truly establishing eBooks as a reading medium, making it the new mainstream standard, all the while opening the doors for authors to publish their own work. All great achievements and I honestly doff my hat to Amazon for their incredible foresight and the vision they had during the past three years.

That, however, makes the technical shortsightedness all the more prevalent. All of the issues I raised before have been around since day one, and clearly someone within Amazon should have championed their correction. It did not happen. Not even when people like myself and others have called them out.

Amazon has never been a software or hardware developer before the Kindle and as such it was to be expected that there would be hiccups in the product and the delivery. No big deal. However, the market has reached such a maturity, that glitches like inconsistent text justification, the lack of transparency in PNG images and other omissions become glaring issues that should have been resolved two years ago.

The Kindle has to mature and it has to mature with foresight or we are gong down the road of mobile games, where you need 200 individual builds of an app. There are great developers out there who would have been happy to assist Amazon in their objective, but instead of embracing them, Amazon has often shunted them.

A command-line MOBIGEN program is just not the same as the luxury you get out of a program like Calibre. Amazon should have long looked into creating high quality content creation tools that help authors to increase the quality of their output. Too many self-published books are still created with an MS Word export or an InDesign plug-in that cause more problems than they solve.

Amazon should also have long started to put in place platform-specific delivery of eBooks, along with was for authors to properly set up books for each of these platforms.

Amazon should also have expanded their eBook format in ways that are truly practical without having to jump through hoops. The introduction of KF8 was a horrid debacle to say the least. Confusing authors and readers alike, the implementation is not what it should be – many things could have been implemented much more efficiently, making it easier for formatters to prepare the eBooks while also giving them a certain level of control over the appearance of their content. If you’ve ever tried to take a look at a black and white line-art image in the “Night” setting of your Kindle, you know what I mean, and the whole image sizing issue puts the dot on the i, I think.

I don’t want to harp on this unnecessarily excessively, but it also appears as if Amazon has long forgotten its pledge to bring KF8 support to the Kindle 3 generation of devices. As far as I can tell, that has never happened either, and yet, the train of model innovation moves on…

With all the new glitz and glamour that accompanies every new Kindle model, for publishers, each new generation brings with it a new set of challenges. It’s not necessarily a bad thing, but as I said, I wish Amazon would allow me to work with them to help them make these transitions as easy as possible, at least from a content creation standpoint. If anyone from Amazon is reading this, you know where to find me…

I’ve been working my way through Amazon’s new KF8 format specs a little bit, and while it is a great format, taking the Kindle eBook format to where EPUB has been for some time, I have to say there are a few things that stick out like a sore thumb.

One of the issues that truly and really disturb me is the lack of support on anything but the Kindle Fire. Although Amazon had initially announced that the current generation Kindles and software readers would be KF8 capable, that statement was simply not true. It has since been revised that these devices will support KF8 some time in the future. In the real world that is a big difference.

It means that if you’re using KF8, you are currently limiting yourself to the Kindle Fire platform. While it is clearly a successful platform, it is nonetheless a niche.

The other thing that sorely disturbed me is the fact that Amazon is in no real way accommodating MOBI alongside KF8. By this I mean that Amazon is not willing to allow you to upload a KF8 version of a book and a MOBI version of the same book in order to enable proper support for all their Kindles. This problem extends not only into the publishing platform but actually starts at the root, the authoring of eBook.

Although with the new tools, Amazon has set up media queries, using an HTML @-rule, which allows you to define different styles for the KF8 and MOBI builds generated from your submission file, it is sadly a rather mediocre solution. It does help, however, in some cases. If you want text to flow around an image, a feature the KF8 format finally supports, you can tell it to use a different style setting for the MOBI version, in which you could center the image and then force a line-break and start the text on the next line. In theory, this would work. The problem seems to be that the old Kindles do not understand the display: block property that would be necessary to enforce the line break. Unless I find some way to tell the old Kindle that it needs to perform a line break after an image, this media-query fix is useless in this case.

The same is true with tables. Old Kindles have no table support. It’s been a major problem in the past, as it makes tabulating information impossible. If you display a KF8 table on an old Kindle it will be flattened, which means every table column will appear in a separate line. From a technical standpoint it makes sense because it is the easiest way to parse a table without actually implementing support. In practice it defeats its purpose, because it completely mangles and intermingles data that should, by rights, be separated — hence the use of a table.

Sadly the newfangled media queries won’t help in this case either, because the only real substitutes for tables on old Kindles are either completely restructured data, which requires different structural code and cannot be managed using a style, or you could replace the table with an image, which also requires code and cannot be achieved via a style setting. Ergo, the media query once again misses the mark.

Nonetheless, the media queries are great and will help on occasion to allow a certain degree of “correction” between versions. At least it’s a try…

In my opinion, however, Amazon should allow publishers to upload separate KF8 and MOBI versions in the future. It would be the only way to make sure that both versions can be authored to the best of the respective format’s capabilities and look as best as they can. Trying to automate the process – even with a media query hint has never been a good idea. The Smashwords Meat Grinder is the living proof that this Least Common Denominator approach is getting you nowhere but in trouble, and therefore I sincerely hope that Amazon will rethink their strategy in that respect, and while they’re at it, maybe they should look at their documentation also and rework the CSS selector listing they have in there, because as it stand, it would lead you to believe that old Kindles can’t handle any CSS, as every single selector is marked off as “unsupported.”

I wonder if they have actually corrected some of the issues I raised a while ago in the new platforms, such as incorrect em calculation, the right margin and padding issues, the missing borders, and so forth. Maybe some of you reader can enlighten me on that, since I have no Kindle Fire and none of the latest Kindles at my disposal.

Yesterday, Amazon released information that with the introduction of the Kindle Fire tablet they will also switch to a new eBook format. Anyone who will check out the quick overview will certainly be pleased and also notice that with the upcoming KF8 eBook format, Amazon seems to have addressed virtually all the shortcomings I have raised in my blog post 10 Things Amazon should correct in the Kindle that I posted a while ago.

And yet, I am not happy. Why is that?

One would think with these issues out of the way, the Kindle should finally catapult itself to the top of the eBook capabilities, right? Well, yes and no. The problem lies in the details, the fineprint, so to speak. The big problem with the introduction of the KF8 format is that Amazon is doing a pretty hack job with this, I am very sorry to say, because, according to Amazon’s announcement and FAQ, none of the older Kindles will be able to support this format.

Why is this a problem? Well, as a professional eBook formatter, the question for me is, how am I supposed to deal with this? Instead of creating the foundation for one rock solid Kindle platform that has powerful capabilities, Amazon is now going down the road of platform fragmentation. Already we had issues that the Kindle 2 and Kindle 3 had capabilities the Kindle 1 did not possess. It was a big problem because things such as tables were unusable, despite the fact that the capabilities were built into the K2 and K3. Since authors have to make sure they cover the largest possible market share, however, using tables made no sense, as the Kindle 1 did not support them and rendered them in a useless, garbled fashion.

With KF8, things will get even uglier. We now have three different sets of capabilities. The Kindle 1 at the bottom end, the Kindle 2 and Kindle 3, and then the new Kindle 4 and Kindle Fire. This is not a smart move on Amazon’s behalf and reeks of either laziness or engineering ineptitude.

From a programming standpoint none of the features introduced in KF8 are in any way supercharged capabilities that require special hardware. Let’s face it. eBook reader software is, in effect, nothing more than a specialized web browser. It is not rocket science! Therefore, Amazon’s decision is hard to comprehend. Web browser implementations have been written a thousand times — I wrote one myself 10 years ago for use in a computer game. There are reference implementations out there that they could have used for free, all things that should have made it possible to retain a unified platform. So, why could’t the software engineers at Amazon make sure they introduce these capabilities in all devices through firmware upgrades?

It is a very short-sighted decision in my opinion, that not only shortchanges the end users, but causes a lot of problems on Amazon’s end as well.

They will now have to begin offering and delivering different versions of the same books – one formatted according to the old, outdated MOBI file specifications, and another one formatted according to the new KF8 guidelines for this to make any sense. How does that make sense?

So, not only will they now have to deal with publishers having to create and upload multiple versions of the same book. This comes at an additional expenses to authors and publishers, as they have maintain two versions of the book. But it also comes at the expense of Amazon, as they have to modify their existing pipeline to accommodate these multiple versions.

To make matters worse, they will have to educate people which format to use for which device, and they will have to prepare – and possibly ramp up support staff, to answer all the customer questions stemming from this sort of confusion.

As I said, I do not think this was a very smart move and it is not in Amazon’s best interest.

Writing and updating the firmware for all existing Kindle platforms would have been a clean way into the future, without all the hassle that comes with platform fragmentation. I know what I am talking about – I’ve been programming for 30 years and I’ve been working in the mobile field for many years, where device fragmentation has gone rampant and costs publishers and cell phone carriers hundreds of millions of dollars every month just to support the insanity.

I know, that for me, KF8 is a step backwards, no matter how attractive it looks at first glance. For the most part it is useless out of the gate because if it doesn’t work on all Kindle devices, it has no value to me and I suspect most of my clients.


Addendum:

An important point was raised in the comments to this post that deserves a few additional words, I think.

Amazon promises that KindleGen 2, the tool they provide to allow authoring KF8 files “will convert your content so that it works on all Kindle devices and apps.”

If you think, this means that all problems are solved with this, you can smoke that notion in a pipe. There is a big difference between could and should.

Just because KindleGen 2 promises to convert your books, doesn’t mean you should, because the output quality will be dubious at best. Of course, if you are part of the I-don’t-care-just-make-it-easy, Smashwords-adoring crowd, yes, that might work for you, but if you take pride in your ebook’s layout and formatting, this is not going to fly.

Let me illustrate this with a very simple example. Say, you have an image and you add the float property to it, to have it embedded in your text with the words flowing nicely around it.

When converting such a file, all KindleGen can really do is ignore the float property — which, coincidentally, all the devices do already. As result, on a Kindle 2 you will now have the image sitting on the left side of the screen with nothing surrounding it. Perhaps the first line of the text that was supposed to float around it will sit firmly at the bottom, creating a huge, ugly gap. Surely not what you had in mind.

If you had properly formatted a version for MOBI devices, instead, you would perhaps have centered the image in this case and spaced it out a little more. That is where KindleGen’s auto-conversion will fail you miserably, because it cannot make decisions like that for you. Things will, undoubtedly get even nastier when your formatting is more complex than this one very basic example, and I would not be surprised if certain elements would even disappear entirely.

Let’s face it, there are certain things the old devices simply can’t do if Amazon refuses to upgrade their firmware across the entire line of products. Just having some devices that support it and others that don’t is hackneyed at best.

As a publisher you will have to look at the lowest common denominator for your product, and that is the long-abandoned Kindle 1, that has seen little love from Amazon in recent years.

Sure, this is not a big problem if you have a novel without graphics or a special page layout. Fair enough, in that case you are really not affected by these changes at all. You will continue to build MOBI files exactly the way you did and ignore the new capabilities, because MOBI offers exactly the kind of functionality you need. Nothing wrong with that.

When books become a little more complex, that is when the problems begin and they will very quickly become exacerbated.

The bottom line — and the main point of my post — is that the way Amazon is approaching this is creating tiers of devices, each tier with different implementational limitations. And that, my friends, is a very real problem.

I am a huge fan of the Kindle. Always been. I owned a first-generation Kindle and in my mind, the Kindle was every bit as revolutionary a product as the iPhone. A game changer.

However, as great as it is, even the Kindle is not perfect. I am not talking here about buttons being too small or somesuch thing. I am talking about the software implementation in the device.

Over the past two years I have formatted hundreds of e-books, as I’m sure you know. I have formatted books for NYT best-selling authors, for publishing houses, midlist authors and indies alike, and I have been able to study many of the idiosyncrasies of the ebook readers in the market close up.

The Kindle has a number of firmware bugs that have unfortunately not been corrected in its three-year lifespan or its three platform generations. At first I was always willing to admit that it was easy to forget that Amazon is simply not a software company but a retailer. So the experience pool is simply not there and mistakes happen.

As the competition mounts we can no longer be so forgiving, I suppose. Apple shows everyone how it is done with an ePub implementation on their iBooks platforms that not only lives up to spec for the most part, but extends it with significant improvements. Apple may drop the ball entirely on the store side of iBooks, but that’s a different story for another blog post.

I think, however, that Amazon can no longer afford to let things like these firmware bugs slide and should take steps to address them properly. Not only in the current or upcoming platform generations, but backwards also, to make sure all Kindle users enjoy the proper, highest quality e-book experience they are looking for.

Here is my list of 10 Things that Amazon should correct in the Kindle.

  1. Let’s start with a simple one. Image transparency. The Kindle supports PNG images but not the format’s transparency settings. Instead it renders the background white. This would be a simple software fix to correct the issue and could be done in a few minutes. In fact, it is surprising that this bug exists at all because PNG transparency is one of the image format’s most basic features.

    Transparency error
    Notice how the background of the image is white against the sepia paper color, while it should be transparent.
    Click on the image for a larger view
  2. Em-spacing. As a book formatter em-spacing is the key to all good formatting, because it allows for proportional scaling of the content, which is key for applications in which text is free flowing – such as e-books.
Currently the Kindle miscalculates the size of em entirely, making it about 4 times larger than it should be. Proper formatting using em-spacing is therefore problematic on the Kindle and I am sure everyone agrees that spacing in pixels is unacceptable in a world where display sizes range from the tiniest cell phone to the largest tables and desktop screens.
  3. Margins are also a sore topic on the Kindle. Not only are margins calculated incorrectly as a result of the em-spacing error mentioned above, the Kindle completely ignores all margin-right settings. To make matters worse it ignores all padding-right information also. As a result it is impossible to space text properly in various occasions.
  4. Border properties are also ignored in many cases. Depending on your Kindle generation or software you may or may not see borders that have been created using the border style attributes in the e-book.
  5. One of the biggest issues, perhaps, is text justification. The Kindle does not properly justify text. Every few lines or so it will suddenly create a ragged line, throwing off the formatting. This is clearly a software bug that should have been addressed long ago but for some reason it hasn’t been addressed even though it is at the heart of the most basic function of the Kindle, the actual flow of text paragraphs.

    Justification error
    Notice how the lines in the top paragraph are ragged when, in fact, they should be fully justified.
    Click on the image for a larger view

  6. Going along with this issue is the lack of hyphenation. While the Kindle software reader software support hyphenation, the Kindle devices do not. Now, I can understand that perhaps the dictionaries necessary to do proper hyphenation may be too large to fit on a Kindle or may be too processing intensive – though I honestly doubt it, giving modern software technologies – the fact that the Kindle does not even support HTML’s soft-hyphenation is really a disappointment. Hyphenation is integral part of text flowing and I am not sure why it has been so overlooked for all this time.
  7. Early generations of the Kindle also do not support tables. When at first the Kindle arrived and was used for novels mostly, this was perfectly fine, but as the acceptance of e-book readers grows, so does the diversity of the books, and, let’s face it, text and reference books need tables. There is always a need to be able to tabulate content, something the Kindle makes impossible. While the current Kindle generation supports tables, it is a feature that cannot be used because legacy readers do not. This feature should be introduced to the Kindle 1 retroactively with a firmware upgrade also to ensure uniformity across all generations.
  8. Another point of contention is object floating. The float property is not part of the mobi e-book specifications, but let’s face it, these specs are older than your last computer. Amazon has bought the company that developed the mobi e-book file format but sadly the development and extension of the format has completely seized, making the Kindle the only e-book reader with a completely outdated e-book format. Before you tell me that Amazon also allows ePub submissions at this point, let me remind you that Amazon converts these ePub files into mobi files before delivering them to users, stripping the e-books of all ePub specific features.
The float properties would allow text to float around images, giving us not only the opportunity to insert images into the text, but they would also make graphical drop caps a possibility at last.
  9. What is also missing from the Kindle is a way to properly deep link to other books in the Kindle store. Sure you can use a link to Amazon’s website and insert it into your e-books, but did you ever look what happens? The Kindle tries to display the Amazon website on its screen, rendering it garbled and virtually unreadable. Why not give Kindle authors the chance to link to page that has been optimized for the Kindle like the one the Kindle pulls up when you search and purchase a book directly on the device.
I cannot tell you how many emails I have exchanged with Amazon on this subject but for some reason the support staff does neither seem to understand the issue, nor care much about it. I was continually referred to use either regular Amazon web links or some XML links that the Kindle could not even interpret properly.
Since upselling more books would be in Amazon’s interest every bit as much as in the authors’, I am flabbergasted at Amazon’s disinterest in providing such a specialized deep link.

    Store page
    This is what a deep link to the Amazon store looks like on the device. Not very useful, is it? Most of it is not at all readable.
    Click on the image for a larger view
  10. Last, but not least, Amazon should spend some time to make sure the software versions of their readers are actually representative of the devices. They do have the best software readers out there — don’t get me started on the Nook software reader that can’t even center text and will crash in 9 out of 10 times — but the way a book looks in the reader is not representative of the device at all? Why is that? Just use the same fonts, the same firmware routines and things should look identical. It is called code portability and I’ve done it for 10 years on cell phone games, making games look the same on hundreds of different phones.

As you can see, these are some basic flaws and it is surprising that they have been sliding by for so long. The things in question are not tied to hardware issues at all. They are all simple software bugs that can be addressed without too much of a hassle. It is really not rocket science. All it requires is a little discipline.

If you agree with me, maybe you would join me in telling Amazon about these issues and reminding them that in order to remain the market leader, they will have to make sure they continue to deliver a superior experience.

Send them an email at kdp-support@amazon.com. Send them a link to this bog post or pick your favorite flaw and ask if they could please fix it. Maybe together we can direct Amazon’s attention towards these software errors that truly deserve to be fixed.

Oftentimes when I send out a finished e-book to a client after I completed the formatting for them, I get an email that asks me, “Why is the Table of Contents in the back?”

The more I thought about it, the more I felt it is something I should probably talk about here on my blog, because there are a number of reasons why placing the Table of Contents — or TOC — at the end of an e-book makes a lot of sense.

Traditionally, in print books that is, the TOC served for readers to orient themselves within a book. You would simply crack the book open, go to the TOC, look for the chapter of interest and then go from there until you got to the chapter you were looking for. We all know where to find a TOC in a print book — in the front — and through years of practice we have learned to use our eye to estimate a position of a certain page number within the whole of a book.

In an e-book things look a little different, however, because if the TOC is in the front, and you are currently reading on page 560, you will have to do a lot of paging to do in order to get to that Table of Contents. Hundreds of button presses are in order… That doesn’t sound cool, does it? No, instead e-book readers have a button that takes you to the TOC, so that a simple button press takes you to a menu from which you have direct access to the table of contents. From anywhere in the book. And you won’t even lose your current reading position.

Hold on a minute, doesn’t that mean…? Yes, it does. The word menu means that the TOC does no longer have to be in the front of the book, because no matter where it is, the e-book reader always finds it for us and displays it in its Contents menu. In fact, it does not have to be part of the actual book text itself at all anymore.

Yeah, but you’re traditional-minded, right? Like, you never thought you’d be using a digital thingie-ma-whatsit to read books on anyway, because you like the feel of a bound book. And because you are a traditionalist, you want your TOC in the front nonetheless, just for tradition’s sake.

Well, not only have you obviously made the switch to digital despite your traditional preference of the printed book, but take it from me, you also want to adapt to modern TOC usage. There is a very good reason why you would not want your TOC in the front of the book.

Apart from the fact that it can potentially give away major plot points through chapter titles, which would be the first thing people see when they open your e-book, the main reason is a thing called reading samples. How does that make sense? Well, think of it this way. When Amazon creates an excerpt of the first 20% of your book to allow people to sample it for free, they take it from where in the book? The front, that’s where.

So, instead of using that exceedingly valuable space to hook your potential future readers and clue them into the premise, your style and the story of your masterpiece, you are boring them to death with a Table of Contents that contains — at its worst — nothing but a three-page list of the numbers 1 to 85. Perhaps you also threw in about five pages of legalese and credits and acknowledgments and such.

Honestly? I don’t think that’s a particularly good way to win over potential readers, let away convince them to give you their hard-earned money for the effort. Therefore, it makes sense to put non-essential things, such as a Table of Contents, in the back of the book where people can reach it but are not forced to sit through it and most importantly, where they are not bored by it when they first open your e-book or reading sample. First impressions are vital — never forget that.

This is no longer the world of print books. Things have evolved and the Table of Contents has evolved with it. Not only has its placement in the book become irrelevant, it has become interactive and therefore deserves special treatment in every possible way.

As people tackle the subject of e-book formatting, every once in a while I receive an email with the question, what meta-data in an e-book are actually used for. Since you will have to re-upload your book description, the ISBN and the keyword tags on every distribution channel’s portal again and again, the question clearly becomes, why am I entering it in Calibre in the first place, if it isn’t being put to use?

First, let me say that it is possible to create e-books without most of the meta-data. Things such as the product description, keywords, ISBN identifier, publisher and so forth are not mandatory, so if you feel lazy, you can leave them out.

However… you knew there would be some kind of catch didn’t you? So, however, if you think they are not being used, you are mistaken. Meta-data are being put to use in a number of places, but the most important one for you as a reader is probably the device itself.

Meta Data Example

When you load your book onto your Kindle or Nook, you see a listing of titles in your library. Depending on your settings and your device, you will also see a small thumbnail of the book’s cover. Do you have any inkling, where that comes from? The meta-data you provided, naturally.

But that’s not all. Many devices allow you to sort books by author, again, using the e-books’ meta-data to dictate the sorting. If the library software on your device is a bit more sophisticated it will allow you to categorize books by genres and keywords, using the “keyword” meta-data you have provided in your e-book.

And so it goes, on and on. While I can’t think of any platform that currently makes use of it, it is also easily possible to think of software that allows you to take a quick preview of the book by printing the product description — culled from the book’s meta-data, of course.

It may feel like you are duplicating information over and over again as you prepare your e-books and upload them to distribution portals, and in fact, you are. I, for example, would love for Amazon to retrieve the necessary data from my e-book file by default, for example, saving me the time it takes to enter all that duplicate stuff, but ultimately it is of no relevance. The process is easy and fast enough as it is, so I have no real complaints here.

What is important, though, is to understand that a book’s meta-data are being put to use over and over again, silently, in the background, to make sure your readers will get the most out of the book and their e-book readers. In fact, I would not be surprised to see meta-data expanded upon in the future to include proper library categorization, author biography and cross references to other books by the same author or titles in a series. These additions may just be around the corner, as Apple is already requesting that sort of information when you upload your book to the iBookstore. Hilariously, though, it makes absolutely no use of the information at this time, it seems, as the iBookstore search engine is about as dumb as a piece of bread. But hey, you can’t have everything…

So, is it a good idea to skimp on your meta-data? Probably not, even though it may seem like redundant information.

This is the ninth installment of a series of articles. To read the previous one, please click here


Okay, it is time for me to finally make good on my promise and turn your book’s HTML source file into a proper eBook. All we need is a little software called Calibre that you can download here.

I want to take a brief moment to point out that Calibre is a free software package and I cannot thank its developer Kovid Goyal enough for putting so much time and effort into this program. Not only is he putting all the effort into writing the application and improving it constantly, Kovid is also very active in his support forums and tries to help everyone with problems whenever he can. So, please feel free to support his restless efforts by perhaps donating a few dollars for the cause. You will find a button on his website and maybe you’d even be willing to commit a small amount every time you actually prepare a new book for publication using his software.

All right, now it’s time to get serious. One of the great things about Calibre is that it allows us to build a variety of eBook formats from the one source file we have so carefully crafted.

The first thing we need to do is to add our new book to the Library. Simply click on the “Add books” button in the upper left corner and select your book’s HTML file. A lot of people do not know that you can actually use an HTML file as a book source in Calibre, but as I pointed out, not only is it possible, it is, in fact, the most reliable way to create a predictable output.

Once you have done that you will see the book appear in the top line of the Library listing. It may have a strange name at this point – Calibre uses the HTML file name by default – but we will fix that in a second.

The next step is to edit all of our book’s meta data. Highlight your book in the Library listing and then click on the “Edit metadata” button in the toolbar at the top. You will now see an input form that allows you to insert all the relevant information about your book on the left side. Most of these fields should be self explanatory, though the “Author Sort” line might be confusing. It is used to allow you to use your last name for sorting. So, instead of “Guido Henkel” I would enter “Henkel, Guido” here.

The large “Comments” field at the bottom is used for your product description. Simply enter your whole flap copy here, your synopsis or whatever you want to call your product description.

Moving on to the right side of the input window you will see a block that is called “Available formats.” Currently it includes only a ZIP file, which is a zipped-up version of our HTML source. Do not do anything else in this block. We will get to it at a later stage.

Finally, lets include the cover of the book into the meta data. This is the cover that will be included in the front of your eBook. It is not the cover that is used by distribution channels to list your book! It is the actual cover image inside the final eBook.

I always create 600×800 pixel color versions of the cover for use here. Even though many eBook readers do not support color at this point this is nothing you have to worry about. The device will automatically convert this to a grayscale image for you. Purists may say at this point that you should actually create an optimized grayscale image for inclusion for better quality. For the most part I found this not necessary. While the end result might be a tad better – and I stress might here because eBook readers are still notoriously bad at displaying images in general – and while the file size might be reduced, I found the tradeoffs not worth it. Not only would you have to create separate versions for color and grayscale readers, but with the growing proliferation of color devices, you will make it possible for Kindle readers on the iPad, for example, to enjoy the full color version of your cover. That alone should be reason enough to stick with the color cover.

Select “Browse,” find your cover and make sure it displays properly in the meta data window. We now have all our meta data and it is time to click “OK” to make sure they are saved.

Next, click on the “Convert books” button in the toolbar at the top of the screen. This is where the rubber meets the road – from a technical standpoint. Here you find the modules that actually turn our source HTML file into the various eBook formats. While all the menu entries and names might seem extremely technical to you, I will guide you through here to make things easier to understand, especially since most of the technical parameters are identical regardless of the selected output format. Which reminds me… let’s select an output format.


In the upper right hand corner you will find a drop-down menu allowing you to select the output format you want to build. For our purposes right now, select EPUB, which we will be able to use for the Nook, the Apple store, Kobo, Google Books and other outlets.

On the left side of the input window you will see a column of icons. these icons give us access to the different settings for the ePub compiler. Most of these parameters we will leave untouched as the default settings that Calibre provides are real world common sense settings. In fact, we could already press the “OK” button at the bottom of the window and get a decent eBook out of it.

Perfectionists that we are, however, we want to take things a little bit further.

Click on the “Structure Detection” icon and you will see a series of cryptic-looking XPath instructions. Not to worry…

Calibre uses this section to determine your book’s structure so that it can format it properly. For example, this can be used to create page breaks before a new chapter. In fact, it is the default setting. The reason I am taking you here is because in case you do not want to include page breaks here, you will need to switch it off by selecting “None” from the “Chapter mark” drop-down menu.

Next stop, our table of contents (TOC). Select the “Table of Contents” icon so we can tell Calibre how to automatically build a fully linkable TOC and include it in our eBook.

Since we have been using a special stye in our HTML file to manicure chapter headings, we can now use this style to tell Calibre where each chapter starts.

All we have to do is enter

//h:p[re:test(@class, "chapter", "i")]

in the field for the “Level 1 TOC (XPath Expression)”. It tells Calibre to look for all instances where the style “chapter” is applied and add them to the table of contents. Calibre will automatically use the entire chapter heading text to display in the TOC, which means the entire block of text that is style with the “chapter” style. From my experience that is exactly what we want. If not, you could narrow the selection down further using XPath expressions to drill down further. If you want to learn more about XPath expressions, feel free to check here.

The last step before we build our book is found in the “EPUB Output” section. Select the icon in the left toolbar and you will find a checkbox entry that says “Preserve cover aspect ratio.” Make sure to select this as otherwise your cover will be disproportionally scaled to fill the entire display of any eBook reader. I am not sure why this is not checked by default, but so be it.

That’s it. Click on the “OK” button and you will notice that Calibre is doing some work in the background. It will tell you so with a small animation in the lower right hand corner of the Calibre window.

This will take a second or two, depending on your computer’s speed and the length of your book. But once it is done we are ready to save the finished eBook.

Click on the “Save to disk” icon in the top toolbar and select a location where you want the book to be saved.

Now it is time to take a look how things turned out – it is the big moment. While it is possible in to use Calibre’s viewer, I found that despite the overall quality of Calibre, the viewer is – at the time of this writing – not at all representative for what your eBook really looks and behaves like on a real reader.

For first checks I always use the software versions of the Kindle or the Nook reader or Adobe Digital Editions. These will immediately give you the results you’re looking for, especially since many people use these application to actually read their books on. However, you should always make sure to also load you books onto the actual devices, if possible, to see they behave properly. It is always better to make sure than to make assumptions and extrapolate from a software implementation running on a desktop computer.
When I load an eBook up for the first time, there are usually three things I checked first.

  • Does the cover display correctly?
  • Are there proper page breaks before chapters, and do the chapter headings display properly?
  • Does the book contain a complete and working table of contents?

Once you have made sure these are in order, you should begin to browse the book very carefully from beginning to end. Look particularly for passages where text switches suddenly to italic text. Particularly when have inserted the <i> tags by hand, it can happen all too easily that you accidentally forgot to close the tag properly, or you mistyped it. Only a visual inspection of the book, page by page, will make sure your text is in order, so take a few minutes and go through it.

If there are errors in your source file you will have to go back and edit the HTML file. What is important is that once you have made the changes, you will have to re-import the HTML file back into the Calibre book. In order to do this, click on the “View metadata” button again to bring up the meta data input form.


You will see that the box saying “Available formats” now also includes an EPUB entry. Delete all the entries here, MOBI, EPUB and most importantly the ZIP entry. Simply select them and hit the “Delete” key on your keyboard to get rid of them.

All we have to do now is bring the HTML file back by clicking on the icon with the red book and the plus sign in the right hand corner. Select your corrected HTML file and then go ahead and rebuild your eBook file. Save it and check to make sure the errors have gone.

Once you have confirmed that everything is as it should, it is time to build the other formats. Select MOBI from the drop-down menu in the “Covert books” form. chances are you will not have to change anything else, as the structure and TOC settings format independent, and because MOBI does not require any format specific adjustments. Build the eBook and save it.

Congratulations, you now have proper EPUB and MOBI ebook versions of your book that are virtually guaranteed to be free of the most common formatting errors found in today’s eBooks. To distribute your eBooks, all you need to do is send the .epub or .mobi file to your customers via email, or to upload them to Amazon, Barnes&Noble, or whichever outlet you want to serve. In case you were wondering, the eBook files contain all the graphics and images that are needed, so you will not have to send the JPG images with it. They are safely embedded directly in the files so that they can’t get lost.

I hope I have been able to help you with this series to understand that in order to create quality eBooks it is not only necessary to tackle the problems by their roots, but also that it is not nearly as intimidating a process as one might think.

Building an eBook from the manuscript to the final build can be done well under an hour if you’re familiar with the workflow. In fact, formatting my own “Jason Dark” titles, usually takes me no more than 15 minutes.

Let me know how this series has helped you, and let me also know there are subjects and issues that you’d like discussed in more detail. I’ll definitely see what I can do and highlight these issues in follow-up posts to this series.

In addition, if you wish to hire me to create your eBooks for you, feel free to send me an email.

Lastly, if you enjoyed this series and found it helpful, please feel free to support my efforts by purchasing one of my books. You can find them here at Amazon, Barnes&Noble or on the official Jason Dark: Ghost Hunter website.


Take pride in your eBook formatting
Part IPart IIPart IIIPart IVPart VPart VIPart VIIPart VIIIPart IX

Need help with an eBook project? Check here for more information.

This is the eighth installment of a series of articles. To read the previous one, please click here


Last time I promised you I’d cover some more frills for your eBook formatting, and as you’d certainly agree, images are a big part of that. Even for fiction writers images offer great opportunities to present your book in the best possible light, so let’s take a look today how you ca best make use of that.

In fiction, one of the most obvious places to have images included is as part of a book’s chapter heading.

Imagine, if you may, to include a small visual vignette underneath the chapter heading text to set it apart even more.

Here is a small image that I am going to use in my examples. Feel free to right-click the image and save it for your own perusal.

”vignette”

In theory, this is exceedingly easy to do, using style sheets and the background-image parameter. You could simply add the following line to your style for chapter headings and see the image appear and trickle down through all your chapter headings.

background-image: vignette.png

Unfortunately, the background-image parameter is not really part of the CSS style sheet subset used by the ePub eBook file format. Although most eBook readers support it at this point — the major exception being the Kobo reader — it is sadly not safe to use. This may change in the future, but if you want to create a stable eBook I discourage its use.

The alternative is, sadly, not nearly as elegant and requires a good bit more work. What we have to do is include the image manually at every chapter heading, which might look something like this.

<img src="vignette.png" alt="pinstripe" />

The important part when using images is to include the slash at the end of the <img> tag and to include the alt parameter. Without them, our final eBook will not be in the proper format required by many distribution channels. The alt parameter is really just a text description of what the image shows. It is used if, for some reason, the device can’t read the image or if it is displayed in a mode for blind people, where images are dropped altogether. Instead, the alt-text is used to inform the reader what the image showed, which is why I used the word “pinstripe,” since the little graphic I embedded there is an image of a pinstripe. Makes sense, doesn’t it?

To center our vignette on the line, all we need to do is wrap the image tag with the proper <p> and <span> tags, just like we would do when centering text.

<p class="centered"><span class="centered"><img src="vignette.png" alt="pinstripe" /></span></p>

CHAPTER 1

pinstripe

Jason Dark was leaning over the chess board when Siu Lin entered the room with a dog-eared book in her hands.

“Trying to solve another one of the London Illustrated’s chess challenges?” she asked.

CHAPTER 2

pinstripe

She had a smug smile on her face when she finally looked at Dark, but it disappeared the moment she saw his expression.

Dark had gone entirely pale as all blood seemed to have drained from his face. For a moment his eyes stared straight ahead, unfocused, not seeing anything. His lips were trembling and he clutched his left arm.

***

Even though you have to manually include the image tag in every instance of your chapter heading, oftentimes you can automate the process by using your programming editor’s search/replace function using a very simple regular expression.

Simply replace — for example —

<p class="chapter">(.+)</p>

with

<p class="chapter">$1</p>
<p class="centered"><span class="centered"><img src="vignette.png" alt="pinstripe" /></span></p>

While it would be theoretically possible to create a separate style for these images that contains instructions to center the image, I decided against it. We have found a way that is virtually bullet-proof by using the <p> and <span> tags, so why take any risks by using something instead that might cause problems somewhere down the line. When in doubt, I typically tend to err on the side of caution, even if it means writing a few extra lines of code. It is just good practice.

In his book “Scourge,” author David H. Burton took this one step further when he wanted to have his chapter headings in a fancy font that mirrored the typeface used in the book’s cover. Since fonts are extremely limited on eBook readers, we decided to achieve this by using images of the actual text that were created in Photoshop. While it increased the file size somewhat, it did have the benefit that it immediately created a very distinctive look and feel for the book as a whole and paid big dividends in my opinion.

This is how it was created.

<p class="chapter"><span=”centered”><img src="Chapter1.png" alt=”chapter1” /></span></p>

There is a big catch to this, however, as we are no longer able to let Calibre automatically create a table of contents for you. The problem here is that we no longer have the plain text that Calibre relies on to build the TOC with. All we have is an image that Calibre can’t interpret. So, what do we do?

There is a nifty work-around for this. Let’s simply change our code to something that looks like this.

<p class="chapter" style="display:none">Chapter 1</p>
<p class="chapterImg"><span=”centered”><img src="Chapter1.png" alt=”chapter1” /></span></p>

How cool is that? What we did was, we created a traditional chapter heading with plain text, but by using display:none as an additional style setting, we essentially make the text invisible. It is there in the code for Calibre to use, but the eBook device itself will not render it. Right underneath then, we plant our graphic text and all is as it should be.

I hope you enjoyed our “frills” session so far, but we’re not quite done yet.

Aside from chapter headings, there are occasions where we would like to include images directly in the text. Scene changes often are examples of that, where traditionally small vignettes find their use.

If you want to do that, all we need to include in our text is a proper image tag at the correct location, that could look something like this.

<img src="vignette.png" alt="scene change" />

Occasionally, you might want to embed images in the text itself for illustrative purposes. We might want the text to flow around them, and would like the image to appear either on the left or the right side of the screen. Once again, all of that is a simple case for our styles.

img.left
{
  float: left;
  margin-right: 5px;
}

img.right
{
  float: right;
  margin-left: 5px;
}

To create an image that sits neatly on the left side of the screen and has text flowing around it, we would simply use the following tag in our mark-up.

<img class=”left” src="apicture.jpg" alt="picture" />

We would use

<img class=”right” src="apicture.jpg" alt="picture" />

respectively for an image that sits on the right side of the screen and has text flowing around it.

CHAPTER 2

pinstripe

coverSiu Lin walked over to the small table and pondered over the chess pieces for a moment. She tilted her head slightly to the side as she analyzed the board set-up and ran through a variety of moves in her head. After a few moments she sat down in a chair opposite of Dark’s, mulling the chess problem over in her head some more. In silence both tried to figure out the solution to the challenge, each trying to beat the other to it. “Bishop to C6,” she finally said. “Then counter with the Rook to H8, and from there it is going to be easy.”

She had a smug smile on her face when she finally looked at Dark, but it disappeared the moment she saw his expression.

Dark had gone entirely pale as all blood seemed to have drained from his face. For a moment his eyes stared straight ahead, unfocused, not seeing anything. His lips were trembling and he clutched his left arm.

***

I will leave it up to your own imagination to come up with great ideas to use this cool feature.

Note: Unfortunately the mobi file format does not allow for floating images at this time. This means, of course, that it is not possible to use one of layout’s greatest features on the Kindle to the best of my knowledge. If you have found a way to float text around images in mobi files I would love to hear from you!

Here we are, already at the end of an installment, and we still have not managed to get our book into Calibre to build a “real eBook. I apologize for that and promise we will definitely do that in the next installment. In the meanwhile, at least you can check out your book in a web browser and play around with the many features we have explored so far.

Everyone has different needs for their books, so if you have any specific ideas for “frills” that you’d like me to discuss, please feel free to leave me some comments.


Take pride in your eBook formatting
Part IPart IIPart IIIPart IVPart VPart VIPart VIIPart VIIIPart IX

Need help with an eBook project? Check here for more information.