InDesign CC - Embedding Fonts

One of the most appreciated improvements to InDesign with the new Creative Cloud edition is that it finally embeds fonts in a way that iBooks understands. Let's take a look.

In InDesign, there is always some font chosen for text. You can't have "none". When you export a book to EPUB, the default is for InDesign to "Include Embeddable Fonts"



The problem is that InDesign CS 6 doesn't do it right. Whether it's Adobe's fault or Apple's or the IDPF's, I've never been quite sure, but the truth is that there were two major problems: the font didn't get obfuscated properly and InDesign didn't account for iBooks' idiosyncracies (read: non-standard font requirements).

So, given this InDesign document:



InDesign CS 6 exports a file to EPUB that looks like this in iBooks:



My design surely lacks penache (it was designed to take advantage of the fonts that were available on the iPad in 2010), but if that's what I want, that's what I want InDesign to give me.

Now InDesign CC does. Notice both the Bradley Script for the headers and the Optima for the body text.



I heard that it finally got the obfuscation right (or in accordance with Apple), but the coding news is that it also caters to Apple's requirement of including the com file in the META-INF folder.



And here's what it looks like on the inside:



Apple's com file is totally non-standard (that is, not part of the EPUB3 spec), but regardless, if you want fonts to work in iBooks with an EPUB 2 file, that's what you need, and I think Adobe made a great decision by including that file automatically so we don't have to crack open the EPUB to add it ourselves. Since the com file doesn't affect other ereaders or validation, there's nothing to be lost in adding it, and everything to be gained.

Note that I said EPUB 2, but InDesign CC actually includes the com file in EPUB 3 exports as well. That's not perfect—since Apple now follows the spec for declaring font usage in a meta element in EPUB 3—but it still works and better yet doesn't break anything. And given Adobe's dedicated support for EPUB lately, I'm confident that they'll roll the new behavior into InDesign CC soon.

One small caveat: remember that if you have Preserve Local Overrides unchecked and you've applied fonts with an override, then you shouldn't be surprised if the fonts don't make it to the EPUB file.

InDesign TOCs to EPUB

I'm exporting an InDesign document to EPUB and for some reason the formatting that I've applied to the TOC title doesn't stick. I click in it and look in the Paragraph Styles box and it says TOC title,



but when I export, it says "No Paragraph Style". I go back again, check once again in the Paragraph Styles box, export, and once again, I get "No Paragraph Style".



What's going on?

And here's where going to trade shows really helps. I mentioned a while back that the engineers at Adobe are really open to suggestions and requests, and it happens that a couple of them came to my EPUB3 talk the other day in New York City. We talked for a bit afterward about my wish for a single file for both the navigational TOC and for the regular, in-the-body-of-the-document TOC (which I describe in some detail in my slides which you can find at the previous link). And the engineer told me, “but since we regenerate the ncx file upon export, we wouldn't know if the user had changed something in the text”.

Remembering that today helped me realize why my format wasn't making it through. InDesign doesn't pay attention to the document that's on your page upon exporting a TOC to EPUB, it only looks at the TOC Style, and what you have defined there. And here's what I had:



Since InDesign uses this definition and not what you see on the page to generate the TOC in your EPUB document, it was giving me "No Paragraph Style".

Once I updated the TOC style, I was able to get the TOC title to be exported with the proper style.





Unfortunately, InDesign CS 6 has a bug which keeps it from properly splitting an EPUB on a style that's part of a TOC. Argh. So, in the end, I had to add the TOC title separately in my InDesign document to ensure the break. (I also had to get rid of the title from my TOC style so that it wouldn't be repeated there.)

Still, I think it's important to keep in mind that when InDesign generates a TOC file, it gets the information from the TOC Style definition, and not from the content that you may have edited on the page.

Numbered lists from InDesign CS 6 to EPUB and mobi

I got a note from a reader asking me to help with a document exported from InDesign 6, but whose lists were displaying repeated line numbers in old Kindle (mobi).

