Marathon: Ebook Design in a Grand Tradition of Bookmaking

For some time we’ve been moaning about how bad most ebooks look, the poor typography, the feeble attempts to make ebooks look like printed books, which they do not resemble in any meaningful way.

The litany of complaints from typographers and book designers includes:

poor tools for working with ebook files

poor results from automated systems for converting files to ebooks

lack of ability to create ebooks that are formatted like print books

difficult and awkward integration of graphic elements

And the generally poor choices of fonts, settings, and control over the reading experience. Everybody admits it’s true, and we all seem to be waiting for something better to come along.

Hold Everything

After I published The Death of Book Design I got an email from Rick Gordon, a graphics professional, about an ePub book he had just completed. He wrote in detail about the processes and procedures he used to format the book and optimize it for viewing on the iPad.

I’m not technical enough to really grasp what Rick was describing, so I asked him to write it up for my blog. While he’s trying to find time to do that, I want to show you the results of his work. Here’s a spread from the book, in the iBooks application:

Click to enlarge

Here’s another spread. iBooks has a great spread display when you turn the iPad sideways, allowing you more of a “book” feeling:

Click to enlarge

The charts use the iBook’s ability to zoom graphics. When you double-tap the image, it takes up the entire screen. Notice also the careful typography in this ebook, something we usually never see. (And something I never thought I would say.) The fonts are appropriate, balanced and carefully typeset. Here’s a single page so you can see it better:

Click to enlarge

The whole thing—delicate rules, 2-color composition, pull-quote boxes, bullet and numbered lists—hangs together well, just like in a print book design. Is it perfect? No, but I don’t think that’s the point. Look at this text box set in a sans serif typeface:

Click to enlarge

This is hyphenated, justified copy that looks fine. It’s not as good as you get from InDesign on your print jobs, but it’s a huge step up from the ebook typography we’ve been seeing.

Okay, here’s one more:

Click to enlarge

I’ve never seen an ebook that looked more like a printed book. Just looking at this chapter opening is oddly reassuring. Perhaps the future of ebooks will include many directions.

One branch of development will see text escape the confines of a “book” that no longer exists in any real way in digital form. Experiments with ways to display text, the ability to publish texts of any length, and texts amplified with other media are all here or on their way.

But maybe another branch of ebook development will include tasteful book typography, on the same road Rick Gordon is traveling with Marathon, but farther along. These ebooks would unabashedly use the materials and conventions of bookmaking to create digital texts that truly are the inheritors of a grand tradition. Now that would be something.

Look for Rick’s post describing the development of Marathon soon. In the meantime, let me know what you think of this book. Do you know other ebooks that come this close to a printed model? I’d love to see them.

Joel Friedlander is a self-published author, an award-winning book designer, and an accomplished blogger. He's the founder of the Self-Publishing Roadmap online training course, and a frequent speaker at industry events where he talks to writers about how the new tools of publishing can help them reach and inspire their readers.

If you like this post, you can stay up to date with the latest information from The Book Designer by subscribing via RSS, or receive articles directly in your inbox. Then click here to download a free 24-page ebook on the top 10 things you need to know about self-publishing.

It might be worthwhile to look at some manuals of classical typography, to get an idea of the problems that old-style typographers sweated over.

As a maker of tools for the new age of typography, you may shake your head over some of their concerns and attitudes, but you may also find practices worth preserving in the digital future.

Robert Bringhurst’s Elements of Typographical Style is worth a look. Carl Dair’s Design With Type is a classic, but out of print at the moment, hence a bit expensive.

For sheer typographical geekery, it’s hard to beat Finer Points in the Spacing & Arrangement of Type, by Geoffrey Dowding. (Example: setting drop caps just a bit to the left of the margin so the cap will optically align with the body type. Good luck with that in Epub.)

i didn’t mean to imply that i haven’t done my homework…
i’ve pored over bringhurst, and read lots of other stuff too.

> you may also find practices worth
> preserving in the digital future.

yes, it is precisely because i recognize that the paper-book
is such a highly-developed and exquisitely-functional tool
that i wish to imbue its electronic-equivalent with much of
the same high-powered capability, so i study the old ways,
and try to engage today’s typographers in a useful dialog…

> Your Zen Markup Language sounds fascinating.

yes and no. on the one hand, it’s just a small part
of a tool-chain encompassing the entire workflow…

on the other hand, it represents the philosophy that
it’s easy to make it clear enough to a well-coded app
exactly what the structural aspects of a document are,
thus precluding any need for clumsy-to-apply markup.
given the fact that .html has made so many people feel
that markup is “necessary”, this is indeed a revolution…

