ePUB CSS Repair

Once you have your ePUB

It will usually open in ADE (depending on what you have installed on your computer). Proof it carefully. Redo as necessary. If your computer is like mine, the graphics will be very poor in ADE. Basically ADE is very crude.

Then drop a copy of the ePUB file onto iTunes and sync it into iBooks on your iPad to read it in iBooks. The reason you need to use a copy is that iTunes adds some weird plist file that prevents the ePUB from validating. Then open it in the Ibis reader at threepress.org. Then check it out in Calibre. Ibis and Calibre will give you a very good idea about what is really in the file. ADE and iBooks will not do this. But you need to know what ADE and iBooks look like because many people will be reading your ePUB in those apps. By now you’ll have a good idea what is translating well.

Editing the CSS if you can

Or don’t if you can’t. You do not have to edit the CSS..But until InDesign gives us controls within the app to control font use, styles use, div construction, text wrap, and all of that, fixing the CSS is a good idea.

You use Dreamweaver. It does not do much to help us either. EPUBs are like a little orphan child at this point where no one wants to deal with it on the software development level at Adobe. Hopefully for CS6…

The first problem is compression

The problem with this has been the difficulty with decompressing the .epub file and then recompressing back into .epub. Evidently this is no real problem on a PC, but I’m not going there. On the Mac, some of the files must be saved within the archive that are not compressed. For that you will need a script. I recommend that you Google and download “ePUB Zip 1.0.2”. It’s an AppleScript that will let you simply drop the ePUB folder you get when you uncompress the ePUB onto the script icon to recompress it into an ePUB again. It has worked flawlessly so far. There are other solutions and you can research them, but this is the most simple at this point in time.

Looking at the uncompressed folder

An ePUB is simply a zipped folder with a special extension. When you decompress the ePUB (I use StuffIt), it opens into a Folder.

The content looks something like what you see above.

Mimetype: As mentioned, one of the things within this folder cannot be compressed when you recompress it back into an ePUB. It is the mimetype file (which is just a single line of code— application/epub+zip—a coder thing). This is why you need the script just mentioned.

META-INF folder: You do not have to worry about this either. It works and that is all we care about. Coding purists like Liz Castro suggest some possible changes, but they are not necessary. InDesign 7.5 writes a file that works fine.

All the real content is in the OEBPS folder

Because the rest of the stuff in the ePUB does not concern us here, I ignore it when I open the ePUB pieces into a site in Dreamweaver. I open Dreamweaver; go under the site menu to Manage Sites…; make a new site with the OEBPS folder as the root folder; and click done. Dreamweaver will open this up so I can edit all the files I need to edit within the ePUB

Fonts folder: This is there if you embed fonts, but none of the major ePUB readers (iBooks, Nook, & Kindle) support embedded fonts. So, we will not deal with that here.

Graphics folder: This folder contains all the linked graphics and the cover image.

The toc.ncx & content.opf files: Thankfully, CS5.5 seems to be writing good ones now. This is coding on a level I can’t handle [or won’t]. Do not touch is a good word here.

All the HTML files

These are the files generated upon export. There is a new HTML file for every chapter break headline you used. As you recall, one of the choices you made on the Contents page of the EPUB Export Options dialog was which paragraph style to use to break your document. As you can see below, I used 6-Head.

The result of that was a new HTML file for each use of the chosen style. We did this because it is the only practical way to make page breaks in a variable media like an ePUB. The good news is that the resulting HTML documents are good, clean code.

Fixing the code

The first thing to do is take a look at the HTML and see if it used the tags you wanted to use. If it did not you need to go back and fix the issues in the Edit All Export Tags… dialog box. This will set all the basic tags. The problem is that even with CS5.5 the resulting CSS has some major issues. Many of the issues are very obvious. And they come about because of the flexibility demanded by the paradigm. My problem is that I want more control than that.

Fixing the CSS

