Use Typecast to design for the reader by putting type first. Try it now

As of January 1, 2018, we are no longer providing support for Typecast. Our apologies for the inconvenience. Thank you.
« Back to Blog

Ditching the Shoehorn: Designing Type That Works on ePubs, Mobi and the Web

on Tuesday 26th of March 2013

Designing typography that works across multiple platforms is no small task. Today, Stewart Curry of Woopie shares what he’s learned in the publishing trenches.

Multi-device publishing
Sub-compact publishing is a complete re-evaluation of the tools and outputs of publishing for a digital world. Defined in a fantastic (and beautifully designed) essay by Craig Mod, it questions the fundamentals of how magazines are currently created for digital and how they can be made better by letting go of some of the baggage from the past.

My teammate and I are developing a platform called Woopie to help people do just this – publish to the web, eReaders, mobile and tablet in lots of different formats. In this article, I’d like to share some insights into how to design and work with type for (responsive) web, ePub and mobi – for devices with browsers as well as to eReaders. While there is some crossover, not all readers are created equal, so there are plenty of fallbacks and enhancements to consider.

Choose your weapon: replica, responsive or customized pubs?

There are a few options for publishing magazine-style content for devices at the moment. The most popular tools create so-called ‘replica’ editions. They take a file designed for print (typically a PDF) and wrap a reading container around it. This can be a page-flipping tool (for the web) or an app (for tablets). These tools usually allow you to overlay links, video, image pop-ups, etc., but they have their limitations.

Perhaps the biggest is that you are taking something designed for one particular format and shoehorning it into an entirely different way of reading. You’re wedging the fixed size, layout and reading conventions of print into the infinite canvases of the web, where reading conventions are constantly evolving. As a result, replica editions create issues like:

  • scrolling up and down excessively to read columns of very short text-length;
  • pinching and zooming to read 10pt text on a mobile;
  • text being illegible on a Kindle; and
  • enormous file sizes. (Many replica editions are just picture of pages, not real text, and screen readers don’t handle this load well at all).

Plus, replica editions are tied to a particular app or platform, so you’ll need to create another version if you want that content available for web browsers.

An alternative and much smarter approach is the responsive web design route, particularly if you are creating something that will only appear in digital format. This gives you much more control over design specifics across multiple sizes, meaning you can create a much better reading experience. There’s also a file-size and accessibility benefit. The downside? You’ll need to develop apps and/or ePub versions if you want people to be able to consume that content offline on an eReader or download it from Newsstand.

Developing many different versions of the same content from scratch for many different platforms is incredibly time-consuming, which is why I like to use a third, hybrid, approach. This lets me:

  • create multiple versions for different devices without having to start each from square one;
  • send my content to a web view, custom app, and other formats; and
  • harness the native features of devices, yet still be responsive and web friendly.

Here are some lessons I’ve learned along the way.

Remember the stack

When creating for multiple devices and platforms, you give up control over how things can appear and embrace the uncertainty of it all to give your readers a better product. The only constant will be your words, so a strong editorial hand and consistent tone-of-voice will help define consistency where branding cannot.

Testing web and system fonts in Typecast

Typecast’s side-by-side template is handy for testing fonts. The left container uses Typekit fonts for anyone using web browsers to access the content. The right one uses fonts I know are native to iOS for those using iBooks.

Web fonts and tools like Typecast are fantastic at giving us more choice in our typography and helping us use type to convey personality and brand. When using them, however, it’s important to remember your stack. Research the devices you are pushing to to see if they support the fonts you are using, and if they can’t, try to find similar fonts that are built in to the device. Typecast is a great tool for this because I can test and compare web fonts side by side right in the browser.

List of compatible fonts by OS/platform

Know which fonts are supported on the platforms you want to publish to.

iOS has a reasonable range of typefaces (and you can embed fonts for iBooks, though make sure you have a licence). Android is pretty poor, and for Kindle there’s not much you can do. Some Kindles let folks use publisher-defined fonts, but most people will just leave it as native. Jordan Moore (former Typecast designer and now emerging responsive web expert) has a great list of fonts and compatibility on his site.

Take extra care when embedding fonts

Don’t forget you might also be publishing an off-line version, so hosted web fonts won’t be served either. If you choose to use embedded fonts with @font-face, first check the licensing to make sure it’s allowed, and next – test, test, test.

You can use @font-face with pretty much every modern browser and some devices that use ePub formats (for example iBooks on iPad and the more recent Nooks), but you really need the devices on hand to make sure they display in the first place and actually work well. You can use .ttf, .otf, and .woff in some cases, but here are a few things to watch out for:

  • Case Sensitivity – Browsers are pretty lenient on us, but ePub (as a format) is a total jobsworth. Make sure your filenames and references to them in the CSS are the same case.
  • Paths – Double check your paths to make sure they are correct. I keep my CSS, fonts, and HTML in separate folders on the same level for ePub, so the path for fonts from CSS is: src: url(”../fonts/fontname/fontname-webfont.eot”).
  • Sizing – Using pixel sizing for font-sizes and line-heights can sometimes cause conflicts with font-resizing in ePub. If you have problems with text sizing and line-heights (especially when increasing text size on the device) try using em units instead of px, with 1em for body copy, em units for headings, and unitless line-heights.
  • Extras for iBooks – iBooks need a special meta-file to make it use embedded fonts, called META-INF/