but after the revolution has occurred, people will wonder
why they ever believed that markup was a necessity…
the youngsters will roll their eyes at such ridiculousness.

> Is it, or will it be, generally available?

allan, after years of answering such questions one-off,
your questions have convinced me that it’s time for me
to create the f.a.q. page for z.m.l. thanks for the push! :+)

Ugh, I totally forgot that full justification is the default setting on ipad (I changed that on my own machine long ago). Sorry, were you using the css hack to set text-align on span/cite for every single individual paragraph? I refuse to do this hack (and besides my workflow doesn’t make it easy), but I have to admit, it looks a lot better.

I’m all for user empowerment, but this is a clear case where ibooks could have made it easier to change justification on its control panel inside the application rather than put it on the settings screen. Frankly, I doubt that 10% of users even know that it would be possible to turn off full justification.

Yes, I used that hack, essentially. More specifically, I used abbr rather than cite, since cite would imply default italicization, and abbr simply denotes an abbreviation — semantic, but without a customarily different appearance.

For this, I may attract the wrath of those who live and die by pure HTML semantics. I don’t like it from a theoretical perspective either, and certainly it adds extra bloat; but it has been removed from the (not yet completed) generic EPUB version of the book, and it serves its purpose for now in iBooks: control over font and justification. For me, it’s a simple regular expression substitution — not difficult to do.

I prefer not to have short hyphenation in left-justified text. If there were an option to left-justify and hold hyphenation to no less than than 4- or 5-character chunks, I’d accept hyphenation for left-justified text. I generally prefer left-justified to full-justified for general text unless the hyphenation controls are more refined than what’s currently implemented.

But for boxed text, I preferred to full-justify and hyphenate (even with potential 2-character chunks) to give a more even text color with the box. I don’t like the look of ragged-right text against a colored sidebar margin.

If all the hyphenation controls available in the CSS3 spec are ultimately implemented in Webkit (and iBooks), it will be a considerably better picture.

Impressive. Also, I liked the Kindle sample — with captions under images — that mostly stayed on the same page and didn’t bleed to the following page (mostly). In Kindle for ipad, it even looks semi-decent. I realize that wide images render better than tall images (I always have problems with tall images in the Kindle), but I would like to know the image dimensions for that tall image of the lone runner (captioned: A runner in the stadion race). Did you specify the width in the HTML code?

I don’t have a problem with using different css files on different online distributors for epub files — as long as the html stays the same. (Kindle is a different matter; the format is so &##$#$ that any &&&#$$#$ trick can be excused). Another problem comes when people buying your epub are either using it on an e-ink device or a color tablet.. and so you need to accommodate both and use the same css).

About the ipad version of the marathon book, I notice that justification is turned off for the main text but not the sidebar. I see that you grumbled about hyphenation on Liz Castro’s blog here . Would it be fair to say that you have judged Apple’s hyphenation as not ready for prime time?

Perhaps, bow (hope you don’t mind the familiarity; it’s difficult speaking with someone who doesn’t give a name), you don’t know “good typography,” but it sounds like you’ve cultivated enough of an eye that you’d surely know “bad” typography if it passed under your nose.

As for your “intent to give the end user the _ultimate_ control” … Meh, is too mild a reaction. I mean, once I’ve made pages that convey the writer’s work in a comfortably readable way, I’m looking to make a book that has some element of artform to it.

If you don’t see a book as ANYTHING BUT a conveyor of words and pics, however, you likely won’t have much use for my take on the matter. But I don’t want the end user messing around with my work. No changing type, type size, or anything like that.

I’m not certain that is how bowerbird sees a book. I think the purpose of allowing a user the control to change the text size and other elements of an eBook is to provide a means by which the electronic display will be more accessible to any reader with visual impairments.

In no way, does that goal intend to destroy the beauty of a design that a book designer has poured into the end product. However, it can still be an unfortunate side effect.

Until there is a more elegant solution to accommodate people with visual impairments, increasing text-size (and thereby ruining a well-designed page) is all we’ve got to make the content more accessible. I don’t like it any more than anyone else, but I can’t justify removing all control from the user’s end in order to appreciate the content, to the best of their ability, for the sake of preserving design above all. And I really enjoy good design! :)

I’d like to think that’s where we’re headed, but sometimes you get the feeling that it’s the engineers who are setting up the goalposts, not designers. But yeah, why shouldn’t we? If we could marry the skills at long-document creation to the convenience and connectivity of ebook software, what kind of books could we make then?

