Introduction

Chapters

Strategy Resources Structure Style Layout Composition Production Infrastructure

Appendices

E-Book Formats Explained Image Formats Explained Advanced Styling & Layout Better Photography Working with SVG Unicode and All That Troubleshooting

Supplementary

Revenue Calculator Contact
Copyright © Dodeca Technologies Ltd. 2016

Style

The previous chapter shows how to insert tags into a block of content in order to format it as HTML, which gives the content structure that has meaning to a user agent. However, HTML does not direct the way in which content elements should appear stylistically, and so user agents use default values for, say, the size of text used when rendering an <h1> element. In fact, you can stipulate your own preferences for a great many such factors, and this is the role of CSS.

This chapter explains this important area of e-book production, but do note that you may choose to go with e-reader defaults, and avoid applying any custom styling to your book. In this case, you can skip this and the next chapter completely, and go to Chapter Six,​which considers compositional issues, or straight to Chapter Seven,​which lays out the production process in fine detail.

Indeed, if you are very new to e-book production, it is far better to create an initial EPUB file without styling and images (aside from the cover), simply to familiarise yourself with the process, where you apply more-advanced techniques subsequently, once you have gained some confidence. This is advisable because trying everything at once could cause you to run into difficulties, which would invite discouragement – our greatest foe when dealing with technical matters.

Note too that, on reading this and the next chapter fully, you may wonder how, say, text alignment, which a section below covers, counts as an issue of cosmetic style. It is, after all, more an issue of positioning, and would seem therefore to be better suited to the next chapter, which considers layout. Similarly, the next chapter covers issues such as background colours and images, which would seem to be an issue of visual style more than one of positioning.

The reason, in the case of the examples cited above, is that aligning text occupies the shallows of text manipulation within CSS. This is all that the majority of e-books require, whereas an element's background falls more within the remit of the ‘box model’, which is a considerably deeper area that applies only to a minority of e-books, but which is pivotal in any discussion of layout.

The Problem

Around the mid 1990s, some of the major software companies of the time included support in their browsers for special tags such as <font> and <center> in order to allow control over how the content in a page appeared (in the browsers in question). However reasonable this may seem, it is a very unfavourable approach in reality. This is because it entangles styling and structural information, and this means that a change to, say, the fonts used across a system globally requires changes at many points throughout the HTML. This is tedious and time consuming, and is therefore error prone.

It means also that creating a fresh page entails coding all the styling information for that page anew, which is equally tedious and time consuming. Nor, without additional complexity, can you separate styling information that applies when rendering the content on a display device from that which applies when printing it on good-old-fashioned paper (of value​during the proofing stage). It also increases the size of the code and therefore the book-file as a whole, which, as​noted previously, you should limit in order to prevent that factor from eroding your revenues should you choose Amazon's 70% revenue scheme.

The Solution

Happily, the current version of HTML deprecates the presentational tags. This means that, in principle, you can still use them but you really should avoid doing so because e-reader manufacturers (and browser developers) may drop them at some point. By using them, you cannot guarantee that your book may render correctly on those user agents that have yet to exist.

Moreover, we do not need to rely on deprecated features because we have a considerably better alternative in ‘Cascading Style Sheets’ or ‘CSS’. Note that you can ignore the ‘cascading’ part of the term for the moment, as it relates to a rather rarefied issue that Appendix G​covers. Additionally, do not confuse the term ‘stylesheet’ with the concept of ‘brief style-guides’ within the sphere of writing techniques.

The core concept is that CSS allows you to define a set of styling and layout rules as textual entities that are separate from the HTML code to which they apply. Those rules tell the user agent how to style and position the content held within the HTML, and the following example demonstrates the essential idea:

<!DOCTYPE html>
<html>
   <head>
      <meta charset = 'UTF-8'/>
      <title>Chapter One</title>

      <style type = 'text/css'>

      p
         {
         background-color :  gray;
         font-family      : 'sans serif';
         color            :  lightgray;
         }

     </style>
   </head>

   <body>

      <p>
      Lorem ipsum ... est laborum.
      </p>

   </body>
</html>

If you are familiar with the material in Chapter Three, Structure, this should look little different to the examples given there, the exception here being the <style> element that is a child of the <head> element. The <style> element encloses some text that, expressed informally, says:

The user agent should display all paragraph elements with a background colour of grey, a foreground colour of light grey, and in a sans serif typeface.

Given that the <body> element contains a paragraph element, a user agent will render that according to the rules stated in the <style> element. Moreover, the rules apply to all other paragraphs that the page may carry, which means that a change to those rules will affect all those paragraphs automatically, which obviates tinkering with the HTML.

External Stylesheets

HTML also allows you to ‘import’ sets of styling rules arbitrarily into disparate HTML files, meaning a change to those rules will affect all elements concerned within the files in question. It means also that, should you set about developing a new book that you wish to style in the same way as an existing work, you need only import your existing style rules into the HTML files that comprise that new book. Given that an e-book is ultimately just a collection of simple, static web pages, you can use CSS to define a set of style rules just once, which you then apply to the entire corpus of HTML files that make up the various chapters.