When I look at the CSS file in Dreamweaver I immediately notice that several key rules are flat missing. For example, I had assigned my 8-Subhead2 style to h3. My 4-BodyHeads style is assigned to h3 with a class of small. When I look at the CSS generated, I see the rule for h3.small—but there is no definition for h3.

This is true throughout. No wonder my ePUBs were never what I expected. None of the twelve basic tags used (p, h1, h2, h3, h4, h5, h6, ul, ol, li, strong, or em) are defined. So, the first thing I do is add definitions for those tags.

Make sure the font choices are good

Before I can do that, I need to change the font lists in Dreamweaver. The DW default font lists give us no real choices of any good-looking fonts [except for Palatino]. My suggestion is that you build your font lists out of fonts available to the iPad plus the Web-safe fonts.

We must remember that at this point, the big 3 ereaders [iPad/iPhone, Nook, & Kindle] do not support embedded fonts. In fact, as you recall the Nook and Kindle basically have only serif and sans-serif. But the iPad has 33 fonts available in a reasonably versatile set.

First let’s review the iPad list

This is a highly personal set of choices. I’m going to suggest my personal tastes and give you reasons. You make up your own mind. I’m going to just mention the ugly ones you should never use: AppleGothic, Courier, New Courier, and DB LCD Temp. These ten fonts should never be used unless you are trying to evoke a period or make a historical statement or something strange.

Fonts with compromised reader reactions

Next we have fonts that are not bad designs, but they have issues—some of them fatal. I don’t use them.

Arial + a rounded style: There are five choices here— regular, italic, bold and bold italic plus the Rounded Bold. These fonts plus Times make up the core of some of the most overused fonts in existence. Plus they are the default for bureaucracies. Arial is the ugly cousin of Helvetica used to avoid the royalties (as far as I know).

Helvetica & Helvetica Neue: Both of these families are available in regular, italic, bold and bold italic. There is nothing really wrong with these fonts for heads and subheads. But readability is a real issue. The main problem is the bureaucratic overtones that these fonts share with Arial.

Times New Roman: This family has regular, italic, bold and bold italic. Though the bold pair tend to be too narrow and ugly with plugged counters, the real problem is the bureaucratic associations.

Bureaucratic fonts: These are the fonts that have been the defaults in Office, Publisher, and similar non-professional page layout tools for decades—Arial, Helvetica, Times, and Times Roman. They are not very pretty fonts, but that is not the real issue.

The real problem is that non-professionals who use nothing but software defaults are the only people who use these fonts. In fact, most bureaucracies have standardized them and require their use. The result is that they trigger our bureaucratic drivel filter.

If you watch when you open your mail or when you receive handouts, you will see that bureaucratic output is quickly consigned to the trash—usually without being read. We know that there is no content in these things. Bureaucratic output is produced purely to prove to administrators that something was done—even though we all know that nothing was done except some committee meetings.

So, almost everyone simply tosses obvious Word output without reading it. Beyond that, default Word and Publisher output is barely readable. There are simply too many really bad associations with these fonts to use them.

Versatile fonts for typography

The iPad gives us several quite good choices here. These are font families that are relatively easy to read and comfortable for the reader. There are several fine serif choices, and a lesser selection of sans serif families. However, there are enough choices for you to be able to make your ePUBs unique, stylish and very readable.

For body copy you need at least regular, bold, and italic versions for your typographic needs. A bold italic is nice but not often needed.

Serif choices for body copy

Baskerville: There are four choices—regular, italic, bold and bold italic. This is an extremely elegant font, very readable—a little cool and distant. It’s a bit formal for my taste now, but it was my first font purchase back in 1991 when I started using PageMaker.

Bodoni: This is the ITC translation of Bodoni’s Papale (or Papal) version of his fonts. These fonts are extremely elegant but a bit difficult to use in smaller sizes because of the extreme contrast in stroke widths. There are seven fonts here. Bodoni 72: regular, italic, & bold, and a true small cap version. Plus, Bodoni 72 Oldstyle: regular, italic, & bold. The Oldstyle version has lowercase figures which is very nice.