I understand that the question was addressed to Joel, but I’ll put in some of my own thoughts:

1) Since Joel was referring to oustanding examples of Kindle books, we’re already outside the discussion of creating authoring tools. The Kindle .mobi format is already hampered by a 1998-ish standard of compliance, and until Amazon budges, there’s not much to do besides settle for very meager typographic posibilities and/or hack/kludge solutions to slightly improve the prospect (at the cost of breaking semantics [not a big deal for me in a closed system] and risking changed behavior between firmware versions, app variants, etc.). In fact, I did quite a bit of that sort of kludging with the Kindle version of Marathon to create titned sidebar boxes that would break between pages, since Kindle table cells will fall off the bottom of the page if too long.

In a larger sense, what I would like is what EPUB3 is moving toward: full compliance to HTML5/CSS3, with graceful degradation for unsupported features, so that we can design with at least the same degree of finesse as web designer using up-to-date tools and techniques.

There is a camp of EPUB folks who strongly feel that less is more, and who would prefer to disallow us the ability to add levels of design complexity, but I can’t buy that, and am quite sure that if we have to, we’ll just keep hacking and kludging our way through the morass, to the detriment of standards and our own sanity. I don’t want to have to do that.

my approach is to use a form of light-markup
(which i invented, called “zen markup language”)
and convert it to .html, .pdf, .epub, and .mobi…

single-source master-file. no need for indesign.
the self-publishers of tomorrow are gonna love me.

and yes, the .mobi conversion is dumbed-down,
and that cannot be helped, because it’s primitive,
but that’s also why it’s not a big concern to me…

my .pdf output is very good, if i do say so myself.

my .html is fine. i find that, for all of the formats,
there is a great preponderance of end-user options
which need to be taken into consideration, such as
straight-quotes versus curly, double-dash or em-dash,
p-book paragraph-indents or internet-block-paragraphs,
font, size, colors, margins, leading, pagesize, and so on.
these are the variables that take up most of my focus,
rather than the format-conversions themselves, oddly.

.epub makes me roll my eyes. it’s a crap format,
first of all, and i have been saying that all along…

second, it’s now plagued by viewer-inconsistencies,
and it appears there will be no quick solution to this…

third, the corporate houses which “own” the standard
seem to be doing all they can to sabotage e-books…

fourth, the techies who “maintain” the standard are
bent on making it even more convoluted than it is,
which will mean even more viewer-app-inconsistencies,
which will unfortunately gum up the works even more…

so i’ve decided i’m not going to pursue .epub very much.
because, frankly, i’m not sure it has much of a future,
and i’d rather continue inventing its _successor_, so…

anyway, rick, i’d like to see your book, but i’m allergic
to paying $9.99 and/or $12.99 just to look at _design_,
(my apps are cost-free), so i guess i’m stuck… ;+)

If you download the sample from the iBookstore (you can go through this link from Safari on your iPad/iPhone, or search in the iBookstore for “Marathon”), you’ll find that it is not DRM’d and you can peruse all the CSS along with the HTML for the frontmatter and first chapter. Be prepared for all of the funky kludges you’ve read about in Liz Castro’s book. (I take responsibility for a couple of them myself.) I did, in addition, make a lot of use of adjacent sibling selectors and CSS3 shadows. While exported from InDesign, it was completely hand-tweaked in BBEdit (though I don’t claim to have removed every vestige of unused code from my CSS).

i don’t have a designer esthetic, so i’ve had to try to
teach myself some of the main principles, and i might
have gotten some things wrong… but there remains
a bunch of stuff in these versions that still make me
cringe, most of which are simply outside your control,
and which reflect quite poorly on the viewer-programs.
a real designer like yourself is probably bothered by
these things even more than i am, so you have my
empathy and sympathy. that’s all for the _product._

as for the _process_, it seems rather convoluted to me.
the writer does some markup while writing, most of which
you strip away when you put it into indesign… then you
do a bunch of work in indesign to make a print-ready .pdf.

(is there available the .pdf matching the sample books?
i’d love to see what this book is “supposed to” appear,
as represented by the way the p-book actually looks.)

then you take the work _out_ of indesign and rework it
in bbedit. i fully realize that this is the workflow which
the world has handed you, so it’s not really your “fault”
that it’s so clumsy, but it _is_ clumsy. and convoluted…