To demonstrate this, consider the next example, which shows the style definition given in the previous example, but which places it in a file of its own that we can call, for example, MyBookStyle.css.

p
   {
   background-color :  grey;
   font-family      : 'sans serif';
   color            :  black;
   }          

Now consider the next example, which shows the HTML in the first example, but which replaces the <style> element, with a ‘<link>’ element (not to be confused with an <a> element, which you use to implement clickable links).

<!DOCTYPE html>
<html>
   <head>
      <meta charset = 'UTF-8'/>
      <title>Chapter One</title>

      <link rel  = 'stylesheet'
            href = '../Styles/MyBooksStyle.css'
            type = 'text/css'/>
   </head>

   <body>

      <p>
      Lorem ipsum ... est laborum.
      </p>

   </body>

</html>

The ‘rel’ attribute tells the user agent that the element relates to an external stylesheet, while the ‘href’ attribute performs the same role as the src attribute in <img> elements, in that it tells the user agent the name of the file. When a user agent renders this piece of HTML, it loads the stylesheet file, and applies the rules therein to the HTML, just as in the first example.

Note that the code (the ‘../’ bit, specifically) states the file's location as being in a sibling sub-directory of the directory in which the HTML file resides. This reprises the point that Chapter Three, Structure,​makes, which is that you should create a directory structure on your machine that replicates the organisational structure that Sigil/Calibre present. It follows that, before working on any CSS for your book, you should first create a sub-directory called Styles, and place any CSS files you create within that (even though most books require just one stylesheet). As pointed out before, you need the Fonts directory only if you will be using custom typefaces.

In the light of the points above, the CSS approach is far superior to the idea of dedicated styling-elements that this chapter explores initially, and now almost every modern web site that you visit on the Internet uses CSS to some degree. In fact, the language has grown to become complex and somewhat labyrinthine, which, thankfully, need not bother e-book producers because the majority of properties and principles concerned do not apply to e-books (and so e-readers simply do not support such properties).

To add to this happy confluence, the majority of e-books, especially the non-technical variety, have a simple structure based around chapters, titles (perhaps subtitles) and paragraphs, and so will never need advanced features, be they supported or not. This means that, if your e-book falls into that category, you need read only a few of the following sections, which consider the styling of text, before you progress to following chapters.

In fact, when developing an e-book, you should strive to keep your styling as simple as possible, and should plan to avoid trying overly ambitious ideas, as this will give you the least trouble. Simple books (the majority) pose no real problems, it is stepping off the beaten track that brings the challenges.

Rules & Definitions

To take a more formal look at CSS syntax, consider the following, which revisits the initial example above, and shows the anatomy of a typical piece of CSS code.

The essential atom of CSS is the ‘rule’, which takes the form of a keyword (a precisely defined term within the CSS lexicon) that describes some styling or layout property, followed by a colon and one or more values. Rules are gathered together in ‘definitions’, which are simply packets of rules that are delimited by opening and closing braces (or ‘curly brackets’ as they are also known).

When specifying values for the rules that you state, the format depends upon the property in question. Some properties, such as font-size, take just a single, numeric value that indicates the text size that you desire, while others, such as the text-shadow property, take a set of numbers that describe a particular shadow configuration. Still others, like text-align, take a keyword from a pre-defined set; and properties like background-image require the name of an image file.

Given this, the sections below and the next chapter explain the value-specifics for a given property on a per-property basis. Do note here, however, that you do not need to specify units when you stipulate a value of zero for a given property. A simple zero will suffice, as the following example shows (and which will make more sense if you consult the sections on margins, padding etc. in the next chapter):

margin : 0;

Note that all CSS keywords are lower case; note also the semi-colon at the end of the rules in the example above. You should treat this as mandatory, even though there is one situation in which it is not strictly required, so always put a semi-colon at the end of each rule that you create. Note also that the spelling of the property that, for example, governs text colour is ‘color’, not ‘colour’.

Remember too that re-defining a given rule within a definition will override the previous instance of that rule, as will re-defining it in a subsquent definition. In the following example, the second font-face rule will nullify the effect of the first:

p
   {

   font-family : 'sans serif';

   font-family :  serif;

   }

One additional point: CSS code can carry comments, which serve the same purpose as comments in HTML, but do note that CSS comments start and end with:

/*     */

Rather than:

<!--  -->

For example:

/*
This is a comment in CSS. User agents
ignore anything that appears between a
slash-asterisk and an asterisk-slash.
*/            

As with HTML, comments in CSS are useful for reminding yourself why you did something in a particular way, or for marking places that need further attention.

Selectors

Beyond rules and definitions, the third component in using CSS is the ‘selector’. A selector is a textual expression that precedes a definition, and which tells the user agent to which element(s) in an HTML file the definition applies. The set of selectors that are available in CSS is rich and varied, but it is highly likely that you will need to use only the most basic ones (mainly because user agents like the Kindle do not support the majority of the exotic selectors), and these are as follows:

1.

The Type Selector. Here you cite simply the name of an element – a tag-name without the angle brackets – which causes the renderer to apply the corresponding definition to all elements of that type.