Cochin: There are four choices—regular, italic, bold, and bold italic. This has been my choice recently—largely because of the uniquely splashy italics. I suspect it is a fad on my part, but I like this family.

Didot: There are three choices—regular, italic, and bold. This is a more uptight and mechanically crafted Bodoni. I’d call it prickly and scrawny, but then I don’t like it.

Georgia: There are four choices—regular, italic, bold, and bold italic. This font has oldstyle figures and is very solid and readable. A Web-safe font family

Hoefler Text: There are four choices—regular, italic, bold, and bold italic. This font has oldstyle figures and is very solid and readable. It is more traditional in form than Georgia.

Palatino: There are four choices—regular, italic, bold, and bold italic. This is a very good looking and extremely readable font with a chiseled, calligraphic look. It uses uppercase figures. Its only problem is some overuse because it was one of the original PostScript fonts when desktop publishing first started. A Web-safe font family

An early iPad bug: When the iPad first came out you were required to use Palatino to make the rest of the CSS work. Liz Castro even suggested an empty paragraph to begin with at one point.

Sans serif choices for body copy

Futura: There are three minimal choices—Medium, Medium Italic, and Condensed Extra Bold. You will not be able to choose a bold style but will have to treat Futura Condensed Extra Bold as a separate font. Futura is barely usable for body copy. This font is a standard in some areas (like here in Mankato). But it is very hard to read, so my recommendation is to use it only for heads—sparingly.

Gill Sans: There are four choices—regular, italic, bold and bold italic. This is the only sans family with any sense of style. It is also more readable that any other sans offering other than Optima [which is nearly a serif design].

Optima: There are four choices—regular, italic, bold and bold italic. This font is one of the most readable sans serifs. There is a little flare at the ends of the strokes.

Trebuchet MS: There are four choices—regular, italic, bold and bold italic. This is a good-looking easy to read sans that is slightly chunky. A Web-safe font family

Verdana: There are four choices—regular, italic, bold and bold italic. This is an excellent font for headers. The large x-height makes it a bit larger than the rest of these fonts, but it reads well. A Web-safe font family

Stylish display options

Finally we have a group of fonts that are quite stylized and really only usable for larger headlines. They are usually too hard to read in smaller sizes. They make excellent style statements for various demographics.

Academy Engraved LET: Very elegant, almost bankish or financial

American Typewriter: The only reason this is here and not in body copy is that there is no italic, just regular and bold.

Bradley Hand: A slightly uptight script that looks like modern cursive printing—a little.

Chalkduster: More loose than Bradley Hand

Copperplate: The de facto standard for lawyers and bankers

Marker Felt: A narrow, dark and more structured hand-written script

Papyrus: A raging fashion, but elegant and pretty.

Party LET: Sixties junk [in my humble opinion]but then the sixties were why I dropped out.

Snell Roundhand: Standard formal script

Zapfino: Very, flashy Calligraphy—the sizing is messed up so there are a lot of overlaps from line to line. Use with care. It will take a lot of extra line spacing and/or margins to work well.

Setting up Dreamweaver with usable sets

I can’t even show you the default sets because I have deleted all the ones that use bureaucratic fonts and fonts I don’t like. I suggest you do the same.

As you can see, after I delete the ones I do not use I really only have four choices left (and I should delete the Courier choice also as I never use it).

Setting up a new list

There are a couple of things you need to understand here. First of all you need to add the font names as I listed them on the previous pages. If there are two or more words, you need to enclose them with quotes like this: “Gill Sans”. Secondly, you need to plan these things out.

As you know, these lists give the browser or ereader font choices to make in order of priority. For example, in the Palatino default above (as set up by DW), I only get Palatino on my computer because I do not have Palatino Linotype or Book Antiqua installed.

Thirdly, DW does not allow you to reorder a list once you have added the font. If you do not like the order, you’ll be forced to delete and start over.