Learn to love progressive enhancement

We’ve all been through the mill when it comes to cross-browser testing. I still have nightmares about Netscape 4 and IE 5.2 (just for the Mac). Well, bad news – ePub and mobi are probably worse when it comes to compatibility. For example, not every device will respect rules, margins, borders, padding and font-styling, either because they can’t display them at all or because they don’t like your syntax or shorthand. This is mainly because vendors make their own versions of standards.

Progressive enhancement is your friend here. Build up your design stylings, but be aware they won’t translate to everything. Baldur Bjarnason’s epub feature grid is good for seeing which devices and formats can render certain features, and here’s another just for Kindle Fire.

Three stylesheets for three levels of capability

Here’s how I’ve been tackling the issue of designing for a wide range of devices, from an iPhone that can play streaming video to a Kindle with a black and white screen. Rather than start from scratch, I start with an HTML version. When I’m done, I “fork” my content into different versions for epub and exporting to apps.

First off, I make a distinction between old-school .mobi (that’s your black-and-white Kindles and Nooks) and group web and epub together. Then I split my CSS for web and epub in two: a base version for both, and a version with media-queries for the web. An easy way to achieve this is to have individual container templates for web and the different epub formats:

  • kindle.css –This is a baseline formatting CSS. It uses percentages for font-sizes and margins, and ems for line-height. Think of it like a normalizing CSS file.
  • epub.css – This has all my styling except media-queries. It sets fonts, font-sizing, line-heights, borders, margins, padding, etc. All the styles you would have normally for a web page if you weren’t being responsive. I leave out things that don’t work well for ePub (for example changing the page background color – remember this is something that color eReaders allow users to override easily, so leave it white.) If this ends up looking like a styled version of Safari’s reader view – or Instapaper with your fonts, colors and styling – then you’re on the right track.
  • web.css – This has all my styles including media-queries. I also add in anything I want to change in the normal (whatever that is) web view that I can’t do on ePub. This would be stuff like floating elements,  pull-quotes and images, or adding color behind headings.

How do I do this? Sass (or LESS) is perfect, as it lets you create partial CSS files. For starters, making media-queries an extra file is a good way to reduced your design workload.

Then I just drop my content into them when I’m ready to export, with a few scripts and regexes to fix the content for each version’s requirements and quirks.

Avoid these gotchas

Here are some things that had me pulling my hair out. Hopefully I can save you some time and stress!

Missing media

Make sure you have a fallback for all your multimedia content, whether it’s a placeholder image or a link where they can go and view it later on another device.

Styles not displaying

  • In flowing ePubs, backgrounds usually won’t fill the whole page, so don’t use dark backgrounds. Keep it white.
  • Link colours will get overridden in iBooks. You can override that by recoloring the text like so: -webkit-text-fill-color: #00f;
  • Borders seem to work in most devices, but don’t rely on them. For .mobi (old school) you can use 
tags as rules, but use sparingly.
  • Sometimes a device’s default style will override your styles, so stick a class on styles to be more explicit.
Background colors sometimes don't fill whole page

Background colors on ePubs (left) won’t always fill the whole page like they do in the browser (right).

Unexpected spacings

  • eReaders have big margins and the user can change them, so be aware of your text sizing, in particular how large you make your headings. Try not to have too large a ratio between body text and headings.
  • Use page-break-avoid to try and keep related content (for example figures and captions) on the same page. In fact, your first stop for formatting help should be Liz Castro’s blog.

    Bad directions

    Don’t refer to things like pull-quotes and images as being “to the left” or “above right” within your content, as in eReaders they can be positioned in a single column. Use figure references and captions instead. For example, “Blah blah blah [see fig 1]” is better than “See the box on the right”.

    If you’re feeling fancy you could always use media-queries like content:after and some empty spans to get around this, but that might be showing off.

    Testing on multiple devices

    Where possible, test with real devices. Emulators and viewer apps are okay but can be pretty buggy. I like to test with Edge Inspect for testing across devices and Epubcheck for validating my ePubs. Dropbox is the easiest way to get files onto tablets, and Kindle Previewer is good because it converts to mobi for you and shows you a preview. However, it can lie, so test on your devices too.

    Creating a publication and making it available to lots of people and devices can be very challenging but very rewarding. It gives you a much wider marketplace to sell your content, and it also gives your readers much more choice about how they consume it. If you try it yourself and find yourself stuck, just ping me @irishstu

    We’d like to thank our guest author Stewart Curry for writing today’s post. For more from him, check out his blog.

    Guest authors are paid for their contribution, and all opinions are their own. If you’d like to write for the Typecast blog, get in touch with shelly dot wilson at typecast dot com

Type on Screen

Get more web type tips, interviews and design gems by email

Hook me up!


blog comments powered by Disqus