For example, the following:

h1 { ... }

…will apply the definition to all <h1> elements.

2.

The Class Selector. All elements in HTML can carry an attribute called ‘class’, the value of which is entirely arbitrary and user defined (i.e. defined by you). Any element, irrespective of its type, that possesses a class attribute with a value that matches a given class-selector will be subject to that selector's corresponding definition.

That is, the following:

*.EmphasisedText { ... }
<p class = 'EmphasisedText'>
Lorem ipsum...
</p>

<a class = 'EmphasisedText'>Lorem Ipsum</a>

…will apply the definition to both the paragraph element and the link because they both possess a class attribute with a value of EmphasisedText.

However, the following, slightly different selector:

p.EmphasisedText { ... }

…will affect only the paragraph element because the EmphasisedText definition applies only to <p> elements. That is, this example demonstrates combining a type and class selector to yield finer control.

Do note that choosing good class names is part craft, part art, and does require a little experience, so do not expect to get it right first, second or even third time around. If you need some guidance, Chapter Six, Composition explores​the issue of good class-name choices, but do remember that many of the selector examples in this guide run contrary to the naming principles advocated in that chapter. This is because clarification of a given syntactic principle trumps proper semantics within the scope of this text.

3.

The ID Selector. The previous chapter, Structure, introduced id attributes in its​discussion of links, showing that they allow you to label a single element uniquely within a given HTML file. However, they also allow you to target CSS definitions at such elements. For example:

#ChapterHeading { ... }

Here the hash indicates that an ID selector follows, and the value ‘ChapterHeading’ indicates that the user agent should apply the definition to only the element with that id-attribute value (if it exists). Recalling from the previous chapter that the value of an id attribute must be unique within a page, do note that applying a CSS definition using an ID selector can only ever affect one element in a given HTML file.

In the light of these points, note that a single definition can be applied using multiple selectors, where each is separated by a comma. For example, the following:

h1,
h2 { ... }

…will apply that definition to <h1> and <h2> elements equally.

It is also possible to target a given element by applying one definition using a class selector, and by applying a second using an ID selector. In the following example, the first definition (contents not shown) applies to everything that has a class-attribute value of EmphasisedText, whereas the second definition applies only to the one element that has the ID of CoreThesis. Given that that element also has a class-attribute value of EmphasisedText, both definitions will affect it.

*.EmphasisedText { ... }
#CoreThesis      { ... }
<p class = 'EmphasisedText'> ... </p>
<p class = 'EmphasisedText'
   id    = 'CoreThesis'    > ... </p>

Note too that it is possible to apply definitions in a very limited fashion without using selectors, as the next example shows:

<p style = 'background-color : gray;'>
Lorem ipsum ... est laborum.
</p>    

Here the paragraph element carries a ‘style’ attribute, which carries a CSS rule that stipulates the background for that paragraph. The user agent will apply that style to that paragraph alone, and this is called an ‘inline definition’.

However, while this example shows that you can apply styling on a spot basis, it is an approach that you should avoid, as it reprises the problem explained above that is inherent in using special HTML styling tags. That is, conflating styling information with structure and content invites trouble. In general, it is far better to gather all your definitions in a <style> element and/or in a discrete file (i.e. ‘out of line’), and to apply them using selectors.

Note that a sizeable number of books and web sites that consider e-book production use inline definitions as a matter of course, seeming to perceive the idea of centralising your CSS definitions in a single place as if that were a secondary concern. Yet this is why we have selectors: they give us action at a distance, from a single locus, thus yielding great power with great simplicity.