It turns out that if you use the Bullets and Numbering tab so that InDesign automatically numbers your lists, InDesign CS6 always hard-codes the line numbers into the resulting EPUB. Always.

Depending on whether you choose "Map to Ordered Lists"

<ol>
<li class="Numberedlist"><span class="char-style-override-1">1. </span>Research solar panels.</li>
...

"Map to Static Ordered Lists" (notice that value attribute is added)

<ol>
<li class="Numberedlist" value="1"><span class="char-style-override-1">1. </span>Research solar panels.</li>

or "Convert to text" (notice that now the paragraphs are exported as p elements, and not li)

<p class="Numberedlist"><span>1. </span>Research solar panels.</p>

and how you map the list paragraphs to export tags, it will create the HTML in one way or another, but the numbers themselves will always be there.

But a li item is always numbered in HTML/EPUB, no? How does InDesign keep there from being two line numbers? The answer is that it messes with the CSS, and changes the li items into regular block elements, taking away their listiness and thus their automatic numbering:

li {
display:block;
}

Not only that, it removes all the default margin settings from both the ol and li elements:

body, div, dl, dt, dd, ul, ol, li, h1, h2, h3, h4, h5, h6, p, pre, code, blockquote {
margin:0;
padding:0;
border-width:0;
}

This has two unfortunate effects. First, in EPUB ereaders, the lists are numbered but they're not treated as real lists. This means that there are no hanging indents:



And since old Kindle (mobi) doesn't understand the CSS that ID uses to convert list items to block items, it keeps displaying them as list items, and we get duplicate line numbers (the automatic ones from the list, as well as the hard coded ones):



Both outcomes are pretty unacceptable, if you ask me.

So what can you do? I see two avenues. You can either crack open your EPUB and GREP out the line numbers and then use HTML/EPUB's natural list-item formatting or accept that InDesign is going to hard-code the line numbers into your HTML and attempt to create hanging indents from the resulting paragraphs (without ever having to open the EPUB).

Let's start with the first, or "coder" solution.

First, I'm going to assume that you've formatted your lists using the Bullets and Numbering tab in the Paragraph Styles box. This means that InDesign will automatically number your lists within InDesign and it will hard code the numbers into the EPUB. It's probably a good idea to use a special character style for the numbers themselves, in case you want to format them later through the CSS. It also makes them easier to GREP-remove, as I'll show in a moment. Mine are called "numbers".

Second, create an listsarelists.css file in your favorite text editor (and save it as text only). It should look like this:
li {display:list-item}

ol, ul {margin: 2em}

This will override ID's CSS and thus restore the listiness of your list items and gives them hanging indents and automatic numbers.

When you go to export your EPUB, choose "Map to Ordered List" next to Numbers at the bottom part of the first panel of the Export Options box.



Then click Advanced to go to the last panel of the Export Options box. Click Add Style Sheet in the middle of the box, choose the listsarelists.css file and click OK. You'll see it listed in the Additional CSS box:



Now export.

Now crack open your EPUB and use GREP to remove all of the hard-coded line numbers:

Note that I applied a character style called "numbers" to the numbers in my lists. This makes them easy to search for, even though ID has added character style overrides:



That is, search for: <span class="numbers.*?</span> (That means, search a span tag whose class is numbers, and maybe some other stuff, and then get rid of it, up until the first following closing span tag.)

And replace it with nothing.

Finally, rezip your EPUB and it looks great:

In iBooks (and other EPUB ereaders):



In Kindle Fire and Kindle (shown with Kindle Previewer):



Now let's look at the less codey solution that doesn't require that you crack open the EPUB:

Remember again that InDesign will always output those line numbers. So what if we converted the lists to text in the EPUB in order to remove the automatic numbering? We start the same way, with InDesign's Bullets and Numbering panel and creating the lists in our book. It turns out the only way to export a list with no listiness (e.g., no ol or li elements) is by choosing Convert to Text upon export:



Here's what the HTML looks like that we'll have to work with:

