Fonts Guide
Fonts Guide
to Fonts
for E-Books
FEATURING
How to choose & find fonts…
Guidelines for embedding…
Using fonts legally…
Obfuscation & Subsetting…
Best Practices for QA…
And more…
Field Guide to Fonts for E-Books
Published June 16, 2014
1| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Field Guide to Fixed Layout for E-Books was prepared for the Book Industry Study Group, Inc. (BISG) by
members of the Content Structure Committee’s Fixed Layout Working Group.
ISBN 978-1-936757-31-2
Copyright © 2013, the Book Industry Study Group, Inc. All rights reserved.
The Book Industry Study Group, Inc. (“BISG”) owns all rights to this publication Field Guide to Fonts for E-
Books and the copyrights therein. This PDF is made available free-of-charge. Anyone who downloads it may
post a copy on his or her company’s secured intranet server or unsecured website or distribute it in physical
or digital form to others. Anyone wishing to use parts of this PDF in presentations, blog posts, speeches, etc.
should first request permission of the Book Industry Study Group by emailing [email protected].
Contributors:
Bill Kasdorf, Apex CoVantage
Karina Luke, Book Industry Communication
Julie Morris, Book Industry Study Group
Heather Reid, Copyright Clearance Center
Thomas Phinney, Extensis
Joshua Tallent, Firebrand Technologies
Garth Conboy, Google
Liz Kessler, Hachette Book Group USA
Chris Mitchell, Hachette Book Group USA
Lucy Albanese, HarperCollins Publishers
Laura Albert, John Wiley & Sons
Ben Dugas, Kobo
Robert Kasher, Macmillan Publishing Solutions
Paul O’Neill, MarkLogic
Nancy Singer, Nancy Singer Design
Bob Anderson, Penguin Random House
Sara Dayton, Penguin Random House
David Haase, Penguin Random House
Andew Peltcs, Penguin Random House
Adam Royce, Penguin Random House
Dan Sanicola, Penguin Random House
Samantha Cohen, Simon and Schuster
James Yanchak, Taylor and Francis
Steve Kotrch
2| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Table of Contents
INTRODUCTION
Chapter 1 | OVERVIEW OF FONT FORMATS
Unicode
PostScript Type 1
TrueType TTF
Advanced Layout
OpenType TTF and OTF
WOFF
Format Conversion
Chapter 2 | SELECTING FONTS
Available Styles: Bold and Italic
Character Sets
License as a Selection Criterion
Chapter 3 | EMBEDDING FONTS
A Font Rule
@font-face
Chapter 4 | STYLING & FORMATTING
On Bold & Italic
Referencing Non-Latin Characters in E-books
Fractions
Chapter 5 | QUALITY ASSURANCE TESTING
Chapter 6 | LICENSING & RISK FACTORS
Free Fonts
Font Management
Chapter 7 | FONT PROTECTION
Intellectual Property
Font Creator Positions
Obfuscation: A Unified Effort
Subsetting Fonts
3| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Tools for Subsetting
Chapter 8 | INDUSTRY STANDARDS
Appendix A | DEFINITIONS
Appendix B | RESOURCES
4| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
INTRODUCTION
And yet, since 2007, we’ve become over-familiar with Arial, been beaten down by Times
New Roman, and read enough in Caecilia to blind any perfectly sighted human. It is only
since late 2010, with the emergence of fixed-layout EPUBs, and later in 2011, when
Amazon released its KF8-enabled Kindle Fire tablet, that we’ve seen our industry begin to
seriously consider typography’s potential in digital books. For the first time in a fifteen-
year history of e-reading we finally have broad reading system support for custom fonts,
and we are eager to take advantage of it. The industry has the will, and the Book Industry
Study Group hopes that this document will help show the way.
The way, however, presents a few challenges. In our view, publishers face four major
hurdles in rendering custom fonts in their e-books:
Selecting screen- and e-reading-appropriate typefaces with complete character sets: You’ve
probably noticed that reading slender fonts on screens can cause fine wrinkles around the
eyes. Some other fonts, no matter their weight, just aren’t particularly legible on-screen and
are even worse on ancient e-ink screens. Some cause text to render slowly. Professionally
printed books typeset in Adobe Garamond on eighty-pound ivory paper will look about the
5| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
same no matter where a customer buys that book. But the same font on screens of different
contrast, resolution, and power can render substantially differently than they do on paper
and across different devices.
Beyond accounting for fonts’ interactions with devices’ reading screens, designers need to
ensure that we choose fonts with character sets and variants—italic, bold, bold-italic—that
fully meet the needs of our books. That means accounting for fractions, diacritics, and other
symbols, as well as all variants. Using strokes and skews is an option for printing, but not in
most reading system environments.
And, of course, there is the challenge of accounting for devices that default to standard
displays of color, font, alignment, etc. instead of the e-book designer’s own (beautiful and
carefully considered) “publisher” display settings. Likewise, we must assume that many
users will choose to change the fonts even if they see the designer’s settings. Write the
phrase “HELLO WORLD!” in a small-caps font in InDesign and you see small caps no matter
the case of the letters you typed. But when a user changes the font, she sees the text exactly
as you typed it, perhaps “Hello World!” Use of <font-variant: small-caps> should
allow small caps to be displayed correctly, regardless of font choice. Similarly, if you are
distinguishing between two characters’ speech using sans-serif and serif fonts and the
reading system is displaying the text with its default settings, users will not see a difference
between the characters’ dialogue unless you define fallbacks.
Licensing the appropriate rights to embeddable typefaces and storing records of those purchases
and rights: Not having had Professor Trelawney at the helm of our 1990s publishing
technology teams, most of us did not acquire the explicit rights to embed fonts—let alone
EPUB-embeddable font files—that we licensed for print in salable electronic documents.
Now we dust off our old end-user license agreements (EULAs) to learn that many do not
specifically grant or deny electronic embedding rights. Often it takes a lawyer to decipher
what those (thousands of) documents say. And going forward, the situation promises to be
similarly fraught: today’s font licensors, whether corporate font foundries or individual
artists, offer non-standardized EULAs that do not necessarily treat comparably the major
6| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
components of the license: medium of use, length of use or number of uses, number of
users permitted to use the font at any given time (seats), and how the font files must be
protected.
Storing, classifying, and protecting the font files themselves: Like InDesign and Excel, fonts are
software. Only so many users can access them at a time, and they cannot be copied, e-
mailed, or taken home for personal use. How do we enforce these rules? Further, there is
the challenge of classifying the fonts so that your users can find, say, a destroyed, gothic,
serif typeface without searching back and forth between Identifont (What font works for
my content?) and your font database (Do we own this font? No? Back to Identifont!). Where
do we store the fonts and their metadata, and who takes on the enormous effort of tagging
fonts that have no internal metadata?
Embedding or calling fonts in e-books in ways that are technically sound, supported by all reading
systems, and compliant with the licensors’ EULAs: Following the IDPF EPUB specification for
embedding fonts is the easy part. But marking up your EPUBs so that the fonts render
consistently on all reading systems is a little trickier. And doing that while honoring the
licensors’ requirements for protecting their fonts is actually impossible in some cases.
Many EULAs call for the subsetting and obfuscation of fonts, methods of protecting fonts
from being extracted and used for other purposes that do not necessarily jibe with giving
your e-book reading software access to those font files.
7| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 1 | OVERVIEW OF FONT FORMATS
There are three major font formats: PostScript Type 1 (not supported in e-books),
TrueType (including OpenType TTF), and OpenType CFF (OTF). Additionally, a WOFF
wrapper may be used on a TTF or OTF font. In this chapter, we are mostly concerned with
the underlying formats, TTF and OTF.
Both formats are scalable outline fonts, which can be rendered at arbitrary sizes. The
quality of that rendering, and its effective minimum size, are factors of both the font itself
and the rasterizer, the engine that renders the font into bitmaps on-screen (or in print).
OpenType and TrueType fonts have fields built in that can include the license terms
themselves and/or link to the license. The problems are that not all font vendors put the
license information in the font package, and even when they do, it isn’t easy for users to see
without specialized tools.
Unicode
Unicode is a universal character encoding system. In an encoding, every character gets a
number. Unicode is the most common encoding these days, having generally gained
acceptance back in the 1990s. It is a superset of all encodings that came before it, and gives
a unique slot for every character. It is used in TrueType and OpenType fonts, in that there
is a table (CMAP) that maps from Unicode codepoints to glyphs in the font, providing a
default glyph for each codepoint. (There can actually be multiple CMAP subtables, but that
is beyond the scope of this document.)
8| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Note, however, that Unicode covers characters, not glyphs. If something represents the
same character, and behaves the same way for text processing, a difference in appearance
does not give it a separate slot in Unicode. For example, only a few ligatures have slots in
Unicode, and then only because they had slots in older encoding standards; true small caps
do not have slots in Unicode (only the ones used in phonetics do); oldstyle numbers do not
get separate slots. Those examples are all treated as style differences, not different
characters. (See character and glyph in the glossary, and this article.)
The phrase “Unicode font” is not particularly clear or helpful when talking about fonts. All
OpenType fonts and all modern-era TrueType fonts have a Unicode encoding, using the
CMAP table to map Unicode characters to glyphs in the font. This does not mean that any
given font supports any particular Unicode character. Indeed, as Unicode has about
100,000 characters, and TrueType and OpenType fonts can encode only 64,000 characters,
it is literally impossible to have a font that covers all of Unicode.
In addition to being a standard encoding, Unicode provides data about the characters it
encodes, and about the processing of those characters. However, the actual infrastructure to
do that processing is beyond the scope of Unicode. Just because an application or a reading
system can handle Unicode codepoints does not mean it can display them properly.
Examples of this issue include not only right-to-left text processing (needed for Hebrew
and Arabic), but also other operations needed to handle complex writing systems or
complex scripts, such as Arabic and the Indic languages.
A portion of such processing can be taken on by the font itself. Advanced layout
technologies, such as OpenType or Apple’s AAT, can help with this, as described below.
PostScript Type 1
PostScript Type 1 fonts, commonly referred to as just PostScript fonts, were the original
general-purpose scalable font format used across vendors and systems from the time of
their introduction by Adobe in the mid-1980s.
9| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Different “flavors” of Type 1 were developed for Mac OS, Windows, and Unix. The Mac files
involve resource forks, and the Windows and Mac types both have platform-specific info;
none of the different types are installable across all platforms.
Type 1 fonts have a relatively simple and reasonably flexible hinting system. Hinting is
extra code in the font that is intended to help rendering systems optimize the appearance
of the rasterized font at lower resolutions, such as on-screen. The Type 1 approach to
hinting was to use simple hints and rely on intelligence in the rendering system.
When Adobe joined with Microsoft to create OpenType in the late 1990s, it began to
deprecate the Type 1 format in general, and stopped producing new Type 1 fonts. New
fonts from Adobe have been OpenType–only since about 2000. Many other foundries have
stopped releasing their new fonts in Type 1 as well, preferring OpenType (whether TTF
or OTF).
Adobe abandoned Type 1 because it was a subset of what it could do with OpenType but
lacked direct Unicode support and advanced layout support. Further, it was not a modular
format and not easily improved upon. OpenType is capable of all of those things.
However, publishers and designers often have huge libraries of fonts, and they are often
mostly in Type 1 format. While most other publishing processes still support Type 1 fonts
just fine, they are generally not supported in web fonts, nor in e-books, as the latter are built
on the web font specifications.
Options for dealing with Type 1 fonts in an e-book workflow include substituting an
equivalent OpenType font (most old fonts have newer OpenType versions available) or
possibly converting the font file itself (see Format Conversion, below).
10| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
TrueType TTF
TrueType fonts were first released in 1991, invented by Apple but shared with Microsoft in
a technology swap. TrueType’s underlying modular, table-based SFNT file format was
adopted by several later formats and advanced layout technologies, including OpenType,
GX, Apple Advanced Typography (AAT), and Graphite.
Apple’s version of TrueType originally used a distinct format with a resource fork. Later,
Apple tried to do without resource forks and packaged its system TrueType fonts as dfonts
(data fork fonts), while also supporting the formerly Windows-based TTF flavor. Today,
most new TrueType fonts use the TTF extension and work on Mac, Windows, and other
platforms, and use a Unicode encoding. Apple bundles its own system fonts in the variant
TTC (TrueType Collection) format that allows fonts to be packaged together and share
certain tables—an approach invented by Microsoft that it uses for some of its East Asian
fonts.
One of the reasons Apple originally invented TrueType was to allow very detailed and
smart hinting (see Type 1, above), and to control exactly what pixel pattern was created by
the fonts on-screen. The disadvantage was that to get better results than one would get
from PostScript outlines (such as Type 1), the hinting had to be done manually by
somebody with specialized expertise at it.
Both Apple and Microsoft later retreated in varying degrees from the pixel-level-control
philosophy. Apple ignores the hinting information in fonts for rendering in Mac OS and iOS,
except at sizes below those normally used for text. However, Microsoft operating systems
and some third parties still get better on-screen results from hand-hinted TrueType
outlines than from anything else.
TrueType also uses a different mathematical description of font outlines than PostScript
(quadratic beziers instead of cubic beziers). Between the simpler math requiring more
points for most shapes and the bulky hinting code, TrueType fonts tend to be a bit larger in
11| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
file size than Type 1 or OpenType CFF (.otf).
Advanced Layout
Fonts can offer advanced layout capabilities for either of two reasons: (1) complex-script
languages can require such capabilities of the font, just to get basic typesetting done, and
(2) fonts can offer additional nice-to-have typographic bells and whistles for layout in
general (which are not basic requirements for English), such as ligatures, oldstyle figures,
small caps, and contextual alternate glyphs.
Apple did its own advanced font technology, originally called GX, later rebranded Apple
Advanced Typography or AAT. Unfortunately, it is Mac only. Apple also supports OpenType
a fair bit (with more coming), including for Arabic and more recently the major Indic
languages. But there are more languages that will not play well across all platforms and
devices with embedded fonts, unless those fonts have both AAT and OpenType
functionality built in, which is very rare indeed.
Note that there isn’t a particularly firm dividing line between TrueType TTF and OpenType.
A file with a TTF extension can be a plain old TrueType font, or it may have additional
tables making it an OpenType font—and the dividing line is somewhere between thin and
nonexistent. Files with OTF extensions are always OpenType fonts, almost always with
PostScript outlines.
WOFF
WOFF is essentially a wrapper for OTF and TTF fonts. It serves several functional purposes.
12| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
First, it is a compressed format. Second, rather than compressing the entire font in one go,
it compresses tables of the font separately, allowing for a client browser to decompress
only the parts it needs. Third, it allows for metadata to be placed in the uncompressed
outer portion of the file, where it can be read quickly and easily. The metadata can contain
licensing/usage information, but is not intended as an enforcement mechanism.
Additionally, WOFF is generally preferred over raw OTF/TTF fonts by the people and
companies that make fonts. This is because WOFF fonts are not directly installable on Mac
and Windows, making casual piracy less attractive. While unwrapping WOFF back to TTF
or OTF is technically quite trivial, it at least provides a minimal level of protection for the
font file, so that a user must do something active to make it usable as a desktop font (in
addition to extracting it from the e-book , browser, or other device/reading system).
WOFF is a core format for EPUB 3, but it is not widely supported in earlier reading systems
and devices. It is maintained by the World Wide Web Consortium (W3C). An updated
WOFF 2.0 format was released as an initial public draft on May 8, 2014, with improved
compression (http://www.w3.org/TR/2014/WD-WOFF2-20140508/).
Format Conversion
Given that there are many fonts in PostScript Type 1 format, which e-books generally do
not support, publishers may be tempted to convert these fonts to TTF or OTF. Technically,
this is quite possible. Font-editing software (such as FontLab Studio, Fontographer, or
RoboFont) can generally do this, and a dedicated font-conversion program such as FontLab
TransType 4 makes it easy to do without much chance of error. However, there are several
considerations and issues in format conversion.
Licensing is almost always a problem. Aside from open source (“libre”) fonts, most font
licenses do not permit modifications of fonts, including format conversion. When in doubt,
check your license, and if you can’t find it, contact the licensor (foundry or distributor).
13| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Character set may be an issue. Old PostScript fonts had severe limitations on encoded
glyphs, which means that (aside from the East Asian CID-keyed variant of the format or
fonts intended solely for use in TeX typesetting) such fonts generally had more limited
language coverage compared to more modern fonts. Although western European language
support was the norm, anything beyond that usually required a separate variant font (e.g.,
Helvetica CE or Minion Cyrillic). Font makers often added characters and language support
as part of their conversion to OpenType.
Even the euro currency symbol is missing from most PostScript fonts—and newer currency
symbols such as those for the Indian rupee, Russian ruble, Ukrainian hryvnia, and Turkish
lira can’t be easily supported in that format.
Of course, pre–OpenType fonts also won’t have OpenType features and alternate glyphs,
such as multiple figure styles or real small caps. In some cases, if they do have alternate
glyphs, they may be encoded incorrectly (such as the “expert sets” that put f-ligatures in the
V-Z slots), causing huge problems if they are used in e-books—consider search, spell-check,
and what happens to display if the embedded font is not used to show the text.
14| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 2 | SELECTING FONTS
For print, designers choose fonts that will project the look they intend, and they consider
factors such as format, quality of letterforms, cost, and licensing provisions. When choosing
fonts for e-books you must follow those same guidelines, but take special care to work
within the limitations of the software and devices. Keep in mind that licenses purchased for
desktop/print usage do not necessarily permit using those fonts in e-books; a separate
license is often required.
For e-book creation, all fonts selected should be OpenType (TTF or OTF), and embedding
rights for e-books must be obtained. Licenses purchased for desktop/print often do not
cover you for e-book embedding rights.
Character Sets
Does the font have the character set you need? Does it have a basic standard character set
15| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
(MacRoman + WinANSI), or are some characters missing? Does it cover any additional
languages you might want? Does it have any special characters you might need? For
example, a designer may need some less common or newer currency symbols, such as the
new Russian ruble and Indian rupee symbols; or specialized math symbols.
With newer professional fonts in OpenType or TrueType, it is fairly common for the type
designers to include support for central/eastern European languages that use accented
Latin characters, including the Baltic languages, Polish, Hungarian, Romanian, and Turkish.
More extensive Latin support, such as for Vietnamese, is less common. Including Greek and
Cyrillic support as well, all in the same font, is also uncommon, but not at all unheard of.
Special care should be taken when choosing fonts for projects with special language
characters or math characters that are not in most fonts. Several methods of supporting
such characters do not work reliably in e-books.
In print, any arbitrary glyphs can be created and added to a font, using arbitrary and
potentially bogus encodings, or even as unencoded glyphs. This is not true for electronic
publications. Generally e-books do not support direct use of unencoded glyphs, and using
standard slots “incorrectly” often fails because many e-book reading systems do not
necessarily use the embedded fonts (either by default or due to user preference settings).
This can cause incorrectly encoded characters to display as a corresponding character from
a different font, and hence as something else entirely. So document creators should beware
of tricks like using a symbol font that maps special symbols to alphabetic characters.
However, even when fonts are correctly encoded, designers should be cautious about using
special characters that are not supported by the fonts built into reading systems: users may
see nothing at all or the dreaded “notdef” character if the reading system, its defaults, or
user preference settings cause the built-in fonts to be used instead of the embedded fonts.
Some designers choose to embed a subset font containing glyphs for "unusual" code points
if they are not expected to be in an RS' default font set. While this causes special characters
16| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
to be displayed in a different font, it does ensure the correct characters are displayed at all.
Special characters or symbols can always be inserted as graphics for print. Although this
works in e-books, designers should avoid this if possible because it can cause problems: the
graphic may scale or be resized differently than the text or get blurry when zoomed, and
text flow around the graphic may look unnatural or cause the apparent location to change.
Fonts with extended Adobe Latin character sets plus Greek and Cyrillic, such as Minion Pro
and Arno Pro, work well for most projects with foreign characters, and many such fonts are
available (which ones are good for a project will depend on the languages needed or the
scope of the math involved). Multiple typefaces may be required to meet some language or
symbol needs. In addition, advanced math formatting is not yet widely supported, so some
formulae and expressions may simply require the use of graphics instead of text, in order
for the expressions to be represented accurately across all reading systems.
17| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 3 | EMBEDDING FONTS
Not all devices (actually few devices today) default to using the font specified by the
publisher, even if it is embedded. Nook, for example, has publisher default settings “off”
by default. Unfortunately, if the e-book does not render with the embedded font, and the e-
book also either requires special characters, uses unusual glyphs for common characters,
or falls back to a poor second choice on a given device, it may become messy.
Currently most EULAs require that fonts embedded in e-books be obfuscated and subset.
Many publishers hire vendors to obfuscate fonts in fixed-format e-books. In the event that a
distributor needs to remove font obfuscation from an e-book, we recommend that the
publisher check the EULA to see if it is permitted, and if not, put the distributor and font
foundry in contact so that they can work out a mutually acceptable solution. See more on
obfuscation and subsetting in Chapter 7.
A Font Rule
While the primary use of a CSS stylesheet file in an e-book is to define the classes of
structures throughout the book, there are also declarative rules that are a preface to these
classes. One kind of rule specifically identifies special font faces that live in the CSS
stylesheet and are to be utilized in the classes: the @font-face rule. Instances of the rule can
be used to define how a font will later be accessed in class sets or directly as style in the
text nodes. Rules are 1:1 for each font face to be used in your book. The rule can define any
of the following elements:
1. A web-hosted font (requiring a reading system that supports it and a dedicated
18| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Internet connection);
2. A system font (requiring access to system resources on the reading system or
device, as with Apple iOS devices listed at http://iosfonts.com);
3. An embedded font (living inside the e-book file structure that is being published, as
you would find in a PDF or EPUB).
Of the three types, embedded fonts are often the most reliable option for e-books. Here’s
why.
First, because web-hosted fonts do not require font files to be licensed and packaged with
the content, but instead use services like Google Fonts (http://www.google.com/fonts/) to
reference fonts stored elsewhere, they provide a lightweight option for web-based content.
However, designers should use caution when using web-hosted fonts for e-books, as they
are not supported in EPUB 3 (see IDPF documentation) and will cause errors in most
reading systems, which do not follow links to web-based fonts. For this reason, using web-
hosted fonts in EPUB e-books is not recommended.
Relying on system fonts is also problematic, given that the system fonts stored on different
reading systems and devices vary, which means that while a book might look fine on one
device, it will be rendered incorrectly on another. In addition, reading systems may add or
remove system fonts over time. This is particularly troublesome for fixed-layout content,
which requires text to fit into the designer’s designated space on the page. Embedding fonts
is almost always the best option for fixed-layout content.
@font-face
The @font-face rule is a rule declared in the stylesheet (a CSS file) of an e-book, or a
website, that is able to uniquely identify a remote or local font file for use in the expression
of type. The @font-face rule can be repeated to declare each font face that is used in an e-
book, including fonts that are embedded (in the local file system of the e-book), system-
issued (delegated by the software), or accessed online as a web font (assuming an Internet
19| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
connection is available to cache fonts at the load of each content document). The rule
allows published content to have fonts that are beyond the stock that is provisioned by the
software or platform when “playing” the book.
To use the rule, declare the font in the html <head> element or a companion CSS file (if
you are using a companion stylesheet, the CSS file location must be declared in the page
head), like so:
@font-face {
font-family:Futura;
src:url("../font/FuturaStd-Book.otf");
}
Then, you are ready to utilize the font specification in any of your style declarations, such
as in this example:
h1.exh {
page-break-before: always;
color: #003a63;
font-family: "Futura", sans-serif;
font-size: 1.75em;
font-style: normal;
font-variant: normal;
font-weight: normal;
}
Adherence to the style specifications, which are regularly updated as part of web standards
by the W3C, can be varied on different software platforms. Many devices are at least two
years behind the latest capabilities on the web. Some devices will ignore @font-face use,
because from a development perspective it is a headache to maintain support, or they just
have not gotten around to it.
20| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
In the @font-face rule, a font file is referenced with an absolute or relative path, and
semicolons separate declarative selectors for the stylesheet to be able to reference. See
more details and an illustrated example in Chapter 3: Embedding Fonts.
The style for the paragraph or the character set needs to tumble down to a thin
specification, should the primary font specification not be supported or be otherwise
disabled. A selector class specification could be {font-family: "Futura",
Courier, sans-serif;} where the fallbacks are built inline with the embedded
system, and slave specifications are drawn out.
21| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 4 | STYLING & FORMATTING
Should you have a font you want to use (see Chapter 2: Selecting Fonts), and you are
authoring an e-book built on formal HTML coding such as KF8 or EPUB, stylesheets will
bring an enormous amount of control to the presentation of your book content. They are
also necessary if a designer wishes to embed preferred fonts. Centralizing a stylesheet as a
standalone *.css file, referenced in the book’s HTML documents, will reduce maintenance
and guarantee accuracy.
1. CSS file classes are subject to overrides inline. Styles of a class inherit attributes
from their definition in the CSS file, but will be silenced by a style attribute that is
applied inside of the para, div, table, or span node with HTML. In typesetting, one
would associate this with the concept of local overrides, where attributes inherit
(from a style) or override (from a variant).
2. Nodes (paragraphs, words, phrases, table cells) that use CSS classes can have
combined classes, applying a mixed presentation to a single object. An example
would be <p class="s5 c12">Duck, duck, goose</p> where the s5 class is
amended by a c12 character style.
3. A CSS file update will at once change the attributes of a class used in all HTML files
that reference it unless specific overrides are defined.
4. A book that is made for many distribution channels may cascade with substitutional
attributes; if the embedded font is not able to render in two of the fifteen channels,
then find the system-issued sans-serif font, for instance. These fallback values are, in
a declaration, comma-separated like {font-family: "Futura", sans-
serif}.
22| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
As a dedicated file, the CSS file’s path is expressed in each HTML file’s head. To find out
more, visit the W3C here: http://www.w3.org/Style/CSS/Overview.en.html, as the
remainder of this chapter will specifically address a discipline built on its comprehension.
h1.exh {
page-break-before: always;
color: #003a63;
font-family: "Futura", sans-serif;
font-size: 1.75em;
font-style: italic;
font-variant: normal;
font-weight: bold;
}
2. If the style is to be applied to a single word within a <para>, <div>, table, heading,
or other element, you can either apply a character style using the method described
above, or insert the styling inline in the HTML document.
There are additional guidelines for the use of bold and italics in e-books, when the styling is
intended to carry a purpose beyond presentational, such as for semantic emphasis, or
when using bold text to communicate the importance of a word. Following these EPUB 3
Accessibility Guidelines will ensure your e-books are accessible to all audiences, including
non-visual users.
23| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Referencing Non-Latin Characters in E-books
The EPUB and KF8 formats both support Unicode, and it is a best practice to use UTF-8 or
UTF-16 encoding on your e-book files. When adding non-Latin characters to e-book files,
you have a few options.
1. Insert the characters in bare Unicode text (like “é”), and ensure that the HTML or
other files are saved with a UTF-8 or UTF-16 file encoding. This is usually the best
option, as Unicode text is much more readable, which is helpful for quality-
assurance purposes.
2. Insert the characters using HTML entities.
HTML entities are supported natively in all reading systems and allow for the insertion of
the breadth of characters and character variants found in the Unicode character set. These
entities come in one of three types: named, decimal, or hexadecimal.
The use of named entities in e-books is not recommended; named entities are not
supported by the EPUB 3 specification and are often flagged by reading systems as an
“external entity” or undefined, making the entire page they occupy render incorrectly.
Decimal and hexadecimal entities are usually supported without any issues, and
hexadecimal entities are recommended for the broadest compatibility. It is important to
note that inserting the correct character or entity does not guarantee that the character will
display in the reading system. You may still need to embed fonts that support the
characters you are using.
For example, if you wanted to include some Spanish text in your e-book file, you might code
it like this:
24| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
de relleno estándar de las industrias desde el año
1500, cuando un impresor (N. del T. persona que se dedica a la
imprenta) desconocido usó una galería de textos y
los mezcló de tal manera que logró hacer un libro
de textos especimen.</p>
Note the use of hexadecimal entities in the code. These example characters are common
and would not necessarily require that a font be embedded to ensure proper display, but it
would be important to test the file on the target devices to be sure.
For more information on Unicode characters, see the Unicode character charts:
http://www.unicode.org/charts/.
Fractions
Using <span> tags along with CSS is a great way to include case fractions in e-books. The
following code usually creates fractions that look good across devices, but it may need to be
adjusted depending on the line-height set in the CSS:
HTML:
<span class="fractop">1</span>/<span class="fracbtm">2</span>
CSS:
span.fractop {
font-size: 0.6em;
vertical-align: 0.5em;
line-height: 0;
}
span.fracbtm {
font-size: 0.6em;
vertical-align: -0.1em;
line-height: 0;
}
Professional typographers will cringe at scaling regular numbers to create fractions, as this
results in thinner and less legible fraction numerators and denominators than real
designed fractions. Modern OpenType fonts can have support for completely arbitrary real
25| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
fractions (not just ¼, ½, and ¾, but even 31/427) built in. Unfortunately, using “real”
fractions beyond perhaps the basic three is not an option until either (1) all reading
systems support embedded fonts and these always override reading system fonts (unlikely
and undesirable) or (2) all the reading system fonts support arbitrary “real” fractions
(unlikely to happen anytime soon).
26| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 5 | QUALITY ASSURANCE TESTING
As with all e-book development, quality assurance (QA) testing is a critical part of the
design process for e-books that have embedded fonts. While e-book specifications typically
define what reading systems are supposed to do with properly coded content, reading
system support is, unfortunately, not always consistent.
When a book is opened on a device, the device as a reading system has been designed to be
an interpreter of the file format specification. The specification is used to recognize the file
by its extension (like *.EPUB) and then by the structure inside the content documents of the
book. Part of the device software is a font-rendering engine, which should be able to
display most of the fonts that are strictly designed as modern OpenType (see Chapter 1’s
overview of font formats). The specifications that affect most e-books are CSS, HTML,
JavaScript, Typography, and the compiled EPUB. This is important because it is through
interpretation of the specifications that you build the user experience of reading the book.
Some devices can’t do what you need yet. Some devices are no longer supported, which
means no feature updates. There are other devices from manufacturers or developers that
are designed to ignore these features in favor of conformity in the user experience.
Recommendations
In the list below you will find suggestions and tips on performing QA testing on your e-
book files. Note that these suggestions relate only to the use of fonts. It is recommended that
you also perform other QA testing on your files for design, code quality, accessibility, etc.
• When testing your e-book files, it is best to load them into actual reading systems (e-
27| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
book devices and apps). There are reading system emulators available for certain
devices, but fonts will sometimes be handled differently in those emulators than
they are on the devices themselves.
• You should ideally test e-book files on each reading system that you are targeting.
This gives you visibility into potential issues and will allow you to fix problems
before users catch them. While iBooks and Adobe Digital Editions may be easy to
use, each reading system handles fonts in a different way, and you are likely to miss
something when testing in only one or two reading systems. It is a best practice to
test your e-book files in all the reading systems you are targeting for sales.
• Issues often appear in specific combinations of operating systems and reading
systems. For example, the display of EPUB files in the iBooks reading system is
impacted by the version of iOS installed on the device. Older iPads without the latest
version of iOS can have significant differences from devices with the latest version.
It is recommended that you try to test in older devices when possible, but
sometimes that can become a rabbit hole very quickly.
• E-books often use font obfuscation to protect fonts from piracy. When testing fonts,
be sure to test them with obfuscation enabled if that is how you plan to sell the file.
Reading systems may or may not support standard obfuscation techniques. If errors
are found, the font could be incorrectly obfuscated. It is important that the key(s)
used to obfuscate the embedded font(s) use unique publication identification
numbers for each e-book they are used in. Errors occur when obfuscated fonts are
copied into new e-books without assigning a new unique ID.
• It is best to test the e-book file both with your embedded fonts turned on and with
them turned off. This is usually done with a “publisher defaults” or similar option in
the reading system’s preferences. Some reading systems deactivate publisher fonts
and styling by default, which can cause the readability of your book to suffer. In
some cases it is a good practice to include an instructions page encouraging users to
activate the publisher settings, but remember that many users will choose to not do
that for various reasons.
• When testing an e-book with special characters or foreign languages, be sure to
28| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
specifically test those without the publisher defaults activated. Some reading
systems may not include fonts that are able to handle these characters, so it is
important to know that before making the files available for sale.
• If you have an e-book with widely dispersed special characters, it might be helpful to
create a test version of your e-book with all of those characters in one section for
easier viewing.
• It is a best practice to include fallbacks in your CSS font declarations. In addition to
generic font types (serif, sans-serif, etc.) these fallbacks can include calls to system
fonts on your target devices. While these system fonts may change periodically,
including them in your fallbacks list may allow better readability on some devices.
• Note that Amazon’s Kindle format has its own standards that may not match with
the EPUB standard set by the IDPF in all respects. Find Kindle Publishing Guidelines
at http://amazon.com/kindlepublishing when producing Kindle-formatted files.
• Another helpful resource is the BISG EPUB 3 Support Grid, which reports EPUB 3
conformance across a variety of reading systems, devices, and platforms, using a set
of systematically designed evaluation files at EPUBTest.org.
29| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 6 | LICENSING & RISK FACTORS
When you begin to research a font, always start by locating and reading through the EULA
(end-user license agreement) on the foundry’s website. Look for links to “Licensing” or, if
you’re visiting a larger vendor site, search for the specific font and look for a link to the
license terms there. Contact the foundry if you cannot locate the EULA.
Note that you are generally bound by the EULA in force at the time you license a font, not
just whatever the foundry currently has posted. This is a very good reason to save a copy of
the EULA when you license a font—and ideally to associate it with the font in some fashion.
Read through the EULA, paying special attention to sections on embedding. The embedding
sections often permit embedding for material cycling internally during content creation but
restrict embedding for commercially available products. Sometimes licensing questions are
addressed in an FAQ section, so look through this link for licensing clarification.
30| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
• Do you have unlimited commercial use, or are there limitations?
• Can you modify the font software and change the glyphs? Typically, the answer to
this is no, but you may be able to turn the glyph into art and modify that before
embedding it into an EPUB.
• Must you “subset” and/or “obfuscate” the font in an EPUB?
• Can you share the font with a subcontractor (such as a freelancer) or a service
bureau or printer? Usually not. You may need to purchase an extended license. Some
are easy to acquire and will allow unlimited uses for an unspecified number of
projects. Others require you to purchase a one-time usage fee or a subscription
model in which you track the usage of the font on a yearly basis and pay accordingly.
Sticking to fonts with more extensive rights is the easiest and safest route. If you still
have questions or concerns, contact the foundry.
Many licenses allow the font software to be installed on up to five workstations. Purchasing
for additional workstations and locations requires a multiuser license—some sites feature
options that allow you to select and view the pricing for the purchase of additional licenses.
See the EULA or contact the foundry for the specific type of extended licenses required to
cover more workstations or users.
Once an embedding license has been located, be aware of further restrictions regarding
how the font should be embedded. Most foundries require the font to be embedded as a
subset—meaning that only the characters used in the document are included when
embedded. Some foundries require digital rights management (DRM) to be applied to the
31| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
e-book. Others require font obfuscation, by which a part of the font software is scrambled
so it cannot be easily installed on a computer if the font is extracted from your document
(see Chapter 7: Font Protection). Some foundries allow their fonts to be embedded in
editable PDFs, while others allow embedding only in PDFs that are set to preview and print.
Adobe, for instance, outlines the types of embedding granted for each font family in their
Adobe Font Folio collection on their website: http://www.adobe.com/products/type/font-
licensing/additional-license-rights.html.
Some licenses also allow modifications to the font software. Follow the rules set out in the
license agreement. If renaming the font or converting the font format is allowed with
modifications—even if the font foundry converts the font format for you for a fee—be
aware that you can no longer use the original font unless you purchase additional
workstation licenses; in essence, you now have two fonts, and the original license covers
only one. Converting font formats is often not permitted, so OpenType is the preferred
format to purchase (see Chapter 2: Selecting Fonts).
Never use a font that you cannot locate a license for. Many fonts found on websites claiming
to offer “free” fonts are actually pirated copies of commercially available fonts or have
restrictions on commercial usage. Legitimate open source (“libre”) fonts will always
include a license with the font download.
Failure to follow the license agreement could result in legal action by the font foundry. Font
foundries suing companies for alleged unlicensed or under-licensed use of fonts has
become increasingly common; there have been several high-profile lawsuits in the past five
years. As their EULA terms and legal actions make clear, many foundries and distributors
regard fonts embedded in e-books as both a revenue opportunity and a piracy risk, so they
take it quite seriously.
Free Fonts
Many websites offer “freeware” fonts. However, not all fonts that are listed online as
32| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
“freeware” are actually free. Some are actually illegal copies of fonts that can (and should)
be legally obtained elsewhere for a licensing fee. Many are free only for non-commercial
use. It is important that you use only fonts that have clearly defined licenses, and that those
licenses support the use you need.
If you are looking for free fonts, it is best to look for open source fonts. There are different
kinds of open source fonts, but many are licensed with the SIL Open Font License
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL), while others may use
the GNU Public License (http://www.gnu.org/licenses/gpl.html), the Apache 2.0
(http://www.apache.org/licenses/LICENSE-2.0.html) license, or another open source
license. These licenses allow the font to be embedded within your e-book files without
requiring special fees or permissions, and also allow the font files to be subset, obfuscated,
and otherwise adjusted as needed (but be warned that fonts using the SIL OFL may use its
optional “Reserved Font Name” mechanism, which requires you change the font name if
subsetting or obfuscating the font). It is important to follow the license terms when making
changes to these fonts, but typically the only requirement is that you include a reference or
link to the license from your e-book.
The most commonly used directory of open source fonts is the Google Fonts directory
(http://google.com/fonts). All of the fonts in that directory have open source licenses, and
they can all be included in your e-book files without a licensing fee.
When unavoidable, if you must use a font that does not have a clear license posted and is
available only on free font websites—not available for purchase at any of the commercial
font foundries—contact the font designer/creator of the font to ask for permission to use
the font in your e-book (this will often be granted with an associated fee). Keep a copy of a
receipt for payment and the licensing agreement or correspondence with the font creator
granting you permission to use the font in your publication.
33| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Font Management
“Font management” could refer to any scheme used to keep track of fonts, but in publishing
it usually means the use of specialized software to do so. Most serious font management
software allows inclusion and tracking of license information with one’s fonts. This is in
addition to the basic font management functions: activating and de-activating fonts
individually or in sets, auto-activation of fonts needed for specific documents, and
previewing and comparing fonts, whether currently active or not.
Font management software comes in two flavors: single-user products, such as Suitcase
Fusion, FontAgent Pro, and FontExplorer X, where each user has a completely independent
font collection and there is no centralized tracking or control; and client-server products,
such as Universal Type Server, FontExplorer Server, and FontAgent Pro Server, which allow
for centralized tracking and control over which users (and how many) access which fonts,
including grouping fonts based on access rights and allowing users access to specific font
grouping(s).
34| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 7 | FONT PROTECTION
The most common use of the acronym “DRM” (digital rights management)in the publishing
space is perhaps in relation to access to a digital book. However, DRM can also apply to
fonts.
Intellectual Property
One area is the source of much confusion: intellectual property (IP) protections for fonts. If
you don’t read this whole section, try just treating fonts the same way you would software,
in the sense that fonts are subject to similar protections—which immediately suggests why
there are issues with distributing fonts embedded in e-books.
Broadly speaking, there are several forms of legal protections that can apply to fonts:
contract, trademark, copyright, and design protections (US design patents, EU industrial
design rights).
Contract law applies because the End User License Agreement (EULA) is a contract, just
like a license to use any other kind of software or copyrighted material. This is discussed at
greater length in Chapter 6: Licensing & Risk Factors.
Trademarking for fonts has generally been applied just to the name of the font.
Trademarking addresses the issue of font creators potentially using the name of an already
existing/trademarked font, and is not typically something e-book creators need to worry
about. Although lawsuits for unlicensed font use sometimes include trademark claims, they
are not generally seen as the core issue.
35| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Design protections for fonts are based on the idea that the abstract design of a typeface can
be protected, even aside from the details of how that design is instantiated in a specific
font.
In the United States, there is no inherent protection of the abstract design of a typeface
based simply on creating it. However, there is the notion of a design patent: a legal
protection for the ornamental design of a functional item. US design patents require
registration and payment, and are valid for 14 years from the date of issue. The very first
US design patent, issued in 1842, was for a (metal) font. Because of the expense and
relatively short lifespan of the patent, few type designers and foundries protect their fonts
with US design patents (with the notable exception of Adobe, for their original typefaces).
See also http://en.wikipedia.org/wiki/Design_patent.
In Europe, and many non-European countries, there are notions of industrial design rights
that are applied to typefaces/fonts. These design rights are protected under some national
systems of design registration, as well as under a European-Community–wide system. The
latter system features protection for up to 25 years for registered designs (requiring fees
every five years) and protection for three years for unregistered designs. Note, however,
that some national laws offer additional or greater protections, including additional
protections for unregistered designs.
Copyright can apply to fonts in more than one way. In the United States, copyright does not
apply to the abstract design (the typeface), but does apply to the design once it is
instantiated in a digital outline font file, such as the font formats used in e-books today. The
US Copyright and Trademark Office treats such fonts similarly to software, and accepts
registrations for font copyrights in much the same way. This does not apply to bitmap-only
fonts, but they are little used today.
It appears that at least some other countries (though by no means all) are following the
same principle of treating computer font files like software. But in at least some countries,
36| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
copyright may also apply to the abstract design of a typeface, just as it does to other
creative works.
37| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
software piracy, as font files are software and are the intellectual property of the font
foundry (development firm) that artfully designed the characters we see on the page. The
high-level goal of book file authoring, for publishers, is a one-size-fits-all model. If
successful, a publisher distributing an EPUB e-book file would be able to distribute the
book file across all distribution channels. That is achieved through unified specification
across channels, a critical element in scaling production methodologies.
Impeding unification is DRM, which often varies across channels. There are encryptions
and ciphers available to protect authors’ content and publishers’ designs from piracy.
Publishers are often interested in protecting digital content, because it is intrinsically
easier to steal than print formats, requiring a simple copy and paste. DRM is typically added
by e-book distribution channels to protect the content, but this does not protect the fonts
embedded in the e-book file. A separate effort needs to be made to prevent the copyright-
protected font files that are embedded in e-books from being extracted and used without a
license.
Font obfuscation allows publishers to deliver e-book files to channels with a universal
method of rendering the font files themselves that is unusable by those who would pry.
While a publisher depends on the DRM to protect files, a publisher needs to build
confidence with font foundries to keep that third-party intellectual property from piracy.
A collection of distribution channels, an area in which O’Reilly Media is a huge leader, have
elected to wave DRM use, distributing their content freely as a way of building confidence
with the e-book user. This method depends on the fact that users will happily pay for
content that they have decided is valuable. This trend of vulnerability, which this
publication strongly supports, depends heavily on font obfuscation, which allows the
reading system (the device software) to render the book correctly, but keeps the font files
from being usable by someone who tries to use them outside of the book file itself.
38| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Subsetting Fonts
In addition to obfuscating fonts, font foundry EULAs usually require subsetting fonts in
EPUBs. This means that you include only the glyphs (characters) that are used in the
publication and throw away the rest. For example, if you use a capital “Z” in the book, but
not a lowercase “z”, then the lowercased “z” is discarded during embedding of the font.
Subsetting fonts decreases the value of stealing a font because the font is incomplete—it
does not contain all the characters (alphabetic and numeric)—and keeps you compliant
with the font EULA. As an added bonus, subsetting fonts reduces your file size significantly.
Fonts with a robust character set of a couple of thousand characters in an EPUB can bloat
your file (increase file size)—unnecessarily if most of the characters are not actually used
in the EPUB. Files that are too large will increase e-book download time and can slow down
file performance in reading systems.
If you are using another method to produce EPUB files, your subsetting options are limited.
FontSquirrel.com offers a tool to facilitate subsetting fonts: @font-face Webfont Generator,
found on the FontSquirrel.com site, features an “expert” mode that offers several options
related to subsetting fonts, including choosing specific font characters to appear in your
EPUB. This tool has its limitations: it’s slow and can process files of only a limited size..
Better tools for subsetting fonts would provide more viable options for maintaining
compliance with font EULAs.
39| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Chapter 8 | INDUSTRY STANDARDS
IDPF (International Digital Publishing Forum) creates and maintains industry standards for
EPUB e-book production. Visit http://idpf.org for up-to-date standards to follow. In
addition, some retailers have specific standards for creating e-books that take advantage of
fonts or features specific to their devices and platforms. However, as the need for
interoperability across reading systems grows, increased standardization of these features
is essential.
BISG recommends publishers and e-book developers keep abreast of updates to the EPUB
standard and its associated profiles. Publishers are encouraged to create an in-house e-
book style guide and keep it current.
In addition to standards for e-books, there are standards for font formats. The OpenType
standard is available from Microsoft, and OpenType 1.6 is identical to the corresponding
ISO Open Font Format standard. (See https://www.microsoft.com/typography/otspec/).
40| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Appendix A | DEFINITIONS
absolute path—The exact location of one file or folder, from the root of the file system to the
object itself.
DRM—Digital Rights Management. DRM is wrapped around font files to control access to
those files.
filename extension—A suffix (separated from the base filename by a dot or space, such as
.jpg) to the name of a computer file applied to indicate the encoding (file format) of its
contents or usage. http://en.wikipedia.org/wiki/Filename_extension
41| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
of e-book content across reading systems globally.
EPUBCheck/ EPUB Validator—A tool that validates EPUB format e-book files against the
EPUB specification and logs any violations of the spec, used as a report to e-book
developers to identify structural or content variances. EPUBCheck and associated
documentation are available at https://github.com/idpf/epubcheck. Small files can be
checked online at http://validator.idpf.org.
EULA—The end-user license agreement that serves as the contract for the use terms of
licensed font files.
file system—The complete structure in which content files are located, and where content
files can draw references to other files located, often defined through folder and file names.
font rendering—Associating a font file with content, then accurately expressing the
characters of text with the corresponding type characters in the font file.
foundry (type)—A company that designs or distributes typefaces. Originally, type foundries
manufactured and sold metal and wood typefaces, then later matrices to create type on
line-casting machines like the Linotype and Monotype machines, all to print on letterpress
printers. Today’s digital type foundries create and distribute typefaces (typically as
digitized fonts) created by type designers, who may be employees, freelancers operating
their own independent foundry, or workers employed by another foundry. Type foundries
may also provide custom type-design services.
42| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
International Digital Publishing Forum (IDPF)—The organization that maintains the industry-
standard EPUB specification for e-books, and related profiles and documentation. Website:
http://idpf.org/
inline—In a stacked structure, elements that occur where the content is, or at the event, in
an electronic document or e-book are inline.
intellectual property—A legal concept that refers to creations of the mind for which
exclusive rights are recognized. Under intellectual property (IP) law, owners are granted
certain exclusive rights to a variety of intangible assets, such as musical, literary, and
artistic works; discoveries and inventions; and words, phrases, symbols, and designs.
Common types of intellectual property rights include copyright, trademarks, patents,
industrial design rights, trade dress, and, in some jurisdictions, trade secrets.
http://en.wikipedia.org/wiki/Intellectual_property
JavaScript—The client-side event language that is able to add causality and interoperability
to composed pages in an e-book. Server-side massaging of XML with JavaScript would be
termed AJAX.
ligature—Occurs where two or more graphemes or letters are joined as a single glyph.
Ligatures replace consecutive glyphs. http://en.wikipedia.org/wiki/Typographic_ligature
manifest (1)—In an EPUB, there is an element within the *.opf packaging file that is a list of
all assets in the EPUB. It establishes unique IDs for each asset, and states the executable
kind for each file. Properties can be established for each asset governing extended uses,
too, which could be “this file can access the Internet” or “this file can run a javascript”. The
assets are usually drawn with a relative path from the root of the content folder, or
wherever the file (the manifest file is within the *.opf file) is located.
43| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
manifest (2)—In HTML5, the manifest, or appcache, would be a namespace that can run
locally inside the book file that allows content to be cached. So, if you are to get content
from a remote resource (the Internet) at the time of a page load, the content will now be
local as a temporary resource until the reading system is quit out, for instance. Support of
this feature is primarily limited at the time of this publication.
MOBI—HTML-based book file format that is primarily used, and exclusively maintained,
for Amazon’s Kindle platform. Currently, a MOBI file contains a KF8.
obfuscation—Any scheme that scrambles or renders a file unusable by some simple and
easily reversible method for which the reversal is well known and not complicated. In e-
books obfuscation often refers to the offsetting of several code characters, often eight
characters at the beginning of a file, that renders a file unable to launch.
open source fonts (“libre” fonts)—Licensed fonts allow users to embed fonts within e-book
files without requiring special fees or permissions, and also allow the files to be subset,
obfuscated, and modified as needed. It is important to follow the license terms when
making changes to these fonts, but typically the only requirement is that you include or link
back to the license from your e-book. For examples of open source fonts see the
SIL Open Font License (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL),
GNU Public License (http://www.gnu.org/licenses/gpl.html), Apache 2.0
(http://www.apache.org/licenses/LICENSE-2.0.html), and Google Fonts Directory
44| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
(http://google.com/fonts).
reading device—The physical platform (hardware and software) on which publications are
rendered. http://idpf.org/forum/topic-553
relative path—The location of one file or folder, relative to the present location of a file or a
user.
RSS—Really simple syndication is a web feed specification (like JSON and POX) used to
publish frequently updated works—such as blog entries, news headlines, audio, and
video—in a standardized format. An RSS document (which is called a "feed", "web feed", or
"channel") includes full or summarized text, plus metadata such as publishing dates and
authorship. http://en.wikipedia.org/wiki/RSS
type styles
sans serif—A letter or typeface that does not contain serifs, such as Arial or
Helvetica.
serif—One of the short lines that finish off the main strokes, generally at the top
and/or bottom of a letter or typeface; or a typeface with serifs, such as Times,
45| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Georgia, or PMN Caecilia.
square or slab serif—A kind of serif letter or typeface that has flat, block-like serifs,
such as PMN Caecilia or Amasis.
sideload—A term used in Internet culture, similar to “upload” and “download,” but in
reference to the process of transferring data between two local devices, in particular
between a computer and a mobile device such as a mobile phone, smartphone, PDA, tablet,
portable media player or reading system. http://en.wikipedia.org/wiki/Sideloading
web font—A font hosted online that a commercial user (publisher) of the font is not
responsible for licensing. Since the font, in this case, is not distributed by the publisher, this
use avoids embedded licensing. Due to the broad assumptions that come with having an
Internet connection while reading, using web fonts is primarily waved by publishers as it is
considered impractical.
46| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
Appendix B | RESOURCES
CSS Fonts
http://www.w3schools.com/css/css_font.asp
Daisy Consortium
http://www.daisy.org/
Design patents
47| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
http://en.wikipedia.org/wiki/Design_patent
EPUBSecrets
http://EPUBsecrets.com
@font-face generator
http://everythingfonts.com/font-face
Font obfuscation
www.idpf.org/epub/30/spec/epub30-ocf.html#font-obfuscation
Identifont
http://www.identifont.com/
48| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
IDPF (International Digital Publishing Forum)
http://idpf.org/EPUB/30
Kobo Guidelines
http://download.kobobooks.com/learnmore/writinglife/KWL-Content-Conversion-
Guidelines.pdf
OpenType Specification
https://www.microsoft.com/typography/otspec/
49| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2
SIL OPEN FONT LICENSE
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL
Training Resources
lynda.com
http://lynda.com
50| Field Guide to Fonts for E-books © 2014, the Book Industry Study Group, Inc. | 978-1-936757-31-2