This underscores strongly the​argument in Chapter One that discounts supposed short-cuts such as, say, saving your content within MS Word as HTML as the initial production step. That is, if you examine the HTML that you generate in this way (note: that you generate… at arm's length), you will see a mass of inline definitions, which are present because the program cannot ‘reason’ about the semantic roles that different elements play. It cannot therefore factor the commonalities that are present into a single set of CSS definitions that cover the entire manuscript.

This is why Chapter One asserts that machine-generated code can never be simpler than the code that you can produce (having acquired a bit of understanding from resources such as this text), and that it will always be bigger to boot.

The remainder of this chapter considers styling text, which for most e-book producers comprises the bulk of any CSS that they apply. If you need to apply more advanced styling, in terms of layout rather than cosmetic appearance, you should turn to the next chapter, Layout,​which considers these more advanced areas of CSS.

As a preamble to the sections below, do note that many people misuse the term ‘font’. To talk about, say, Times New Roman, Courier or Bembo is to describe typefaces, as in the shapes of the glyphs in question. In contrast, a ‘font’ is a combination of typeface, size and other modifying attributes such as emboldening. That is, Times New Roman is a typeface, whereas italicised Times New Roman rendered at 11 points in size is a font.

Textual Emphasis

As the previous chapter showed, you can embolden text and render it in italics by the use of the <b> and <i> tags respectively. HTML also supports the <s> and <u> elements, which will render their content with a struck-though appearance, or with an underscore, but these are not valid in an EPUB file, which means you cannot use them in any e-books that you wish EPUB retailers to accept.

The alternative therefore is to use the <span> tag, which the next chapter considers​in greater detail, and which you can regard as a general-purpose tag that confers no stylistic information of its own, but which acts as a way of delimiting a word or phrase to which you wish to apply specific effects.

Using a <span>, you can use the text-decoration property to apply effects such as underlining, and the CSS standard defines this property as taking one of five values. These are:

Note that blink is a throwback to the early days of HTML and the Web, and (thankfully) user agents are not required to support it.

The following example shows the use of the <span> element in conjunction with a CSS definition, to strike-through a run of text:

span.StruckThrough { text-decoration : line-through; }
Lorem <span class = 'StruckThrough'>ipsum</span> dolor
Lorem ipsum dolor

Building on this, the next example shows how you combine different textual emphases – you simply embed one span within another:

span.StruckThrough { text-decoration : line-through; }
span.Underscored   { text-decoration : underline;    }
Lorem <span class = 'StruckThrough'>
      <span class = 'Underscored'>
      ipsum
      </span>
      </span>
dolor...
Lorem ipsum dolor...

Note that this is an example of the ‘subsumption’​principle pointed out in Chapter Six, Composition. That is, to achieve a given effect, a useful approach is to contain or subsume one element within another, and then to apply one definition to the containing element, and another to the contained.

Font Size

To set the size of a piece of textual content, you should use the font-size property, and here the question of units enters the equation. While you can set text size in an absolute manner by, say, stating a certain number of pixels, this is inadvisable in e-books because people read them using a wide variety of display technologies. A Kindle Touch has a 600 × 800 screen, whereas the current ‘Retina’ displays give resolutions up to 5120 × 2880 pixels.

This means that text set in the following manner:

 font-size : 20px;

…may be fine on a Kindle Touch at its mid-range setting for text size, but it will be impossibly tiny on a very high-resolution device, which will require the user to increase the text size in order to render the text readable. Instead, the favourable approach is to specify text size using relative units, and this is the purpose of the ‘em’ and percentage units that CSS supports.

In the case of percentages, you can set text size as follows:

h2 { font-size : 120%; }
<h2>Lorem ipsum dolor</h2>

Lorem ipsum dolor

…which sets the text to be one hundred and twenty percent of the text size set for the parent (or ‘enclosing’) element.

That is, if the body element's text size is be 20 pixels in height (as calculated by the user agent – not taken from any pixel-unit font-size for that element), and all paragraphs in that element are set to be 120% of the parent's text size, text in those paragraphs will be rendered at 24 pixels high. You can test this now by changing the text size on the browser you are using currently to read this guide. As you increase it, the size of the <h2> element in the example above will increase accordingly, whereas decreasing the text size will see a concomitant decrease.

The em unit (more accurately, the ‘em-height’ unit) corresponds to the height of the letter ‘M’ in the font in question. This operates in the same proportional manner as percentage units, in that 1em is the equivalent of 100%, and 1.2em is the equivalent of 120%, and so on.

For example:

h2 { font-size : 1.8em; }
<h2>Lorem ipsum dolor</h2>

Lorem ipsum dolor

You may wonder why ems and percentages are both available, given that an em value corresponds numerically to a percentage value. The difference is that the metric of which a given percentage value represents a proportion depends on the CSS property in question. That is, if a percentage is used to set, say, the width of an element, the value given expresses a proportion of the enclosing element's width, not the enclosing element's text size, as in the example above.

It follows that you could set a width using ems, which would then relate the rendered width of the element in question to its parent's text size. Indeed, it is by these means that we can lay out our content, and set other parameters, independently of the device on which the user is consuming the content (and note that the next chapter considers widths, heights etc. in great detail).

The second point of note here is that relating size (in any meaning of the word) to the size of the corresponding property for the enclosing element is called ‘inheritance’. That is, without an explicit setting for font-size on your part, a given element will inherit (acquire automatically) its font-size value from its parent. Elements inherit values for various CSS properties, not just font-size, unless you change those settings explicitly, and you should consult a comprehensive reference if you desire fine detail here.

A minor, final point in this section: you will see the value 1.0em in some of the CSS examples in this guide, and while the ‘.0’ part is unnecessary, the examples use this form in order to align values precisely within their definitions, which maximises readability for you.

Aligning Text

The need for control over the position of certain textual elements in a book is common, and the first CSS property to explore in this respect is text-align. This property takes one of four values, which are:

Given that, the following gives an example of centring a chapter heading:

h1 { text-align : center; } 
<h1>Lorem Ipsum</h1>

Lorem Ipsum

The next example shows the same heading aligned to the right:

h1 { text-align : right; } 
<h1>Lorem Ipsum</h1>

Lorem Ipsum

You can apply this property to elements other than headings. For example, applying it to paragraphs with a value of center, yields the following:

p { text-align : center; } 
<p>
Lorem ipsum dolor ... ea commodo consequat.
</p>   

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Some people prefer to denote paragraphs by indenting their first line, rather-than/in-addition-to separating them vertically, and if you wish to achieve this effect, you should use the text-indent property. Consider the following example:

#SmallIndented  { text-indent : 2%; }
#MediumIndented { text-indent : 4%; }
#LargeIndented  { text-indent : 8%; }    
<p id = 'SmallIndented'>
Lorem ipsum ... est laborum.
</p>

<p id = 'MediumIndented'>
Lorem ipsum ... est laborum.
</p>

<p id = 'LargeIndented'>
Lorem ipsum ... est laborum.
</p>

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...

Note that the early generation Kindles indent the first line of paragraphs by default. If you are targeting those older devices, and you do not desire this behaviour, you can apply a text-indent of zero to all paragraphs. That is:

p { text-indent : 0; }

A final point in this section: the previous chapter​notes the defect in at least some Kindles, where text held within a <pre> element that is longer that the lateral extent of that element wraps around, when it should not. While this does not relate strictly to text alignment, this section is the most appropriate in which to consider this issue, and the remedy is to use the word-wrap property, giving it, bizarrely, a value of ‘normal’.

For example:

pre
   {
   word-wrap : normal;
   }

Line Height

You can also apply a line-height property to textual elements, which in terms of traditional print equates to the ‘leading’ (after the little strips of lead that traditional typesetters would place above and below words and phrases in order to adjust the vertical offset).

The line height can be expressed using units, such as a percentage, or as simply a number that represents a proportion of the height of the content that the element encloses. Given this, the user agent:

1.

Determines that height using the height of the font that applies to the element in question.

2.

Multiplies that height by the value of any line-height property.

3.

Subtracts the actual height of the content from that value.

4.

Divides it by two.

5.

Adds half of the result to the top of the element's content, and half to the bottom.

That is, the overall height of an inline element is determined as follows:

Leading     = (ContentHeight × line-height) - ContentHeight
TotalHeight =  ContentHeight + Leading 

For example:

#SpanElement_BigLineHeight
   {
   background  : #B0B0B0;
   line-height : 1.5;
   border      : 3px dashed #606060;
   }
<p>
Lorem ipsum dolor sit amet,
consectetur adipiscing elit,
<span  id = 'SpanElement_BigLineHeight'>
sed do eiusmod tempor
</span>
incididunt ut labore et
dolore magna aliqua. Ut enim
ad minim veniam, quis
nostrud exercitation
ullamco laboris nisi ut
aliquip ex ea commodo
consequat.
</p>

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Styling Lists

CSS defines three properties that support specifically the styling of lists, which are:

list-style is the shorthand property that allows you to specify type, position and image in one rule, but you may find it easier to use the other three properties piecemeal-fashion (as with the background​shorthand property). The next example shows an ordered list where application of list-style-type causes numbering of the items using lower-case letters.

ol.LowerAlphaMarker { list-style-type : lower-alpha; }
<ol class = 'LowerAlphaMarker'>
   <li>Lorem</li>
   <li>Ipsum</li>
   <li>Dolor</li>
</ol>    
  1. Lorem
  2. Ipsum
  3. Dolor

Note here that the CSS standard enumerates a great many different types of marker, so you should consult a comprehensive reference for the full set. Do remember, however, that support for the more exotic ones in web browsers is unreliable, and so you can count on even greater unreliability in e-readers.

In a similar vein, the list-style-image property allows you to use a custom graphic in place of the markers that user agents support natively. Unfortunately, this property is of little value as it gives poor control over the positioning and scaling of the graphic that you employ. There is, however, an alternative approach that gives you full control, and the next chapter, Layout, explores this in its discussion of background images and padding.

Colour

The issue of colour in both traditional printing and modern electronic rendering is a complex area, and the capabilities of e-readers introduce additional concerns because some possess colour, luminescent displays that have a wide colour-gamut, whereas others use monochrome, reflective technologies that have a restricted grey-shade gamut. This is not to say that you should avoid colour in your e-books, but it does mean that you should be circumspect in the choices you make. Chapter Six, Composition, covers​the factors you need to consider in this respect.

You can express a colour value in a number of ways, and do note that these operate in an equivalent fashion, whether applied to text or to backgrounds and borders, which the next chapter explores in detail.

1.

Keyword Values. CSS supports colours specified by name, such as black, green, white, and so on. For example:

color : green;

The CSS standard defines 147 named colours in all, and if you wish to apprise yourself of these, the search-terms suggestion is as follows:

css colour keywords list

2.

Decimal Values. You can use the following expression:

rgb(RR, GG, BB)

…where RR, BB and GG stand respectively for the red value, the blue value and the green. You can express those as three numbers between 0 and 255, where larger values indicate greater amounts of the colour in question. That is, a value of zero for all three corresponds to pure black, whereas a value of 255 for all three will render as pure white. (If you are curious as to the reason for the seemingly arbitrary maximum of 255, Appendix F, Unicode and All That explains​things from the ground up.)

3.

Percentage Values. You can specify the amount of red, green and blue as a percentage between 0 and 100 (from nothing to as much as possible). For example, you can give a run of text the colour of mid-grey by using the definition given in the following example:

 p.MidGreyText { color : rgb(50%, 50%, 50%); }
 <p class = 'MidGreyText'>
 Lorem ipsum ... magna aliqua.
 </p> 

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

An extended form of this method is possible too, where you use the rgba quantifier instead, where the ‘a’ stands for ‘alpha’, and where you provide a fourth parameter that specifies the opacity of the property in question. This must be a number between zero and one, where zero means zero opacity (i.e. full transparency, which renders the element invisible), and where a value of one means full opacity (i.e. zero transparency). This means that a value of, say, 0.333 represents one-third opacity.

Clearly, this opens up a range of creative possibilities, as the next example shows:

p.SemiTransparentText { color : rgba(50%, 50%, 50%, 0.5); }
<p class = 'SemiTransparentText'>
Lorem
</p> 

Lorem

Do not worry for the moment how the shaded tiles are implemented (the property at work here is background-image, which the next chapter considers); do note that the edges of the tiles are visible through the glyphs in the word ‘Lorem’.

4.

Hexadecimal Values. A third method is to state your desired colour as a hash followed by a triplet of two-digit numbers expressed in base 16 (or 'hexadecimal'), where each pair of digits corresponds to the amount of red, green and blue, and can have a minimum value of 00 and a maximum of FF. For example:

h1 { color : #808080; }
<h1>
Lorem Ipsum
</h1>

Lorem Ipsum

As the previous chapter​states, do not let the concept of ‘base 16’ worry you – again, consult​Appendix F, Unicode and All That, should you need clarification of what it means and why such technicalities pervade computing-related matters.

Fonts

E-readers come supplied with a relatively limited set of typefaces, thus giving users some control over the rendering of the text they read. As Chapter Six, Composition, points out, you should not usurp this by forcing the rendering of body text in a typeface other than one of the defaults. However, when presenting chapter headings, subtitles and other elements of your content, you may present them in a typeface of your choosing. Indeed, this is one path to giving your book some distinctive styling, and an example in this guide is the use of Lucida Casual for chapter headings and the like.

In the early years of CSS and HTML, web site developers were limited in the choice of typefaces that gave some guarantee that a given page would render in essentially the same way across all browsers on all computers. This was because only a sub-set of all the computers in the world could be guaranteed to possess a given typeface such as, say, Verdana or Times New Roman. Without the ugly workaround of using images to display text, this placed miserable limits on the scope for distinctive and artistic designs.

Happily, however, modern CSS now gives you the ability to embed typeface information (or ‘font files’) within a web page, and we enjoy support (with caveats, see below) for this in modern e-readers too. Consider the following example (and note that the ‘Publisher Font‘ option must be selected in your user agent for this demonstration to make sense):

@font-face
   {
   font-family : 'Tangerine_Regular';
   font-weight : normal;

   src         : url('../Fonts/Tangerine_Regular.ttf');

   }

h1.CustomTitle { font-family : 'Tangerine_Regular'; }
<h1 class = 'CustomTitle'>
Lorem Ipsum
</h1>

Lorem Ipsum

Here, the @font-face statement is called an ‘at rule’, and it tells the user agent to import a file called Tangerine_Regular.ttf that is held in a sub-directory called Fonts. It gives that typeface a font-family value of Tangerine_Regular, which allows us to use that name as a font-family value in other CSS definitions. You can see this in action in the definition that follows, which applies to all <h1> elements that have a class value of CustomTitle. This affects therefore the <h1> element in the HTML fragment that follows, and you can see the effect of this in the final panel in the example.

There are a number of additional points of which you should be aware in the area of font embedding:

1.

If you intend to render text in a given, non-default typeface, where some of that text should be emboldened, you must provide a font file that caters for the bold version of the typeface in question, as well as the normal version. You achieve this by providing a second @font-face definition, as the following example demonstrates:

@font-face
   {
   font-family : 'Tangerine_Regular';
   font-weight : normal;

   src         : url('../Fonts/Tangerine_Regular.ttf');

   }

@font-face
   {
   font-family : 'Tangerine_Regular';
   font-weight : bold;
   src         : url('../Fonts/Tangerine_Bold.ttf');

   }

The second definition now allows you to render emboldened text in your choice of typeface, as the next example demonstrates:

h1.CustomTitle_Bold
   {
   font-family : 'Tangerine_Regular';
   font-weight : bold;
   }

Here the font-weight : bold rule will cause the user agent to use the font stipulated in the second @font-face definition in the example above. The same argument applies to any italicised version of a typeface that you wish to use.

2.

If your book uses only a few glyphs in a given font file, the rest of the glyph information in that file will increase the size of the deliverable redundantly. In this case, an alternative is to replace the glyphs you do use in the text with an SVG image, or to embed only a subset of the font file in question. See Appendix E,​Working with SVG, for more information (which also covers using custom fonts in SVG images).

3.

If you intend to target older Kindle devices in addition to the modern ones, you should nominate a fall-back typeface, in case someone reads your book on an older device that does not support font embedding. For example, if the custom typeface is called Lucida Casual, the font-family rule should look like this:

*.Sidebar
   {
   font-family : 'Lucida Casual', serif;
   }

This means that, if the user agent does not support font embedding, the text that the definition above targets will at least be in a serif typeface.

4.

There is currently a defect on at least some Kindles, such that @font-face declarations in the <head> element in a given HTML file are ignored. That is, if you wish to use an embedded font file, the corresponding @font-face declaration must go in an external stylesheet, otherwise it will have no effect.

5.

Do ensure that the value you give for the font-family rule in any @font-face directive is exactly the same as the file name you give in the src rule. That is, in the example given above, the font-family rule is thus:

font-family : 'Tangerine_Regular';

...and the corresponding src rule is thus:

src : url('../Fonts/Tangerine_Regular.ttf');

6.

Not all font formats work on Kindle-flavour user agents. That is, font files can be encoded in one of a few ways, PostScript (Type 1) being one format, while True Type (TTF) and Open Type (OTF) are two other common formats. Amazon discourages the use of Postscript fonts, and states that any text that is formatted using them will be rendered using one of the defaults that the user agent in question carries. This leaves TTF and OTF, but people (on the Mobile Read and KDP forums) have reported problems with the OTF variety on Kindle user agents, which means it is best to stick to TTF only.

Some, however, have reported also that not all TTF fonts will render correctly, citing Papyrus (used by James Cameron in his film Avatar) as one example, and people have reported problems with others (strange visual effects and the like), so do be prepared to use an alternative if you find during testing that a given font just will not play ball.

7.

When you upload a book to Amazon, that company's systems perform some processing (of indistinct nature, see below) on the file in question before making it available on a product page. There is currently an egregious and long-standing defect in the software that performs that processing, such that any embedded font files the book possesses may be removed (and where the corresponding CSS code may be altered too). This causes any content that should be rendered in a given custom font to be rendered using one of the default typefaces that the user agent carries, thus degrading the presentation of the content.

The factor(s) that cause(s) the defect to manifest are unclear because not all books are affected, and there is no discernable pattern to those that are and those that are not, but this is a serious problem that Amazon should rectify post haste (and it is truly baffling why the company has let the situation persist for so long). Until it does, however, and if you use one or more custom fonts in your book, you will have to employ a workaround that will foil this evil bug.

The requisite technique is simple, and entails using an additional stylesheet file that exists solely to import the actual stylesheet file(s) into a given HTML file, where all the HTML files that comprise your book link to that intermediary (and to no other stylesheet files) even if a given HTML file is not subject to any explicit styling.

For example, if you have a single stylesheet file called StyleSheet.css, you should create a second file called, say, StyleSheetImporter.css. That file should contain an ‘@import‘ directive (another ‘at rule’) that tells the user agent to pull-in StyleSheet.css. Note that it need contain no other CSS rules.

That is, you would change the following:

/* ----- StyleSheet.css --------- */

/*

Imagine some normal styling definitions here

*/
<!-- === Chapter_One.htm ======= -->

<!DOCTYPE html>
<html>
   <head>
      <meta charset = 'UTF-8'/>

      <link rel     = 'stylesheet'
            href    = '../Styles/StyleSheet.css'
            type    = 'text/css'/>

      <title>Chapter One</title>
   </head>

   <body> ... </body>

</html>

…to this:

/* ----- StyleSheet.css --------- */

/*

Imagine some normal styling definitions here

*/
/* --- StyleSheetImporter.css --- */

@import url(../Styles/StyleSheet.css);
               
<!-- === Chapter_One.htm ====== -->

<!DOCTYPE html>
<html>
   <head>
      <meta charset = 'UTF-8'/>

      <link rel     = 'stylesheet'
            href    = '../Styles/StyleSheetImporter.css'
            type    = 'text/css'/>

      <title>Chapter One</title>
   </head>

   <body> ... </body>

</html>      

It follows that, if your book uses multiple stylesheet files, StyleSheetImporter.css should contain additional @import directive to pull-in those other files too.

Note that this technique is not guaranteed to work, and if you find that it fails you, a variant is to put the at rule(s) that import(s) the font file(s) into StyleSheetImporter.css, after the at rule that imports StyleSheet.css.

On the question of why Amazon should wish to perform any kind of processing on the books that publishers upload (other than, for example, separating a Mobi/KF8 file into its separate Mobi and KF8 components): it seems that this is in place so as to ‘sanitise’ e-book files that have been generated from the low-grade HTML that wordprocessors and tools such as InDesign create, such that the content in question renders as best as possible.

This is all very well (and it would be unecessary were it not for the point-and-click brigade), but it is galling for defects in that company's software to mangle a book that has been formatted carefully and conscientiously using the professional techniques advocated here. Having to work around the defects in its user agents is bad enough, but having to work around bugs in its post-upload system is beyond the pale; and note that the damage can go further than the deletion of font files. Tests​with the e-book version of this guide revealed that Amazon's system edits the CSS definitions that give certain HTML elements a white background (the color rules are simply deleted).

Presumably those who developed Amazon's post-upload processor thought that elements with white backgrounds must be redundant because the default background colour in a user agent is white. It never occurred to these fools that an element with a white background may be nested within an element that has a non-white background, as is the case at points in this book. (The fix in this case is to set the colour to very slightly off-white. That is: ‘background-color : #FEFEFE;’)

A final point: recognition is due to the individual who discovered the workaround for the font-stripping bug, and who posted it on the KDP forum on the Internet under the name Teo Kos on 29th August 2015.

Text Shadows

With version three of CSS came the welcome ability to cast shadows around letter glyphs by using the text-shadow property. Consider the following demonstration:

h1.SharpShadowedTitle
   {
   color       : #000000;
   text-shadow : 0.04em 0.04em 0      #404040;
   }

h1.BlurredShadowedTitle
   {
   color       : #000000;
   text-shadow : 0.04em 0.04em 0.03em #404040;
   }
<h1 class = 'SharpShadowedTitle'   >Lorem Ipsum</h1>
<h1 class = 'BlurredShadowedTitle' >Lorem Ipsum</h1>

Lorem Ipsum

Lorem Ipsum

The first example shows that the first two values of a text-shadow rule determine the vertical and horizontal position of the shadow. That is, you can think of text-shadow as throwing a shadow of the same size and shape as the text directly underneath the text, where the first value in the rule offsets the shadow's position along the horizontal axis, and the second offsets it along the vertical axis (zero values yielding no offset).

The third value constitutes a blur factor, as the second sample shows, which must be a non-negative integer (the bigger the number, the greater the blur), and the fourth value determines colour. Note that, if you omit the colour value, the user agent will use the colour of the text. Note too that at least one popular reference states that text-shadow accepts an additional value in the fourth place (which would make colour the fifth value), which is said to determine the size of the shadow. This is incorrect; the property takes only four values.

The text-shadow property is very versatile, as it is possible to apply more than one shadow using multiple value-sets for a given text-shadow rule, where each set is separated by a comma. Moreover, shadows can be light as well as dark, and this means that application of light and dark shadows to the same element can generate surprising and very pleasing effects.

Consider the next example:

h1.OutsetTitle
   {
   font-family :  Tangerine;
   font-size   :  6em;

   color       : #B0B0B0;

   text-shadow : -0.01em -0.01em 0.00em #C0C0C0,
                 -0.02em -0.02em 0.01em #FFFFFF,
                  0.01em  0.01em 0.01em #202020,
                  0.01em  0.01em 0.00em #000000;

   }

Lorem Ipsum

The embossed effect you see – a large-scale example of which is given in the sidebar below – is achieved by applying two light-coloured and two dark-coloured shadows. The first, light shadow is offset to the top and left by just a fraction of an em, and the second slightly lighter one is offset to the top and left by just a little more.

This has the effect of aggregating the light shadow along a diagonal direction, which gives the impression of what is called ‘specular’ reflection (as opposed to diffuse reflection), as if the light source were to the top-left, highlighting the supposedly-raised edge of the glyphs. To complement this, the CSS code places two darker shadows to the bottom right, one slightly darker than the other, offsetting the darker a little more, just as with the light shadows. This gives the impression of the bottom-right-facing edges of the supposedly raised letters being in shadow.

Note that it is necessary to use a number of shadows because just one white and one dark does not yield a very noticeable effect, and offsetting single shadows by a larger distance puts a visible gap between the character glyph and the shadow in question when using thin-stemmed typefaces (like the one used here). Note that the order of the values list for the text-shadow rule is critical, and that including a tiny bit of blur to two of the value-sets softens things a little, giving a more ‘rounded’ appearance to the apparent embossing, which works better at large text sizes. (An additional note here, which is that the large version displayed in the sidebar is, in fact, a JPG image, which is used here because of a rendering defect that manifests on some Kindles when super-large characters are displayed in certain typefaces.)

Note too that the general rule, if you intend to pursue this effect, is that the light shadows must be lighter than anything else, and the dark shadows must be darker than anything else. It follows that a pure white or pure black background will not work.

Now consider the next example,

h1.InsetTitle
   {
   font-family :  Tangerine;
   font-size   :  6em;

   color       : #606060;

   text-shadow : -0.015em -0.015em 0.01em #000000,
                  0.015em  0.015em 0.01em #ffffff;

   }

Lorem Ipsum

This demonstrates a technique that gives what is known as a ‘letterpress’ effect, and it is surely a stony soul on whom its appeal is lost.

Notably, it works slightly better on e-ink rather than luminescent displays, and as with the preceeding embossed example, the sidebar shows the effect on a large scale in order to facilitate understanding. Essentially, it is the inverse of the embossing technique, and it implies again that the light source is to the top-left. Here, however, only two shadows are necessary, and it is the darker shadow that is offset slightly to the top and left, while the lighter one is offset by a fraction in the opposite direction, where a tiny bit of blur on that shadow smoothes things beautifully at large scales.

Note that the colour of the text itself is lighter than the top-left shadow, and darker than the bottom-right, and that, as with the previous technique, a wholly white or black background will negate the effect. That is, the text must be darker than the background, and the top-left and bottom-right shadows must be darker and lighter respectively than anything else. (Note here that, as with the previous large-scale example, the sidebar is a JPG image, used again in place of a native rendering due to a defect that manifests on some Kindles when super-large characters are displayed in certain typefaces.)