<p class="Basic-Paragraph">Here’s a list:</p>
<p class="Basic-Paragraph"> </p>
<p class="Numberedlist"><span>1. </span>Research solar panels.</p>
<p class="Numberedlist"><span>2. </span>Figure out if it makes sense to redesign the kitchen.</p>

You don't have to look at it, but it helps to know what we've got :)

The next step is to create an extras.css file with CSS that formats the resulting p elements into things that look like hanging indents. Beware, it won't look perfect. Make sure that the class name in your CSS (here: list) matches the paragraph style name in InDesign.

p.list {line-height: 1;padding:0;margin:0}


@media not amzn-mobi {
p.list {margin-left:1.2em; text-indent: -1.2em;}
}

@media amzn-mobi {
p.list {text-indent:-40px}
}

You can have InDesign add that CSS to your EPUB by choosing it in the Advanced Panel of the Export Options box:



That looks pretty good on the Kindle Touch (at this font size):



and on iBooks:



though you can see that the lines are not quite lined up.

When you look at it in old Kindle, the misalignment is more pronounced:



even more so when the text is smaller:



So, those are two solutions. Neither is perfect. Keep in mind that my example is a very simple one-level numbered list. Not a bulleted list and not a complicated one.

As I was working on this, I asked on #eprdctn if anyone had any other ideas, and it turns out that Ron Bilodeau has been working on this too. He wrote a little bit about lists in ID6 in last month's InDesign Magazine and says he is writing a blog post that should go up some time next week. I can't wait to read what he finds.

Pepcon 2012

I'm writing this on the plane on my way home from Pepcon 2012. I'm tired and annoyed with the TSA, but even they cant take away my appreciation for having gone. As much as I love and value the connections and communication that happens online, there's something about meeting people in person that somehow makes it all real.

I wanted to write a little about what it was like so those who couldn't go could get a feel for it.

I didn't get to Pepcon until almost 3pm on Monday due to some prior commitments. But there were some sessions still going on when I got there, and I listened to part of Mike Rankin's top ten Long document tips and then a bit of Bob Levine and Keith Gilbert's presentation on DPS. One of the hardest parts of most conferences for me is wanting to listen to multiple presentations at once. My solution is to wander from one to the next, but it's imperfect at best.

Let me confess that I don't know a thing about DPS, but my first impressions aren't that great. It feels like a dead end to me, and I personally can't stand subscription programs; I don't want to be locked in month after month, I want to own. And it's all images, even the text?? No. I want standards so that my content doesn't get lost under proprietary formats. I don't want all my eggs in anyone else's basket.

After the sessions I took part in the first of two meetings with the senior InDesign engineers from Adobe. I've been on the InDesign beta team for a while so their names were familiar, but this was the first time I had met any of them in person. I was totally impressed. They asked us what we wanted (in terms of InDesign support for EPUB) and then carefully listened as we debated the merits of different solutions and the problems of various strategies. They didn't make any promises and they didn't make us sign any NDA forms, they mostly just listened and gave us feedback about our complaints.

One of my big complaints was that the CSS that InDesign generates has too many default values, and doesn't take advantage of CSS' power of inheritance (the cascade). It's tricky, because you can have an unending hierarchy of styles based on other styles in InDesign but the most obvious way to translate that to CSS involves using multiple classes, which are unfortunately not supported by all ereaders. There is limited cascade without multiple classes though there is the body, the p elements and then individual classes.

Throughout the course of the two meetings (almost four hours) we talked about a lot of issues. We didn't come to any firm conclusions and they made no promises but I think the important bit was helping them talk with people who actually use the tool to make EPUB files—probably Ron Bilodeau and Colleen Cunningham were more useful in this regard than I was.

And I don't mean that in a flippant way. In my own personal experience, it's a challenge to both write about how to create EPUB and actually create EPUB files. I imagine that it's even harder writing software that creates EPUB files and actually creating EPUB files. I'll come back to this point.

After the meeting with Adobe, I went to the Pepcon Ignite session. My favorites were the ones by MarisaKC and by Kelly Vaughn, whose presentation on creating crazy shapes with various weights and kinds of strokes reminded me a bit of my own exhaustive report on the possibilities of iPhoto.