Hey Bowerbird, good to see you. It’s no secret what I want: ebooks with great typography in which the extent to which the user can change the display is determined by the designer. I want ebooks that look as good—or better—than printed books, with the same kind of control over relationships between objects and type and the same ability to precisely control all the typography. Thanks for asking.

joel said:
> It’s no secret what I want:
> ebooks with great typography

joel, like i said, i don’t really have
a designer esthetic in my head,
so i need to see some examples…

you might implicitly know what
“good typography” is, but i don’t.

> in which the extent to which
> the user can change the display
> is determined by the designer.

and there, you swerve into philosophy.

and, i might add, questionable philosophy.

my intent is to give the end-user the
_ultimate_ in control, if they want it,
and to free ’em from worrying about it
if _that_ is what they’d prefer to have…

i’m not adverse to giving the designer
the ability to specify default rendering.
indeed, i think that would be ideal…

but in terms of preventing the user from
changing that rendering? no way, jose…

i’ve never seen a designer use anything
except curly-quotes, but i know that users
often _prefer_ straight-quotes, and i am
not going to deny them that preference…

rick’s book prevents the user from changing
the font, short of going in and changing the
stylesheet, and i find that completely appalling.

i also observe that most p-books full-justify
their text, but rick’s book used ragged-right,
even when i tell ibooks to turn on justification.
so i’m a bit perplexed by that. to me, that alone
makes it such that it doesn’t “look like a p-book”.

i am also bothered by things that you cannot
control, but which the viewer-programs should,
like controlling for widows and orphans, and
making sure that the page-bottoms balance…