Other than that the process is obvious. You simply type in the font name and click the double left arrow (<<). To remove a font you click the double-right arrow button. If you are like me it will take a few trial runs for each list.

Some recommendations

Always include a Web-safe font: depending on the ereader used, you may well be on either a Mac or a PC. If you are using a browser-based ereader like Ibis (one of the best) then your choices will be governed by the fonts installed on your computer.

Always include a generic choice: Remember, Nook and Kindle (and other dedicated ereaders) only have two choices, serif and sans-serif. So even if you use cursive or fantasy for your generic I would always add the sans/serif choice last.

Here’s my current Dreamweaver lists. I modify these quite regularly as I find more fonts available. Eventually, I will be adding special, custom fonts when @font-face becomes more easy to use. But these should give you an idea of the possibilities for ePUBs. They will give the people who buy the book you are formatting a good start.

Repairing the CSS

The first thing to do is decompress your ePUB and take a look at the rules defined by InDesign upon export. As you are looking, remember that you can fix much of this by going back and adjusting the Export All Tags dialog box and reexporting your ePUB. This is a long process as you begin to get control over your ePUBs.

My goal is to make it more simple for you. But there will be many thing you try that do not work in actual practice. Do not be discouraged, Eventually, our goal is to have a standard set of files in InDesign with consistent remapping to the exported tags and a standardized template.css you can use in the Export ePUB dialog box in InDesign. But that will take a little bit of time and effort.

First! All the standard tags are missing: You will need to add them once you have your export figured out so the generated tags match up with your expectations.

Here are some mapping tricks

Lists: You cannot map to ol or ul. You will be adding these definitions to your CSS file, but when mapping from InDesign you map to li.

If you are like me and use your sans choice for numbered lists and your serif choice for your bulleted lists then you might want to map your exports to an li with a class of serif or sans. However, I am finding that this may be better handled with the ol and ul tags also.

Character styles: You do not want to use span as your choice in the Export Tags dialog. You want to use strong and em with as many classes as you need.

Heads & subheads: You can be creative with your formatting of the h1–h6 tags, using multiple classes as necessary.

Check it out thoroughly

I really have a tendency to be lazy about this. As you go through this process, make sure you check out your ePUBs in various readers. ADE may be crap, but it is common and you need to see how your book looks in that environment. But the most important are the iPad and Nook. Kindle is much more limited [and it can’t read ePUBs yet, regardless]. But also check out your book in a good reader like Ibis, the reader from threepress. It’s browser-based and it is good. Calibre also shows almost everything.

Most of the ereader options only show part of the CSS instructions. That is one of the most frustrating things about the current state of ePUB design.

Fixing the CSS

If you know CSS this is pretty straight forward. However, my books assume that you do not know a lot about coding so I will go through some simple explanations of some things the more advanced among you may find tedious.

Adding the basic tags: you need to add p, h1–h6, ol, ul, li, strong and em. InDesign does not define any of these crucial tags. They also do nothing for tables.

You need to define them pretty tightly, but there is a difference here. We are talking about ePUBs, not Websites. You really need to be concerned with allowing enough reader freedom to modify the copy as they read.

On the other hand, you want to make the first impressions good, comfortable and easy to read [before they “mess things up” with their personal settings in their reader]. Remember the basic conceptual world of the book designer and typographer.

Your reader has far too much to read and will drop your writing as soon as possible unless it is easy to read & relevant to his/her life

Some things you may need to change

• Before we start, I must define an em for those of you who are typographically ignorant: An em is the square of the point size. In other words, 34-point type will have an em that is 34 points wide. It was used to define a size for characters and spacers that vary proportionally with the point size. Now you know how large an em space or em dash is. [An en is half as wide, but the same height.]

Type size: This is a variable for the person who is reading. But more than that, it varies by device. The actual size of the type will differ a lot between, iPhone, iPad, Blackberry, laptop and desktop. So, you need to use ems for sizing & leading.

Spacing: For margins, padding, and indents we again need variable spacing. The width of devices changes radically.