You'll notice that I haven't mentioned food yet. I went up to my room and ate some of the lovely fruit that Anne Marie and David had left for me. but I didn't go out to dinner because I still wasn't done with my presentation despite my promises to myself not to leave it to the last minute. Having to stand up in front of people and say something relevant is a really good way of proving the difference between having an idea and actually having a presentation. I knew what I wanted to say, I knew where I wanted to put the emphasis, but when I started to practice out loud, I realized (yet again) how much work it is to put those ideas into a shape that makes sense to other people. Easy is hard, and all that.

I didn't get to sleep until 11:30pm local time, which was 2:30am in my head, and I had been up since 3am the night before because I had left on an early flight. Note to self: really, really finish your presentation before you go to your next speaking engagement.

I woke up at 5am, thanks to a call from my non-time-zone-aware-daughter, but then took advantage of the time to really finish my talks, and practice them all the way through.

During the morning session, while hearing the brilliant ID scripter Kris Coppieters, admit that he “isn't an InDesign user”, and then watch several more presenters describe features I've never used and sometimes never heard of, the difference of using a program and creating the program (or teaching others how to use it) became even more clear. It's really hard to do both.

I think of the morning sessions, it was Gabriel Powell's that was the most helpful in terms of EPUB stuff: “Preparing Images for ePub/eBook”.

At lunch, I had a nice chat with Ron Bilodeau and Felipe Santos, the former from O'Reilly in Cambridge, and the latter from Brazil. These are the moments that make a conference special: catching up with people face to face that you might know online (like Ron), and learning different perspectives and needs from people you're meeting for the first time (like Felipe).

At 1:30, I gave my first talk, on Enhanced Ebooks. I started by talking about what sorts of books are encompassed by that term, and then talked about how to embed audio and video in an EPUB file with InDesign, using the techniques shown in the blog post that I published that same day. I was pretty jazzed to be able to explain to these InDesign-centric and perhaps code-cautious listeners that they could create enhanced ebooks without cracking their EPUB files and looking at the dreaded HTML.

Then Matthew Diener joined me to explain what EPUB 3 has in store, wisely showing some nice examples on both Azardi and Readium. Then I gave a more nuts and bolts look at exactly what EPUB3 code looks like. It's not that different from EPUB2, you'll be happy to hear. There were many fewer listeners in the EPUB3 talk than the Enhanced Ebooks presentation. I think people are wary of future technologies that are not yet implemented. But as I mentioned yesterday, EPUB3 is now supported by the iBookstore, and Apple is using it in standard ways to provide a better user experience. It's time to make the move.

After my talks, we had another two hour meeting with the InDesign crew, in which we discussed indexes at some length. One of the issues we argued about was how to label references to content. That is, if you go look up EPUB3 in the back of a print book, you might see something like:

EPUB3 12, 45-67, 78, 92

In an ebook, of course, there are no discrete pages, and so at first glance, you might be inclined to do away with those references altogether and use something like:

EPUB3 1, 2, 3, 4

But I argued that even though the page numbers themselves might be an artificial construct, they still give us information about what we might find there, that is lost in the replacement solution. In the example above, I might expect a short introductory mention on "page 12", a more thorough treatment on "pages 46-78", and less introductory, but still short mentions on "78" and "92". How do we convey that information without the actual page numbers? The short answer is, we don't know yet.

Finally, it was time for dinner. I was looking forward to meeting EPUB coder extraordinaire Rick Gordon for the first time, and had put out a call on Twitter to see if anyone wanted to join us. It was a really interesting bunch in the end (about 10 of us) who made it to the Jazz Bistro Les Joulins, just down the street from the hotel. The food was good, and the conversation interesting, and heavy into code :)

Not quite done, in the morning, I spent an hour at the Meet the Author's table with Steve Werner, InDesign expert. I'm not sure people really knew we were there, but I got to talk to a few people who wandered over.