I’m currently working on an iBooks-only book series (with much appreciated advice on the #ePrdctn Twitter hashtag from Rick!), but this is because it has audio (there may be a Kindle app version, but for now my director has told me to focus on iBooks).

It is such a chicken-and-egg issue. What comes first?? We want more resources to produce more ePubs in-house, yet that won’t be funded by corporate until we produce more.

Our approach (for now) is to target all eReaders (Kindle, Nook, Sony eReader, Google Books, Kobo, iPad) with a certain amount of titles, and at the same time, target specific eReaders (like the iPad) with a (smaller) set of titles – to see what sells, what works, what we should put our efforts into and what we shouldn’t. This year it’s very much a try-it-and-see approach for us, but we won’t know anything until we try. It’s a balancing act of experimenting and producing revenue for publishing right now. Most days I find this fascinating, some days it does drive me nuts.

This ePub really raises the bar. I’ve been going through the sample version on the iPad and it is interesting to note some of the tricks he has employed.
I like one kill switch being used in particular: The built-in fonts trump any preference changes by iBooks. Going from Baskerville to Verdana, for example, merely affects the size and leading of the text, but does not actually change any font.
I also like the use of the tinted boxes and the drop shadow elements. It looks like the drop shadows are actually added separately from the image. If that’s the case, it must have taken a lot of patience to get the alignments in that code right.
Much praise to Rick Gordon for showing us the future of iBooks, and hopefully, all ebooks.

Thanks to Rick for sharing and Joel for presenting. Walt has raised the big issue. I mean, is the juice worth the squeeze if we’re going to have to put real time in for each version. Moriah’s hit the nail on the head as far as that goes. There’s a point where those of us who make many books will have to decide how much time to how much we’re making on the whole job makes it worthwhile. On the other hand, if we’re going to have a shake out and one format survive, that would settle things and then I’d wish for it to happen soon. But I don’t see that happening quickly, as each device and format still seems viable.

Stephen, this is one of the reasons I don’t want to get involved learning ebook conversions. (That is, besides the fact I have no interest in messing with code when I can be messing with typefaces and layouts.) But from my experience, I think there are plenty of authors who would be willing to pay for the time it takes to create a gorgeous ebook. You can’t get that from the $99 conversions, it requires a lot of handwork. Thanks for pitching in.

The software to produce ebooks is a bit behind the tech at this point. I just took an ebook production class and as helpful as it was, they told me that as soon as I got home some of what we went over could already be obsolete. The biggest challenge for me is continuing to learn html, css and Dreamweaver – developing a command of type in ebooks equally comparable with my command of type in CS5. Not easy. Yet.

The Kindle? If the tech on it is going to be an afterthought, then we should treat is as such. Keep things simpler and walk it backwards from the more design-friendly platforms. It’s a totally different file type so we probably have to dedicate it’s own version unfortunately.

I do think the future will get better in terms of capabilities and the software becoming more intuitive for the designer.

Derek, that seems to make sense to start with the most design-capable formats and work backwards from there. Still, it seems from the outside like a difficult, unpredictable and technical task that’s really completely divorced from what we think of as design. Thanks for the input.

Taking my print version to ebook has been quite the challenge as it is heavily formatted with graphics and poetry. But seeing Rick’s work on Galloway’s “Marathon” beautifully rendered on the iPad is very encouraging. Granted, this is just on one device. As Walt said, I, too, would like to see it on a Kindle, or a Nook, or a… But from what I can see in the pages offered here, sure looks pretty damn good on the iPad.

And maybe that’s the hurdle we as authors/publishers/artists have to deal with to insure our works are represented to the best of our abilities on multiple devices (if we choose to do so). The PDF file from our print book (if that’s where we’re starting) is not the be all end all source for myriad outputs. As much as it pains me to think about it, we very well may have to approach each output device as its own formatting project (with subtle and not so subtle tweaks for each version).

I just finished formatting my book for the Kindle (in review status over at Amazon as I type). The preview they give you and the mobi file on my Kindle seem to be a pretty close approximation to what the print book has. But I haven’t downloaded the ePub file to an iPad yet, nor a Nook. I can only imagine there will be tweaks involved on both of those.

Where does that leave us with projects coming down the pike, either for ourselves or clients? Probably more headaches and learning curves (the coding I’ve had to learn in the past month…). But until all devices play nice with one master source file (wishful thinking), I reckon I’ll be keeping the Excedrin bottle handy.

That is one of the nicest ebooks I’ve ever seen. In fact, it is the nicest. The pages look fantastic.

It’s true that ebook formatting is tough– I use professional ebook designers, and even then, it’s tough to get something that I like. The finished product never looks as good as the printed book. But it looks like designers are getting more savvy about this. Which is good, because ebooks are quickly becoming an inescapable part of this business.

Interesting project and nicely designed. However, these pages are displayed on the Apple iPad using the iBooks app. Before deciding on the overall value of the layout, I would want to see the same pages:

(1) displayed in Adobe Digital Editions and on the NookColor, Kobo and other eReader devices

(2) displayed with a reader-selected font and larger font size on iBooks

(3) displayed in the many other ePub apps on the iPad

Also, what’s his plan for a Kindle edition? After all, Kindle books far outsell ePubs sold through the Apple iBookstore.

The real trick is to design an eBook that looks good on all platforms. I have been contending for some time, and still do, that it is not necessarily a good investment to strive for an optimal iPad iBooks experience.

We sell a lot of eBooks and create them in both Kindle (mobi) and ePub formats, with the latter available on all of the major eBook retail sites. To date, 70-75% of our eBook sales are through the Kindle Store, and that percentage is, if anything, increasing (total numbers sold is increasing across the board in both formats). They may be read on an iPad, but they’re sold in mobi format through the Kindle Store.

Walt, good points, and I hope someday we get to the point where books like this can be displayed on many ereaders, not just one.

Rick was very specific about designing this book primarily for iPad and, with 15 million units and counting, I’ll bet he’s hoping, like a lot of us, that books become more popular on the iPad than they are at the moment. This book is like a lot of other content coming out solely for the iPad, which seems to be a much better platform for designers and typographers.

What was encouraging to me was finally seeing an ebook—of any kind—that actually looks decent and book-like. I think that’s pretty neat.

I’d love to see outstanding examples of Kindle books. Do you know anyone who has posted them?

The Kindle version is available at http://www.amazon.com/dp/B004I6D6WG. I think it looks quite good on the Kindle hardware, and loses something in the apps due to some app-level mishandling of some top/bottom margin specs. So my spacing intent is as it is on the Kindle device. And yes, it sells much better.

@WaltShiel does have a very valid point concerning this approach vs. a generic approach. The iBooks version has major problems in a non-webkit-based reader. A generic version is yet forthcoming, but stalled by more immediate print book priorities.

@MoriahJovan: The answer in short is too long, but I attribute a great deal of that to learning curve. This was my first full-fledged eBook project, and in the future, I would modify my workflow considerably: 1) Locate the optimal split point for forking code between generic, Kindle, and iBooks versions. 2) Not use iBooks as my primary feedback mechanism in those earlier stages. And more to come…

I did quite a bit of proofing for a variety of font sizes. Obviously, when getting to the extremely large fontsizes where there are just a few letters to take up the width of the page, things don’t look “normal,” but it’s readable.

Regarding font changes, I locked in the font face, even on p, li, and such, so they stay in Palatino, although the size and leading varies slightly through some mechanism outside of my control.