For top and bottom measurements, ems work best. For right, left, and first line margins and indents you need to use %. Percentages are based on the window width and work much better.

Divs are rare & tied to text location: It is really not possible to do double columns or anything approaching that with divs.

All you can use are Float: Left, and Float: Right. Div widths need to be in percentages again. Divs are essential for images and many types of sidebars. You have to add them by hand to the HTML docs with one exception. InDesign defines a div for a group, as in an image with a caption..

Graphics are not Web graphics: It’s XHTML, remember. So, for now, you are stuck with GIF, JPEG, and PNG. But you can do them high resolution. You need to do them in Photoshop.

We talked about this earlier, but you must keep it in mind. InDesign’s conversions are abysmal for the designer accustomed to print. For the high resolution JPEGs and PNGs I use Save As instead of Save For Web.

Text wraps require HTML editing: You need to add a div to do it. Then you can set the alignment for the div.

Headers as inline-blocks: This must be done because there is no widow or orphan control that works in all readers.

Keeping captions with images requires a div: You also have to set those divs to display as an inline-block to keep a caption tied to its image.

• InDesign defines far too much: You need to understand that to maintain a cascade of styles (the ePUB variation of based-on styles) you will need to delete all properties that do not change from the parent rule.

Creating Sidebars

You can make inline sidebars by setting up borders, backgrounds, padding and so forth with an inline block. Or You can make separate divs with alignments for text wrap.

Inline sidebars

This is very easy to do in CSS. Set up a style in InDesign that you can map to one of the headers, say h3. Map it as h3.sidebar. Set up your indents, a background, margins and so forth. Make sure you set the padding to keep the type from getting too close to the edges.

You can do some of the fancy coding available in CSS3 like round corners, drop shadows, and gradients, But at this point you must do a lot of special coding for webkit and mozilla. That’s a level of pain I don’t want to deal with. You’ll find that iBooks supports some of this, but most dedicated ereaders do not. This is one of the reasons I have been using Ibis a lot more recently.

Floating sidebars

Here you need to enclose your sidebar with a div. Set the div to float left or right. Set up the div as a percentage width of the ereader screen. Images within the div need to be set at a width percentage relative to the div—commonly 100% or close to that.

Mainly, you need to remember that while you have a fair amount of real estate on the iPad and similar tablets, for smart phones the width is a lot narrower. The iPhone Retina display helps a lot, but there is still very limited screen width.

Keeping the CSS as a default

This is still tedious. Gone are the days when you can simply design loosely—going with the flow, as it were. To get any real production speed, you need a set of styles you can add to your InDesign documents that will met all your normal needs. In fact, it should even cover regularly used uncommon needs like kickers, quotes, and such.

Then you need to have a standard set of mapping choices so that the exported styles are converted to CSS rules that are already defined in your CSS template. You nest hope for production speed is a personal common usage that you can remember habitually.

Test, Proof, & Validate it

Redo the proof as often as necessary. Check itout is a variety of readers. Make sure that when you have what you like, you remember to validate the ePUB. I go to:

http://www.threepress.org/document/epub-validate

It should validate. If it does not, all I can do is pray you will be given information that will enable you to figure it out. The failure messages tend to be very cryptic. But both Lulu and threepress are getting much better about this and letting you know what is causing the problem.

This is why CSS is not in my first book

All of this is much more pain and time spent than most designers are willing to put up with. You can sub-contract these conversions. But that costs money as well as time. My suggestion is that while we are waiting for transparent software solutions, these techniques mentioned here will get you by.

Keep current: These things are changing all the time. I try to mention new changes at my blog: The Skilled Workman. Liz Castro does the same at hers: Pigs, Gourds, and Wikis. A List Apart, Joel at the Book Designer, and many others are good also.

 

Related articles

• Editing ePUBs (bergsland.org)
• Embedding Fonts in iBooks 1.2 (pigsgourdsandwikis.com)
• iBooks can now open ePub files on web pages and in email messages (9to5mac.com)