The last thing on my agenda was to talk to Kris Coppieters and see some of his amazing scripts in action. He kindly came out to give ma demo and I was totally enthralled. While I had originally talked to him about a script that converts blogs to InDesign documents, I was most interested in his CSS Geometry which spits out the coordinates of the text blocks in an InDesign document and might be very useful in generating Fixed Layout ebooks from InDesign.

And I did get to see a cablecar!



Many thanks to Anne Marie Concepcion and David Blatner for inviting me, and in general for organizing the conference and getting so many interesting people together! (And thanks to Matthew, whose nicest tweet ever is still making my day.)

Customizing InDesign's EPUB files without cracking them open!

I'm working on my presentation about Enhanced EPUB for PePcon on Tuesday afternoon and I was playing with the newly released InDesign CS 6 to make sure that everything works as expected. But it didn't. For some reason, when you place an audio file, iBooks displays the controls so small that the only thing you can do is choose Airplay, but not the actual Play button (if you're on an Airplay network). It's pretty frustrating and would completely ruin InDesign's much improved multimedia function if not for one thing.

You can fix it without cracking the EPUB file open. One of InDesign CS 6's other new features is that you can choose additional CSS files to apply to your exported EPUB. All you have to do is create a CSS file that fixes the code that InDesign supplies, and voilà, the audio controls reappear. You don't have to unzip, or worse, rezip.

The key lies in the letter "C" of "CSS". It stands for Cascade. The Cascade means that when there are multiple sets of style rules for a given bit of text, there is a defined hierarchy for which rules will win out. I actually see it as a sort of waterfall in my head with the more “important” rules flowing over and covering the lesser ones.

To make the cascade work, you have to understand the slightly complicated topic of CSS inheritance: given two competing rules, which one wins? I talk about this in some detail in my HTML book. The very abbreviated answer is that you have to take into account specificity (that is #id overrules .class overrules p) and location (that is, inline overrides local overrides earlier, overrides imported), as well as taking into account the !important tag.

In our example, InDesign creates this code for audio elements. Note that this is the default size if you don't change the poster image for the audio element.

audio.frame-5 {
height:60px;
width:60px;
}

But when I open that document in iBooks on the iPad, this is what I see:



And when I click it, all I can select is which Airplay device I want. I can't actually play the audio.



So, I open a new text document. InDesign 6 lets me add additional CSS documents and will automatically load them after the CSS that it creates itself. That means that since my styles are later, as long as the specificity is the same, my styles will override InDesign's.

But if you look at the code above, notice that the selector that InDesign uses, audio.frame-5 has a class, and thus is more specific than a plain audio.

The answer lies in the HTML that InDesign creates. By default it generates an id element for each audio (and video) element that it creates, set to the filename. So, you can use that filename in the CSS to make your selector more specific, and thus override InDesign's CSS.

My audio file is called "bondia.mp3", and if you know CSS, you know there's a problem already. That period in the filename has special meaning in CSS (it means that what follows is a class name). Since we don't want that special meaning, we have to escape the period with a backslash:

audio#bondia\.mp3 {
height:26px;
width: 150px;
}

These values will now override the height and width values that InDesign generated. Save this text file as "extras.css"

How do I get them into my EPUB file? Go to Export in ID6, choose EPUB, click the Advanced panel, and then choose Add Style Sheet, then find your extras.css file. Export as usual.



If you looked inside your EPUB file (though you don't have to), you'll see this:



That's it! When you open your book in iBooks, you'll see that the audio controls are as you specified (and not as InDesign specified), even though you never had to deal with Terminal, never had to unzip or rezip or anything.



The best part about this is that you can use this technique to override any of the CSS that InDesign either creates in a way that you don't like or that it doesn't yet support. For example, suppose you want to add a border around a video. You can do that with an extras.css file. (Indeed, you can add borders to all of your videos just by using video as a selector instead of targeting just a single video.) Suppose you want to add media-queries so that your document will work as best as it can in different ereaders. Just put the media-queries in your extras.css file. The possibilities are really enormous.

Thanks to Adobe for incorporating this amazing new feature!!

Kindle ignores everything when ID gives it multiple classes

I'm about to publish an anthology of stories based in Barcelona (more news soon!) and keep bumping into an annoying issue with (old) Kindle: if your InDesign document contains a styled paragraph with local formatting, InDesign will export the resulting EPUB with multiple classes, one for the base style and one "override" class with the extra bits. Unfortunately, Kindle throws up its hands at multiple classes and not only ignores the extra classes but actually ignores the base class as well, leaving the paragraph with no formatting at all. Ugh.

Here's an example from my new book.



The paragraph that begins "Moving between the shadows" has no styling. It should be in italics with no indent, as shown in iBooks:



I go look at the code, and find that InDesign has added an "override" style:



Why? Because I had added some local formatting in the original InDesign file. Oops. (You can tell by putting your cursor in a paragraph and looking at the Paragraph Styles panel... if there's a plus sign next to the style name, there's local formatting.)



Really, InDesign is completely within its rights by exporting multiple classes, they are perfectly standard. It is Kindle that is at fault here.

The easiest solutions is to avoid local formatting. This is a good idea in general, although I'll admit that when I just need to nudge something in my print version, I am not always strictly orthodox.

If you forget, and/or don't want to go back and change the print version, the second solution is to create a new style that contains the characteristics from the two applied styles, and apply it both to the HTML and to the CSS. Kindle can't say no to that.



In general, I recommend doing a search through your XHTML files in an InDesign-generated EPUB document to find all of the override classes. Then, substitute them with better-labeled and less troublesome individual styles.

Also note that it is "old" Kindle that can't handle multiple classes, Kindle Fire supports them just fine.

Bad Headers in InDesign exported EPUB

I've talked about this issue on Twitter, but I've gotten two emails about it this week, and because of installing a new language version of ID bumped up against it myself, so I'm going to write a quick post to make sure that everyone knows:

The first version of InDesign CS 5.5 had a serious bug that exported bad headers to EPUB. Specifically, it inserted an extra space in the DOCTYPE element of each XHTML document:



This error in the DOCTYPE causes all sorts of problems, particularly with special characters, non-breaking spaces (@nbsp;), discretional hyphens (@shy;), etc.

Luckily, Adobe fixed the error right away and has made a free update available for both Macintosh and Windows. If you're using InDesign CS 5.5, I strongly urge you to install the update.

Here's what the proper DOCTYPE should look like:



Now, here's a weird bit of extra info that you'll probably never need. But I did, so you never know. I have both English and Spanish versions of InDesign CS 5.5. I originally installed and then updated the English version. When I installed the Spanish version, it overwrote the English. I updated it as well. Then, when I got sick of navigating in Spanish (and had finished De InDesign CS 5.5 a EPUB y Kindle), I renamed my Spanish ID folder, so as not to lose it, and installed the English version again.

I forgot to update it until yesterday, but when I did, suddenly the English version started coming out in Spanish—Spanish menus, Spanish dialog boxes. It was bizarre. And annoying. I still have no idea how that happened. I was definitely using the English version, and the menus and dialog boxes were definitely in Spanish. Anyways, I really didn't feel like reinstalling the English version again (and wasn't convinced it would help), so I rummaged around the internet (and complained on Twitter) until I found this very helpful post from David Blatner on InDesign Secrets, that explains how to change the interface of your version of ID—even if you don't own the other one. It did the trick and now my English ID is back to English. (I haven't dared open the Spanish ID :)

