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

---

Now that we’ve seen some of the structural basics of HTML, it is time to examine how you can affect the actual look of these elements. The easiest, most efficient and most reliable way is through so-called style. A style sheet is nothing more than a list of definition that allows you to tell the device exactly what you want it to do with each of the available HTML tags.

A valid style definition in HTML would look something like this…

<style type=text/css>

  p
  {
    text-indent: 1.5em;
  }

</style>

We need to surround these styles with a <style> HTML tag to tell the device which part of our page is the actual style definition or it would otherwise mistake it for structural HTML tags and end up with syntax errors.

There is a remarkable wealth of things you can directly influence with these types of style settings. The most commonly used ones are things such as font face, font size, line spacing, indentations, margins and so forth, but it is also possible to actually create things such as borders, drop shadows and other exciting things with, or even include specific images for display with each one of their respective tasks.

Some of the biggest problems I have seen while I was creating HTML sources for eBooks had often to do with the fact that every eBook reader has its own default settings. Some of them are set up to include extra space at the end of a paragraph, others are set up to create a 20 pixel margin around the text, others yet will indent the first line of every paragraph by default.

For us, this kind of random behavior is oftentimes unacceptable, and fortunately there is an easy remedy for it — a so-called style reset.

html, body, div, h1, h2, h3, h4, h5, h6, ul, ol, dl, li, dt, dd, p, pre, table, th, td, tr { margin: 0; padding: 0; }

This line, which will be the very first line in our style definitions, tells the device to remove all default margins and padding by setting them to 0 for all major tags we might use. The next step for us is then to go create specific style settings for all the tags we are going to use.

Since we will be using only a very small subset of HTML tags, in practice this is very little work but instantly gives you 100% control over the look of your final eBook. No more guessing or chance formatting for you!

“Hold on,” I can already hear you say. “Not all paragraphs are equal, for example,” and you are absolutely correct. In our eBook we will have paragraphs for general text, we might have headlines, we certainly will have chapter headings, and each of these will require a different look.

Fortunately, HTML gives us an easy way to create customized tags and allows us to style each of them individually. We do this by assigning a class to a tag, thus letting the device know which style to use for it. Take a look at this line, for example.

<p class=headline>Look at me</p>

Upon encountering this paragraph tag, the device will look for the paragraph style called “headline,” and use its settings to display the paragraph. If we want to tell it to display this type of paragraph in a large bold font, we would simply create a style that could look like this.

p.headline
{
  text-size: 2em;
  text-weight: bold;
}


This is pretty easy stuff, isn’t it? But what the heck does 2em mean?

While it would be possible to define the text size in points, the way you would do in a word processor, in the publishing world it is oftentimes easier to use the alternate measurement of Em.

Since text sizes in a document are usually in a certain relationship to each other, it makes much more sense to use a relative measurement than absolute font scaling. In practice this means that if you change the base font size of the document all other sizes in the document are automatically scaled up as well to an equal degree. All measurements made with ems are derived from that one base font size definition.

Not only does this ensure that the size relationship between fonts in your document remains intact at all times, it also means that you will not have to change all your styles manually, if, after a long day’s work, you decide that all the text is actually a tad too small. By using the relative measurement of em, this won’t be problem for you, ever.

I could bore you with the history of the em and talk about the old days when typesetters like myself would work with lead characters, but to make things easy for you, simply think of one em as the space taken up by the character M. In most typefaces, this creates a space that is as wide as it is high and is therefore a recognized measure.

If we are working in a 12pt font, for example, 1 em is also 12pt. Now, let’s assume we want to create an indentation in our text that is four characters – or 48pt – wide, we would simply make the indentation 4em. The advantage, as described above, is that if we should decide to switch to a 10 font instead, the indentation of 4em will still be four characters wide — 40pt in the new font size. The visual balance of our text will remain unaffected and it will remain pleasing to the eye without us having to raise a single finger. That is the magic of using the right tools for the job…

There are many parameters that you can adjust through HTML styles — far too many to cover here. We will encounter a number of them as we go along. Since most of them are self-explanatory, I may not necessarily explain the function of each one. However, if there are certain things to look out for, or if we should encounter unusual settings, I will certainly let you know about it.

