From the book
From the book
From the book
Cleaning up InDesign EPUB files
I think InDesign is a really powerful tool for creating EPUB files, but it’s nowhere near perfect—at least not yet. In this section, I’ll show you how to clean up the EPUB files that InDesign produces. Even if you haven’t used InDesign, you may find some useful tips. To edit InDesign’s files, you’ll have to unzip the EPUB as described in “Unzipping an EPUB” in the previous chapter.
How InDesign writes XHTML
When InDesign exports a document, it generates style information in a very specific way. First, it creates one large div element whose id is the title of your InDesign file. It then creates another div, with a class of generated-style for each frame, in order, from left-top to bottom-right. Images are exported into divs of their own with a class of generated-style-2 while grouped items, unsurprisingly, get divs with a class of group. Lines and shapes are ignored outright. (If a document begins with an image, the img elements are enclosed in generated-style classed divs while the text frames are enclosed in generated-style-2 divs.) All generated-style classes may be deleted.
)
In CS5, the way the actual text is exported depends directly on whether or not you’ve defined a TOC style (see “Creating a Table of Contents Style” in Chapter 2). If you have, and if you’ve selected that TOC style upon export (see “Export EPUB from InDesign” in Chapter 2), then the InDesign paragraph styles selected to generate the TOC will be exported as headers (h1, h2, and so on), while every other paragraph—even Bulleted and Numbered lists—will be exported as a p element. (If you have not defined a TOC style or don’t choose it when exporting, or if you’re using CS4, everything is exported as a p element.) Regardless, all header and p elements get a class equal to the name of the paragraph style in InDesign.
InDesign also inserts an xml:lang attribute into every single element to specify the element’s language. You may search and delete these.
Character styles are exported as span elements with the InDesign character style name as a class attribute.
)
Local formatting (which is ignored in CS4), is exported as a span with a class of no-style-override. Sometimes, InDesign creates generated-style classes in span elements as well. These can be safely deleted.
How InDesign writes CSS
The CSS files that InDesign generates will depend directly on the choices you make when you do the export. You can always control the process completely by choosing Style Names Only or Use Existing CSS File upon export. The first option will output a CSS file with each InDesign style mapped to a class with the same name, attached to a p or header element. You can then define the style rules manually. The second option lets you choose a predefined CSS style sheet that will be used in the EPUB. If you often use the same style sheet, this may be the most effective option as long as you make sure the CSS classes match the style names in the InDesign document. In this example, nevertheless, we’ll assume that you’re using InDesign to generate the style information in the CSS style sheet.
- Just as InDesign creates extra generated-style classes in the XHTML, it creates empty style rules for these styles as well. I think it’s best to get rid of them.
)
Next, for each paragraph style, InDesign creates a set of style rules that defines each of the following properties, whether you’ve defined a value for that property in InDesign or not: font-family, font-weight, font-style, font-size, line-height, text-decoration, font-variant, text-indent, text-align, color, and margin. Indeed, it only creates values for those 11 properties, and all other aspects of the style—even features that CSS and InDesign support in common—are ignored.
For example, imagine the header style in the Walden document, defined to have green, 36 point, bold text set in Cochin, centered, with 1 pica of space before and 12 picas after.
)
When InDesign exports this style information to CSS, it gets much of it right, but unfortunately, it erroneously offers default values for properties that weren’t explicitly defined. In this example, that’s line-height, text-decoration, font-variant, font-style, and text-indent.
h1.header {
font-family: "Cochin";
font-weight: bold;
font-style: normal;
font-size: 3em;
line-height: 1.20em;
text-decoration: none;
font-variant: normal;
text-indent: 0em;
text-align: center;
color: #1c910a;
margin: 0.33 0 4em 0;
}
- Unfortunately, because of CSS inheritance, a default value is not neutral. Instead of not defining, say the text-decoration, this CSS specifically says “make sure there is no text decoration”. I recommend eliminating these extraneous and sometimes harmful declarations. After the changes, the rule
will look like this:
h1.header { font-family: "Cochin"; font-weight: bold; font-size: 3em; line-height: 1.20em; text-align: center; color: #1c910a; margin: 0.33 0 4em 0; }
Remember that an em is a curious measurement. When used to specify a font size, as the 3em in the previous code, it means 3 times the size of the parent element’s font size. The parent element in this case is a div which gets its font size from the body, which in iBooks and in many websites, is 16 pixels by default. So the h1 element here would end up 48 pixels high (3 × 16 pixels).
When you use ems for line height, text indents, and margins, however, one em equals the font size of the current element. So, the specified 4 em for the margin-bottom, since the font size is 48 pixels, will be 192 pixels.
InDesign doesn’t always use the same font names that the iBooks app supports. For example, if you choose the Bradley Hand font for a style in InDesign, the exported CSS uses "Bradley Hand ITC TT" but iBooks will only understand "Bradley Hand" or BradleyHandITCTT (with no spaces). You can find the full list of official names in “Fonts in your ebook” later in this chapter.
- Make sure the value for the font-family property is the official name for that font, as given in the list in “Fonts in your ebook”.
- Repeat these steps for each set of rules in the CSS document.
Maintaining InDesign inheritance in the CSS
InDesign lets you base multiple styles on a single foundational style. Then when you change the foundation style, all of the styles that depend on that foundation are also updated. It’s a very useful feature. For example, in this book that you are reading, I have formatted all of the code examples with variations on a single InDesign style called code. The base code style includes font information and basic indenting. The code-first style includes everything in code, and adds a rule above. The code-last includes everything in code, but adds a rule below. And so on. You get the idea.
CSS has a similar functionality. You might assign a number of style rules to the p element, and then add additional style rules to only those p elements of class code-last, for example. In addition, CSS applies inheritable styles automatically to elements contained within other elements. For example, if there is an em element within a p element, the contents of the em element may inherit styles applied to the p element. Whether or not a style rule is inherited is determined by the property’s characteristics (and sometimes on whether or not you choose to make it inheritable).
Unfortunately, and as you might expect, InDesign doesn’t take advantage of CSS’s inheritance features. As we’ve just seen, InDesign creates separate, independent sets of style rules for each and every style in your InDesign document. Not only that, but it sets the default values for several properties, even though these are not necessarily defined in InDesign. Further, it does not reflect the inheritance of one style on another in the exported declarations. This is a shame and can be remedied.
I have developed a technique for maintaining the inheritance in InDesign styles in the CSS styles that InDesign exports.
- In InDesign, create the base style and title it with a single lowercase word. My base style is called code.
- Still in InDesign, create the styles that are based on the main style and title them with the same lowercase word used for the base style, plus a space and a single word modifier. For example, code first, code last, code both, etc.
- Style the text in your document with the InDesign styles and export to EPUB as usual. InDesign converts the space in the style
names to a hyphen.
<p class="code-first">h1.header {</p> <p class="code-m2">font-family: "Cochin";</p> <p class="code-m2">font-weight: bold;</p> ... - In the generated CSS file, eliminate any default values from the base style that you do not want to declare explicitly.
p.code { font-family: "AmericanTypewriter"; font-size:.8em; line-height: 1.2em; text-align:left; margin:0 5% 0 5% !important; background: #f8dddd; width: 90% !important; } - Still in the CSS, eliminate the base style name from the child style rules. (In this example, code-first becomes just first; code-m2 becomes just m2.) Then, simplify the child rules so that they contain only those declarations that are above and beyond what is defined in
the base style.
.first { border-top: 2px dashed red; padding-left: 1%; padding-top:.2em; padding-bottom: .2em; } .m2 { text-indent: -5%; padding: .2em 0 .2em 11% !important; } - In the XHTML file, use search and replace to convert the hyphen that separates the base name from the child name into a space.
Now, each of the two words are independent classes and both will be applied to the paragraph. In this way, both the base style and the child style will be applied to the affected paragraphs.
<p class="
code first">h1.header {</p> <p class="code m2">font-family: "Cochin";</p> <p class="code m2">font-weight: bold;</p> ...
)
Now when you change the rules for the base style in the CSS, all of the paragraphs that depend on that rule will be affected. At the same time, each paragraph will continue to be individually affected by the child rule that applies to it.