Thanks to Ester, who reminded me I really needed to write about this.

Metadata in iBooks, iBookstore, iTunes Producer, InDesign, and Amazon

I got an email today asking how to set the subject keywords for an ebook in InDesign. That part is relatively easy. You choose File > File Info, and add the desired keywords to the Keywords field, separating each keyword from the next with a comma or semicolon:



But what happens when InDesign exports to EPUB? I'm happy to report that it does exactly what it should and converts those keywords into dc:subject elements in the OPF file:



Now, I'm no expert on metadata, so I have not made it a point to use standard BISAC book categories for describing the subject of my books in those fields. We'll come back to this.

When you upload your book to Apple's iBookstore, you have the option of entering BISAC data in iTunes Producer:



And that data entered in iTunes Producer overrides whatever you entered in the content.opf file (or InDesign for that matter). When someone downloads your book, they will only see the Main BISAC category (although the original keywords remain in the content.opf file inside the book):



And as far as I can tell with this single example (though I've heard other anecdotal evidence also in support), the iBookstore does not use the keyword metadata to help aid searches for your book. Notice for example a search for GREP, which I specified as one of the keywords for this book:



iBookstore fails to return my book when searching for "GREP", even though the book contains "GREP" as a subject keyword.

For the record, my book does appear when searching for "InDesign" and "EPUB", presumably since those words are also in the title.

Then I switched over to Amazon to check what happens there. I also had to enter the BISAC categories when uploading my book to Amazon. In addition, they let me enter up to 7 keywords.



Amazon doesn't list a category next to a book on the Kindle. When I search for InDesign and EPUB, my book appears (as it should, since those words are in the name). More importantly, when I search for "GREP" on Amazon, my book also appears:



Now, I am not at all sure whether Amazon is paying attention to my specified dc:subject elements or more probably to the keywords that I specified above. But either way, it gets points for finding the book.

Seems like you can't hurt anything by adding the metadata in InDesign and/or directly in the EPUB file, but it is far from conclusive whether or not it helps. I wonder if other ebook distributors pay attention to the dc:subject elements. Does anybody know?

Finally, Apple iBookstore clearly has a long way to go towards being a useful tool for discovering books you're interested in. That it completely ignores metadata categories and gives you no other method for specifying them is pretty lame, to say the least.

Returns in EPUB

We have these crazy complicated tools that can do amazing things for us but they have gotten so complicated that it's sometimes hard to take advantage of even their most basic power. Case in point: returns.

So, here's the rule: At the end of a paragraph, use a single return. Then adjust the style for the paragraph so that it has the correct amount of spacing after it.

The most important advantage is that you gain flexibility. If you decide you want more or less space after each paragraph, all you have to do is adjust the style, not delete or add additional returns. And while a return will always give you a set amount of space, you may want to add half, twice, or three times that much space.

This is particularly important when exporting to EPUB. If you add extra space by adding returns in InDesign or Word, those returns will disappear in your ebook. This is because HTML (which EPUB is based on) treats white space in its own special way.

Let's look at an example. You're laying out The Legend of Sleepy Hollow, and you've decided to start your paragraphs flush left, without indents. Therefore, you want space between each paragraph so that readers can see where one paragraph starts and the next one begins.

You add two returns after each paragraph to add this space in InDesign (or Word).



You export your book as usual, and notice that the code reflects the extra return:



But when you open your book in your ereader, the space disappears:



What happened? White space in HTML is collapsed. Three spaces are converted to one. Two paragraph returns are converted to one. And an empty paragraph, like the one shown in the code, is simply ignored. You could hack the code to make the ereader pay attention, but a much more sane solution is to adjust the spacing around the paragraph.

There are two strategies. The first, which I highly recommend, is to return to InDesign, remove all the extra returns, and then specify a value for Space After in the Paragraph Styles Option box:



The amount you put in the Space After determines the amount of space that will be added to every paragraph marked with this style. Don't like it? Change it once in this box, and all your paragraphs will be updated at once.



When you re-export to EPUB, the Space After is properly applied to the CSS of the affected paragraph(s):



And we no longer have the extra paragraph in the HTML code:



But best of all, now we have space where we wanted it in the ebook on the ereader:



And the second solution? I didn't forget. If you've already got your InDesign or Word document set up, you could theoretically ignore the extra p elements that will be generated and just adjust your CSS by hand, by adding a margin-bottom value to the paragraphs in question. It's not the best solution, but sometimes, you've only got so many hours in the day and the OCD well in check :)

Finally, I don't know why they spelled tranquility with so many l's!