There is one HTML tag in particular that I think I should single out at this point, however. I usually stay away from using H1 tags and its brethren H2, H3, H4, H5 and H6. They are strange beasts and their behavior can be quite unpredictable, depending on the device or browser you are using. Since we can recreate the behavior of these tags easily through the use of specially styled paragraphs, I usually prefer going that route.

A replacement of the H1 tag, for example, could look like this.

<p class="h1">This is a large headline</p>

By using an appropriate style for the paragraph class we can now give it the size, font and weight we desire.

p.h1
{
  text-size: 4em;
  text-weight: bold;
}


Below you will find an example of a style description that could easily use in any eBook right out of the box and get good results, no doubt.

<style type=text/css>

  html, body, div, h1, h2, h3, h4, h5, h6, ul, ol, dl, li, dt, dd, p, blockquote, pre, form, fieldset, table, th, td, tr { margin: 0; padding: 0.1em; }

  p
  {
    text-indent: 1.5em;
  }

  p.title
  {
    font-size: 1.5em;
    font-weight: bold;
    margin-top: 5em;
  }

  p.headline
  {
    text-indent: 1.5em;
    font-weight: bold;
    margin-top: 1.5em;
  }

  p.chapter
  {
    text-indent: 1.5em;
    page-break-before: always;
    font-weight: bold;
    margin-top:5em;
    margin-bottom:2em;
  }

</style>

I will leave you with this example for this time. Feel free to explore style settings in a bit more detail in the meanwhile. In our next installment we will take a look at how to put it all together into an actual eBook source file.

---

Take pride in your eBook formatting
Part I • Part II • Part III • Part IV • Part V • Part VI • Part VII • Part VIII • Part IX

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

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

---

The basics of HTML

Finally, with all the preliminaries out of the way, we are finally ready to descend into the real machinations of eBook creation, but since we will be working with HTML for the next few chapters, let me explain some of the basics first. I will keep this very short because ultimately it is not all that relevant to creating eBooks but it certainly helps understand why things work the way they do. I’m an inquiring mind by nature and I always feel more comfortable doing things when I fully understand what is going on under the hood, and why. It is the reason why I always loved machine code programming because it truly lets you get down to the wire… but I’m straying.

When working with HTML there are two basic layers of information that you need to be aware of because they need to be kept separate for best results. The first layer deals with the structure of the information in an HTML document while the second one deals with its visual presentation.

The structure defines, for example, the titles of a chapter and the actual text of that chapter. If your book is a bit more complex, the structure will also define where images might be embedded in the text. But that’s usually as far as it goes. The facts, only, Ma’am, if you please…

The second layer, the one that is responsible for the visual representation, then takes that structural information and determines how it should look like on a screen, whether you chapter title is in bold typeface, for example, and whether it should be somewhat enlarged, perhaps. It is in charge of creating proper page breaks, indentations and line feeds, as well as possibly margins around your text. It will determine exactly how to place the images embedded in the text, whether text should flow around them or if they should be centered on the page, breaking up the text flow. All these things that are responsible for how your book will look like are handled by this second layer.

As you will learn, the separation of these two layers is crucial because not only will it create in more robust HTML files, it will also make your life a lot easier.

The structural layer

HTML is a basic mark-up language that allows you to insert certain information into text to give it certain properties. All HTML tags are bracketed by < and > signs. One of the easiest ways to understand this is perhaps the following example.

This is an example for <strong>bold</strong> text

As you can see, we have inserted the tag <strong> before the word “bold.” The <strong> tag tells the display device that we want the text following the tag to appear in a “strong” typeface – what exactly that is we will discuss later. For the time begin, let’s just say, it means we make it bold. On the device, the result of this line will look something like this…

This is an example for bold text

Naturally, we will also need to tell the display when to switch back to the regular typeface, and we can simply do that by inserting a </strong> tag. It is like a toggle. Turn bold typeface on… write… turn bold typeface off.

Most of HTML works this way, as you will see. An opening tag starts an action, a closing tag ends it. Look at the following example and I am sure you will understand what it does as soon as I tell you that the <em> tag means “emphasize,” which in HTML is equivalent with italic.

This is an example for <em>italic</em> text

