Sometimes I feel so stupid. The solution to the incomplete CSS in exported ePUBs is so much more simple than I thought. Your mind just seems to turn a little corner and the solution pops up in front of you.

My beef with InDesign CS5.5’s ePUBs was the need to edit the CSS

I’ve posted several times here and published a couple books about fixing the ePUB CSS. What I wrote was accurate. It’s not difficult, as long as you know HTML and CSS and can work in Dreamweaver to fix this stuff. But my frustration is that I don’t think you should be forced into DW to make an ePUB. It turns out that what I wrote simply is not necessary in most cases.

You can easily force InDesign CS5.5 to write good CSS

Well, that’s a bit of an overstatement. The Web developer purists will be shrieking. But, you can easily make InDesign write CSS that controls all of your type in the ePUB. If you remember from my earlier writings, the basic problem is that InDesign does not define the basic tags: h1-6, p, ol, ul, and so on. What I suggested before is that you map your tags so that all you need to do is open the CSS in Dreamweaver and add definitions for all the basic tags you need. That still works. And in many ways that is still the way to go for reasons we’ll mention in a bit.

However, you can easily force InDesign to write CSS rules that will control all of your type without the need to edit the CSS afterward. What you need to do is make sure that you specify a class for all your styles as well as a tag. Let’s take a look at what I just exported for the ePUB for Writing in InDesign. I opened the Edit All Export Tags… dialog and set up the following classes.

Notice I added tags for all the styles. For the lists I use li. InDesign adds the ul and ol tags, but we have no way to edit them in InDesign. The same is true with all the tags for tables. If I want any fancy sidebar rules with backgrounds and reversed type and all of that, I’ll still need to edit the CSS. But what you see above will work, and it will look remarkably close to what I see in InDesign.

What changed are the basic tags

If you notice, I used to make my heading h1 with no class. Now I have added a class of chapter. I used to make my first level of subhead (Style 7-Sub 1) h2, now I add a class of normal. Even my basic paragraph tag (Style: 2-Body) is now given a class of standard (or normal).

Why add the classes?

That’s simple. InDesign will not define p, my basic paragraph tag. But it will define p.normal. It will not define h2, but it will define h2.normal. Is the result wonderfully sleek and elegant XHTML code? No. But it works and all of your typography is controlled. If you do not do this, you are forced to crack the ePUB, open template.css and add the basic tags.

So, the choice is yours. You can now design your ePUB edition of your book in InDesign and directly upload the resultant ePUB with no modifications. The results will look very good.

However, it is never quite that easy

The problem is that during the massive conversion from your print version to your ePUB version it is extremely likely that you have many styles or locally formatted type that use fonts you cannot use in an ePUB. I was looking at the CSS for the first proof of the ePUB and at the bottom I found many spans asking for fonts I was certain I was not using.

Here we see the Find Font dialog box (Type>> Find Font…) for the InDesign file I used for one of my font design ePUBs. As you can see, the top listings (there were actually sixteen of them) are fonts I didn’t want to use in my ePUB, BECAUSE almost all ereaders would substitute them out with its own defaults. Obviously this is real problem with an ereader like the Nook which only has three fonts available. None of these sixteen fonts are available on any ereader unless I am using a browser-based ereader (like ibis) on my own computer where these fonts are installed.

For the Writing In InDesign ePUB there were about ten of these errant fonts. I carefully decided what to do with each one of those instances. If I click the More Info button you can see above in the Find Font dialog, it will show me the page location of the font use (often it shows many locations). Once I locate the problem, I find I have three choices:

1. It may be in a paragraph or character style that was never redefined: In that case I can redefine the style and eliminate the font usage very easily.
2. It may be in a graphic: In this case it is usually large enough to convert to outlines and then make a rasterized version of the graphic.
3. It may be part of the copy: This will probably not happen to you unless you are like me and write about typography and fonts. In this case, I can select the type and Create Outlines—leaving the outlined type inline in the copy. That will work, but InDesign will convert that outlined type into a coarse bitmap that looks pretty chewed up. Your best choice (for quality) is to rasterize that type in Photoshop and save it as a GIF or JPEG at 300 dpi. You can then place that high resolution bitmap graphic inline in your copy and it will look as good as possible.

Once you have your fonts cleaned up and your export tags set, you can export your ePUB. It will probably verify [but make sure at threepress], If it verifies, you are then ready to upload it for sale and distribution.

Related articles

• Writing in InDesign: Part 6, Fixing the ePUB CSS (bergsland.org)
• I just added CSS editing instructions to the free ePUB design booklet (bergsland.org)