Yeah, I assume you see how this works, don’t you? In your eBook reader, the result of this line you look a lot like this

This is an example for italic text

Let’s try something a little harder. Make this more interesting, so to speak.

One of the major elements of a book are paragraphs. A number of sentences that we bunched together and that we usually want to appears as some kind of unified block. The best way to tell HTML that it is dealing with a paragraph is by using the <p> tag.

<p>This is a paragraph. It might be a short one, but computers are intrinsically stupid and surely won’t care.</p>

Note the opening <p> and the closing </p> tags that tell the display device exactly where we are beginning and ending our paragraph. With this knowledge, we can later tell the device exactly how we want it to treat and display these paragraphs.

Another very important HTML tag that you will most likely come across when building eBooks is <img>, used to embed an image in a document. Its use looks something like this.

<img src=“/images/cover.jpg” alt=“Cover” />

Its usage is very simple. All we do, is tell the device where to find the actual image file — the file “cover.jpg” in the subdirectoy “images” in this case. Unlike HTML you would create for web pages usually, when we create HTML for eBooks we need to be a little more mindful of some of the smaller details. The alt parameter, for example, is essential in eBooks and cannot be left out — unless you want to create a flawed, broken eBook file that will be rejected by various distribution outlets. So, simply include a brief one- or two-word description of the image. It doesn’t really matter what you say here, as long as you have the parameter included. If you wish you can even leave it empty, and make it look like this

<img src=“/images/cover.jpg” alt=“” />

In addition always make sure to close the tag properly with the slash at the end, like such “/>”. eBook readers are very picky about these small details, so make sure you do it right the first time around and turn it into a habit.

For the most part, these are the key tags we will be using to build our eBooks. While there are many other tags in the HTML vocabulary, from my experience, the ones I just showed you are pretty much the core of what you will need. For certain, more specific tasks you might have to make use of others, but I prefer to introduce and tell you about those as we get to them over the course of this series. It will be easier to understand and memorize them when you see them within their proper context and in actual use.

For now this will suffice and as you can see, this has been very easy and straight-forward, has it not? Like I said, easy as burning a marshmallow over an open fire.

In the next installment of the series we will begin to take a closer look at the second layer of HTML where I will show you how to affect the actual look and layout of the text elements we discussed above.

---

Take pride in your eBook formatting
Part I • Part II • Part III • Part IV • Part V • Part VI • Part VII • Part VIII • Part IX

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

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

---

The Road to Right

After having spent a lot of time in my last installment, telling you how you should not create an eBook, I will no longer hold you back with explanations of Wrong and instead we will point our heads forward and look down the road of Right. Let’s start with a quick overview over the process I am proposing just so you get a general idea for what you’re going to get yourself into. Depending on your level of expertise this might or might not be all that intimidating at first, but let me assure you that there is no magic involved and every tasked can be performed by virtually anyone familiar with a computer. Remember, the key lies, as so often, in getting the right tools or the job and putting them to work for you.

The majority of ebook formats in use today are nothing more than a packaged collection of HTML files. Yes, the same kind of files used to create and display web pages. Surprised? You shouldn’t be. It actually makes a lot of sense. HTML has been created to allow information display on a wide variety of display devices regardless of their capabilities. Whether your computer monitor has a high or a low resolution, whether you are running your browser fullscreen or in a small window, on an old or a new computer, basic HTML pages will always be able to display properly in all these environments.

Since we don’t know what device or software the reader will use when they want to display our eBooks, it only makes sense to utilize a format that is tweaked for that very purpose, doesn’t it? A format that has free text reflow capabilities and can easily embed images and other media. You might recall how I told you that you can actually embed video in your eBooks if you want to, and now you know, why.

HTML is a format perfectly suitable for the needs of the eBook community and all it really lacks is digital rights management, or copy protection to put it in plain old English. To accommodate that, some of the eBook formats are encrypted internally, but that is really none of our concern at this point. Let other people worry about that. We just want to package our book in a digital format that can be used by eReaders for the time being.

Among recording musicians we have a saying that is very suitable for our cause: Garbage in, garbage out! It means that when the source you are recording is garbage, your end result will inevitably be garbage also. There is just no way to make a bad source signal good. The synthesized vocals of current-generation pop stars are living proof of that.

Since we know that our end result is going to be an HTML file, the best way to avoid garbage along the way is to choose a source format that is as close to the output format as possible. So, if the output is HTML, why not make the source format HTML also? HTML is a very simple markup language that is so basic and, more importantly, widely document today that anyone can pick up the basics in under 30 minutes. In fact, many of you may already be familiar with the general basics of mark-up languages from styling their message board posts or maybe even creating their own web pages and blog posts.

To put it very bluntly. If we create an HTML file as the source for our eBooks, the end result will be every bit as reliable as the HTML file we initially created. Makes sense, doesn’t it? And that is really all there is to it. That is the secret to creating professionally-looking eBooks. You take the contents of your book and prepare them as a first rate HTML file and run it through a packaging software to prepare the final eBook for you. Yes, it really is THAT simple!

I would be remiss, however, to leave things at that. I promised to show you exactly how to do it, and I will. To make sure you are not getting stressed out at this point, let me repeat our key mantra once again.

The right tools are critical for an easy workflow.

Get the right tools for the job and you’ll be pitching a home run in no time. You will be a much happier human being and you will have much more time on your hands to enjoy other things in life. With that in mind, let me run you through some of the basic tools we will peruse in the next installments; tools that will help us achieve the perfect eBook formatting we so desire.

I don’t know about you, but I’m a Mac-head. I have long ago decided that my time is too precious to waste on computers and operating systems that don’t work properly and turn into utter time sinks. As a result, I am an Apple Mac user, plain and simple. As I said. Get the right tool for the job.

While I highly recommend you should use a Mac also – you will see you productivity go through the roof for one thing, I promise – this does not mean that you really need one. Everything we do on the following pages can be done on a Windows computer also, so do not worry.

At this point, let us assume that you have completed the manuscript for your book and have it entirely committed to a single word processor document. Needless to say, you will need a basic word processor to open, read and massage the file, but once again, I assume that as a writer, you do have that.

What you will also need, ideally, is a software called a Programming Editor. I use personally TextMate (http://macromates.com), but there are numerous other editors available on the internet also, which will serve the purpose just fine, some of them as paid software, others for free. JEdit (http://www.jedit.org), for example is a free programming editor that is available for Windows, Mac and Linux platforms and will definitely do you nicely.

In addition we will be using Calibre (http://calibre-ebook.com) for our final creation of the most common eBook formats. Calibre is a free software package that works under Windows and on the Mac.

In the next installment we will take a closer look at some of the features of HTML that we will need to whip our eBooks into shape and how they impact how we will create our eBook source file.

---

Take pride in your eBook formatting
Part I • Part II • Part III • Part IV • Part V • Part VI • Part VII • Part VIII • Part IX

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

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

---

Why you shouldn’t use a word processor

When I visit message boards for authors on the the Internet I keep coming across the same question over and over again, followed by what is effectively the same advice over and again. Sadly, in my opinion, the recommendations are all too often ill-advised and tend to create more problems than they solve.

What I am referring to, of course, is the question that aspiring independent authors frequently ask once they get to the stage where they want to self-publish their books, “How do I create an eBook?” Aside from the noise that such a question generates, the tenor of responses usually goes something like “You can export an ePub file from your word processor” or “Take your word processor file and upload it to insert-your-favorite-conversion-service-here for conversion.”

To me, these responses are usually not real advice. They are opinions. Someone suggests the procedure because it worked for them, completely ignoring the fact that their own eBooks resulting from said procedure are oftentimes riddled with problems and/or that the way to get there was resembling running a gauntlet of cumbersome obstacles and tests of patience.

Advice, on the other hand gives you the opportunity to make an educated decision based on the evaluation of information. So, let me give you a piece of advice.

Do not use a word processor file as the source of an eBook.

As you will see in a moment, word processors are not very good at what eBooks do and are therefore the wrong tool for the job. It’s like trying to hand someone a spoon to dig out a swimming pool. It is certainly possible, but at what price?

In life, the proper tools will always make your life easier, because tools are designed for a specific task. They will perform this particular task better than any other tool and should therefore always be your first choice. You would never use a blender to mix waffle batter, yet that is exactly what many authors are doing when they try to create eBooks straight out of a word processor document.

I can already hear you, getting all giddy with the question why I suppose a word processor is the wrong tool, and I think it is time for me to finally answer that question.

Word processors have been designed to enable writers. They are the replacement of the typewriter — in case you still remember those. Their goal is to make it possible for people to write text as cleanly and efficiently as possible, allowing them to simply dump their thoughts onto a computerized sheet of paper. In order to make this as easy as possible, word processing software puts a number of additional tools at the writer’s disposal which come in very handy and will help to keep writers focused on the task.

That is the job of word processing software. However, as computers became more powerful and software companies realized that they can’t keep selling the same toolset to people over and over again they began to add features. Slowly at first, further making the writing flow more practical, it soon deteriorated into what developers know as “feature creep.” It is a phenomenon that has cropped up across all branches of software development and describes the situation when more and more features are being added to software for nothing but their own sake. If you take a look at today’s word processing packages you quickly realize that they contain an overkill of flashy features designed solely to impress users. At the same time, these packages contain a smorgasbord of obscure features — many of which are actually helpful to writers but not very sexy to market — that are so forgotten that most users don’t even know they exist. Or did you know that your word processor probably contains a generator to create random text? Better yet, did you know that it probably contains a feature that allows you to create “Lorem Ipsum?”

Which brings us to the next problem with word processors. Year after year they have encroached upon the Desktop Publishing Space. It started with simple WYSIWYG attempts and today virtually all word processors in the market pretend to be able to do full page layout. I say “pretend” because despite thinking of themselves as being the jack of all trades, the DTP features in word processors are usually completely worthless. Problems ranging from ridiculous sixteen linked-up textbox limits to unpredictable text flow behavior and errors, make them pretenders in the truest sense of the word, rather than contenders.

I am rambling, I know. So why am I telling you all this? To put it simply, because these days word processors try to do too much and obscure too much as a result. From the point of view of a book editor, that is. All these fancy WYSIWYG text layout features are useless if they can’t be properly converted into eBooks and that, in fact, is the crux of the matter. Word processors are almost by definition inept in handling text output that needs to be formatted for variable text flow — a feature crucial to a good eBook.

To illustrate the point, let me show you the following word processor screenshot.

As you can see we have three paragraphs of text here, each formatted with a first-line indentation and extra line spacing between each paragraph. Simple enough, right? It’s what a manuscript should look like in the computer.

The problem here is in the detail, however. What you don’t see is what will run you to the edge of madness when the time comes to create an eBook.

The first line created the indentation using a tabulation character, the one generated when you hit the TAB key, while the second paragraph achieved its indentation by inserting a series of white spaces, blanks. The third paragraph on the other hand achieved the same goal by using a style formatting, telling the word processor to automatically indent the first line in every paragraph by a certain amount without requiring any characters.

Three very different approaches to achieving the same thing. Make a mental note, if you will, which one you think is the best way to achieve first-line indentation. We will talk about it in a bit more detail later on in the series.

This is but a small exploration of the problems inherent in that little screenshot. If you look at the extra line spacing, you are looking at another ugly beast rearing its head when the time comes to create an eBook. The first paragraph has been set apart from the second using an extra line feed character — inserted by pressing the Enter or Return key on your keyboard. To set apart the second from the third paragraph, however, we have once again applied style formatting instead, which tells the software to automatically insert extra line spacing of a certain size after every paragraph.

Are you seeing what I am driving at, yet? Since each of these paragraphs has been created differently, there is a very real risk that each of them will look differently once you let the word processor export your text to an eBook. Naturally, the problem can be avoided by using the same way throughout your entire document, but let’s face it, in the real world, very few people are as rigorous and organized that they apply the proper style setting every time they italicize text or want to create an indentation, particularly over the period of time it usually takes to write an entire book. Since we can’t easily see existing formatting errors in the word processor, we are always teetering on the edge of hidden defects using this methodology.

I could bore you with countless other examples where things can go horribly wrong, but since you are reading this, I assume you already figured that out yourself and are looking for a better way to do things. As authors in the real world, what we need is a way to create eBooks that produce reliable results, and word processors simply don’t do that. What is needed, is a different approach, and I will tell you more about that in the next installment of the series.

---

Take pride in your eBook formatting
Part I • Part II • Part III • Part IV • Part V • Part VI • Part VII • Part VIII • Part IX

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

To me, one of the key elements that sets apart a professional eBook release from that of an amateur has always been the technical presentation of the book. Sure, anyone can write a document in a word processor, run it through some export tool, use a fully automated conversion utility or peruse the services of an online service, but the sad fact of the matter is that none of these approaches typically results in, what I call, production-level digital books.

So, why are people using them? I have spent a lot of time thinking about this and observing how other authors approach their eBook publishing, and the more I examined it, the more I have noticed that there are generally two reasons for it.

The first reason is that many authors simply don’t know any better. They write their book, complete it and look for the fastest, cheapest and easiest way to deploy it. Don’t be one of those authors! It is a sad testimony in my opinion, and certainly not a valid excuse. You have labored over your book for months, maybe even years, you have read and re-read it countless times, cleaned out typos and grammatical errors, massaged the style and worked on the structure, grinding away in the wee hours of the night alongside holding a daytime job and maybe having a family. You did not get here just to break the first cardinal rule of book publishing:

Don’t get sloppy on the home stretch! It will reflect poorly on your work.

If you’re anything like me, an author you’re not familiar with has one shot to prove himself to you. I will never again touch the book of an author who has made a bad impression on me by delivering a broken eBook that is clearly sub-par. I can forgive many things in a book if I so please — stilted language, poor pacing, logical errors, uneven style, even the occasional typo. However, one thing I cannot forgive is poor eBook formatting, particularly if it is to the point that it becomes distracting from the actual reading experience, and sadly I have seen too many of these in recent memory.

I started reading books as a form of entertainment 35 years or so ago and to this day I have not once found a printed book that had formatting problems! Every book that goes to print is practically flawless, except for a typo, perhaps, or print issues such as ink blotting or somesuch production-line flaw. However, I have never seen a book where the font size suddenly jumped, where the font face suddenly changed, where indentations were all over the place or where paragraph adjustment switched from justified to left aligned halfway through a paragraph.

Since the dawn of eBooks, however, these things have become prevalent, and what’s more worrisome is the fact that to many authors this seems to be completely acceptable. To me that notion is ridiculous and disconcerting, and no writer who is worth their salt should ever be caught publishing an eBook that is not equally flawless as the longstanding tradition of print books has dictated.

You may frown upon traditional publishing houses and their supposed arrogance all you want, but most indie authors would still do well to take a few lessons from these dinosaurs. Among many other things, at least they know how to produce and package a product for sale and do not discount professionalism as a sales point at the expense of instant self-gratification.

If you are a self-publishing writer and want to be taken seriously, spend a little time getting acquainted what digital eBooks actually are. Learn how they work, how they originated, what they can and cannot do. You might be surprised how many cool features you can actually add to an eBook with the proper background information and some of these capabilities may truly enhance your books. Sure, some of the features are not very useful for most types of books, but, just as an example, did you know that you can actually embed video content in eBooks?

The second reason why many authors never take the time to create proper, optimized eBooks is that they are perhaps intimidated by the process. It is a technical process, to be sure, but it is nothing to shy away from or to be afraid of. All it requires is a very basic sense of structure and sequencing, things we’ve all been taught since first grade and that we have down pat.

Let’s be realistic, for a moment. This is you, a smart and intelligent person. You have written a book. You have mastered the spelling of millions of words. You have internalized grammar rules and overcome countless stylistic challenges over the course of putting your book together, not to mention that, most likely, you had to plot it all out properly to create a dramatic arc, or to create a stream of conscious that readers can follow.

By comparison, creating professionally formatted eBooks is as easy as burning a marshmallow over an open fire.

Over the next couple of weeks I will post different installments on this blog to show you how you, too, can get to state-of-the-art, professional-looking eBooks that work perfectly on any eBook reader in the market, taking the guess work out of creating your final product. Stay tuned…

---

Take pride in your eBook formatting
Part I • Part II • Part III • Part IV • Part V • Part VI • Part VII • Part VIII • Part IX

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