I'd expect that many foundry licenses provide a definition of "document embedding" that would be broad enough to cover ePub. What might catch you out is the "commercial product" clause in licenses that would prohibit the ePub document being charged for.

Embedding friendly licenses include Adobe, FontShop, and er Microsoft :-) these may be worth reviewing.

Well, a DRM free epub is nothing more than a renamed zip archive containing, amongst other things, the full font files. Is that sufficent? Would free epubs ship with DRM?

Good point, you could certainly be caught out by EULAs that require "secure embedding" (although in my opinion there's really no such thing) or that define document embedding as only being PDF. At the end of the day I'd be inclined to review EULAs and confirm your findings with foundries that appear to allow this form of embedding.

Also worth noting that EPub v3 will support WOFF as well as plain TTF/OTF. WOFF in ePub provides the same level of protection as you would with WOFF on the web.

Cheers, Si

I was hoping some foundries would chime in, as most of them are active on Typophile.

On Epub3: Yes, I'm excited about that, but can't seem to find any information on how soon we can expect cross-platform support.

>I was hoping some foundries would chime in, as most of them are active on Typophile.

The foundries who know about ePub likely already charge for those rights. The others are probably researching right now. :-)

Since e-pub makes use of Web standards such as XHTML and CSS, interest has been expressed in using WOFF in this context. Note that as with Web served typography, ePubs are not 'embedding' fonts in documents: the fonts reside alongside the document and is linked.

>Since e-pub makes use of Web standards such as XHTML and CSS, interest has been expressed in using WOFF in this context.

WOFF (and OpenType) support seems to be a requirement of the current epub 3 spec. My understanding is that it’s a done deal?

>Note that as with Web served typography, ePubs are not 'embedding' fonts in documents: the fonts reside alongside the document and is linked.

Depends how you define the document. If the document is the renamed .zip then the fonts are embedded within it.

From the current draft of the spec...

› 5.2. CSS Fonts Level 3

EPUB Style Sheets may include all of the constructs defined in the CSS Fonts Module Level 3 ( [CSS3Fonts] ) specification. User Agents must support at least the following values for the src descriptor in @font-face rules: "woff", "opentype" . I.e. both WOFF and' OpenType are Core Media Types that must be supported by all Reading Systems. Reading Systems may optionally support SVG Fonts in CSS.

http://code.google.com/p/epub-revision/downloads/detail?name=ebup30-2010...

Thanks, Si. I wasn't sure of the status of the ePub plans re. WOFF; Vlad was talking with them and I couldn't remember whether a decision had been reached yet.

Depends how you define the document. If the document is the renamed .zip then the fonts are embedded within it.

I suppose that is one way of looking at it, but this text is from the introduction to the openbook.org documentation of their recommended font obfuscation mechanism:

‘Many commercial fonts allow embedding, but embedding a font implies making it an integral part of the publication, not providing the original font file along with the content.’

I think this notion of integral vs. accompanying the content is one that will fit with many peoples' notion of embedding.

For sure. If the inventors of the file format/package do not believe it qualifies as a document file then it would be hard to argue that document embedding permissions (either written into the EULA or encoded in the embedding bits) could apply.

>... If the inventors of the file format/package do not believe it qualifies as a document file then it would be hard to argue that document embedding permissions (either written into the EULA...

Naturally. How could any working group do such a horrible thing as using embedding bits. And How could anyone argue that an e book is a document, sillies. I see that the "garden fence" has been mentally upgraded to a "stumbling block". Must be dark in there.

Do any of the popular e-book readers actually implement any “embedded” fonts?

It’s been about a year since I did any testing. At that time, the only reader that I could find that supported document-specified “embedded” fonts was the Adobe Digital Editions reader for the desktop.

None of the ebook-reader apps for the iDevices will recognize epub-attached fonts. (Heck, mobile Safari doesn’t even recognize @font-face except SVG.)

As far as I know, none of the proprietary devices (Nook, Kindle, et al.) will present anything other than their own device fonts. But maybe things have evolved with the latest versions?

It would be interesting to know if any e-readers have plans to support Epub document-specified/attached fonts in the near future.

I'm embedding fonts in an ePub for iBooks on iPhone/iPad at this very moment.

eMbedding. Sorry:)

OT files that is.

If we are going to treat apps and e-books as OEM's, we're missing out on a huge market.

mobile Safari doesn’t even recognize @font-face except SVG

It does now:
http://webfonts.info/wiki/index.php?title=%40font-face_browser_support

I'm embedding fonts in an ePub for iBooks on iPhone/iPad at this very moment.

The embedding part is easy, the question is will iBooks display the fonts?

This page is pretty straightforward about it:

Can I install and use custom fonts?

No, not at this time.

@frode

I'm working on a post about E-pub, which, IMHO, is useless, stupid, and counter-productive. And the licensing issues you're talking about are icing on the cake.
I'm curious - why format with E-Pub? Browsers are ubiquitous - why not just go with HTML5?

Rich

why format with E-Pub? […] why not just go with HTML?

I’ve always wondered the same.

I'm testing them on iPad, iPhone, Kindle, ADE and Sony E-reader (etc.), so I know it works Jens. So far, Kindle is the only one that defaults to device fonts.

Why .epub? The format is really cumbersome, but authors demand DRM and editors follow the trends in publishing. A HTML book can't be, DRM'd, sold via the usual channels or read offline unless it's packed in an app - or can it? Even so, the font licensing issue* is still the same.

Frode, are you using any hacks or tricks to make the fonts work in iBooks on the iPhone? I have tried without success. I'd be grateful for any hints.

>I'm working on a post about E-pub, which, IMHO, is useless, stupid, and counter-productive.

Unlike your other posts? :-)

Jens: iBooks overrides all the commonly used tags. Try for example a cite inside your p’s, and make sure you reset any default styling it adds.

I don’t know if I’m the only one thinking in these directions, but websites, apps and e-books are the layman’s publishing platforms much more so than the professionals. With OEM-ish licensing and stiff prices we’re killing a potential market. The @font-face licenses that differentiate between small scale and big scale users are, IMHO, those that serve customers best while type designers actually earn money. I mean, look at the apps available today. The only ones that can afford professional type are the big league stuff.

@sii

Oooooh, ouch. I begged for that one. We should take this show on the road!

@frode frank
"The only ones that can afford professional type are the big league stuff."

What, precisely, would you suggest? (Seriously.) What price point do you think the bulk of potential customers are willing to pay?

Rich

With OEM-ish licensing and stiff prices we’re killing a potential market…The only ones that can afford professional type are the big league stuff.

I suspect the high price for E-pub embedding is due to the high cost of licensing font for use in iPad magazines apps. Magazine publishers are paying a lot of money to license fonts on a per-app, per-font basis. E-pub embedding licenses at a cost comparable to a web or desktop font licenses might interfere with the iPad app gravy train.

But James, THIS is the issue: The prices are forcing the regular Joe to use free fonts or bitmap images, all the while Fontfeed complains about the lack of @font-face use in iPad magazines.

The prices are forcing the regular Joe to use free fonts or bitmap images…

I guess the regular Joes should start looking for investors.

Or just don’t use fonts that don’t allow electronic document embedding. That seems like a rather good option.

That is so defensive.

richard said:
> E-pub, which, IMHO, is useless, stupid, and counter-productive.

well, what else would you expect from the corporate publishers?
look at the members of i.d.p.f., which created the .epub format.
(i remember their acronym as short for "i design poor formats.")

the e-book revolution is making their business-model extinct,
as that model relies on managing the scarcity of p-books, so
the .epub "standard" is one of their attempts to _stifle_change._

it's worth pointing out that .epub evolved from the o.e.b. format,
also maintained by i.d.p.f., which became the "standard" back at
the end of the 1990s, and the sabotage attempt _did_ work then.

thanks to the kindle, however, which uses another format (.mobi),
.epub's shortcomings won't be able to sideline e-books any more.

which is not to say that the corporate publishers have given up...
to this very day, for instance, they've still neglected to ever create
"reference implementations" for either an .epub authoring-tool or
an .epub viewer-program. this means that other companies have
had to start from scratch to build their viewer-programs, and --
as anyone familiar with such a situation could readily tell you --
the result is a bunch of apps badly inconsistent with the "standard"
_and_ inconsistent with each other in terms of their inconsistencies.

which means the e-book arena is now re-experiencing the awful
nightmare of "browser inconsistencies" that plagued us in the past.

> Browsers are ubiquitous - why not just go with HTML5?

well, first of all, browsers make very bad e-book viewer-programs.

aside from that, html5 would be ok, if you're starting from scratch.
but since i.d.p.f. doesn't really want stuff to work, i'm guessing that
they will choose instead to continue along their present path, and
try to continue to support their legacy format which has served their
(ulterior) motives so fine all along the line. or, to put it another way:

if you like that it's broke, and even broke it on purpose, why fix it?

-bowerbird

by the way, adobe spokesperson, i would love to have you step into this...

i would _love_ it. so please, step right up. i dare you.

-bowerbird

Thanks bb, I know you've kept very much up and been close to all the developments (or non-developments, really) of EPub and I'll be quoting you.

My attitude summed up in this rant on AListApart.

But I'll be fleshing it out a bit on RW. Especially the part about the consistent inconsistencies, like browsers circa 2003.

Rich

richard said:
> Thanks bb, I know you've kept very much up

the only thing i think i should have added is that
microsoft was the big tech partner back in 1998,
whereas it's adobe here in the 2007-on period...

so, of course, before the ink was dry on o.e.b.,
microsoft came out with their format (.lit) which
put the open format in a proprietary wrapper...

the i.d.p.f., which thought that _it_ was the one
who'd been in charge of the thing, realized that
microsoft was now in a position to extract a toll
from all of the i.d.p.f. members who wanted to
use this new format, so the i.d.p.f. flipped out...
they _wanted_ sabotage, but they wanted it to
work in their favor, not _against_ them, and
they realized that they had fallen victim to the
microsoft pattern of embrace/extend/extinguish.

so the corporate publishing houses just shelved
their plans for o.e.b., and electronic-books, which
is what they wanted to do anyway, except that they
had learned to be skeptical of any tech partners...

however, by 2005 or so, these corporate houses
were becoming very afraid of amazon's power...
they needed a counter, and in stepped adobe...

adobe had been disdainful of the o.e.b. effort,
partly because microsoft was so heavily involved,
but also because adobe was always pushing .pdf.

adobe finally realized, though, that a fixed-page
format simply wasn't going to work in a world
where screens came in all different sizes, so
they first tried to modify .pdf so it'd do reflow.
the result was the "tagged" .pdf. if you've never
heard of one, don't feel bad, because they never
really took off. so adobe knew it had to change.

adobe also knew that the corporate publishers
_desperately_ wanted d.r.m., so that path was
the plan of attack that adobe chose to utilize...

of course, the corporate houses were smarter now
and they _expected_ that adobe was going to want
a piece of the pie as well, but they were so afraid
of amazon that they were willing to give it up now.

the thing is, with amazon's d.r.m. attached to it,
.epub ceases to be an "open" standard any more,
because only the reader-programs that have paid
a fee to adobe are allowed to access adobe files...

there are so many ways to kill "an open standard".

> My attitude summed up in this rant on AListApart.
> But I'll be fleshing it out a bit on RW.
> Especially the part about
> the consistent inconsistencies,
> like browsers circa 2003.

it would be nice if the inconsistencies were
consistent. but we're not even _that_ lucky.

here's a woman who has explored the many
ways in which .epub viewer-apps diverge:
> http://www.pigsgourdsandwikis.com/

in recent months, it looks like she's decided
to focus exclusively on the ipad's viewer-app,
and has given up on all of the other ones...

-bowerbird

"it looks like she's decided
to focus exclusively on the ipad's viewer-app"

Yeah, so all the inner city kids with iPads at six hundred bucks a pop can learn to read.
(That's Liz Castro's site - for some reason I've been encountering her name quite a bit over the last month or so.)

Thanks for the play by play.

Any ideas on where Adobe AIR might fit in, if at all?

richard said:
> Thanks for the play by play.

sorry, didn't mean to get it on your shoe.

but that _is_ what vomit do...

> for some reason I've been encountering her name
> quite a bit over the last month or so.

that's probably because she's the only person who was
motivated to explore all of these inconsistencies, and
_her_ motivation was writing a book to explain 'em...

> Any ideas on where Adobe AIR might fit in, if at all?

just like everything else from adobe "fits in" these days:
it's a bad joke.

-bowerbird

oh yeah, i just thought of something else about .epub...

first, this "standard" is being choked by the early versions.

a.d.e. ("adobe digital editions") is the viewer-program
that was adobe's entry into the .epub arena.

it had to run on deficient hardware, i readily acknowledge,
handicapping it badly, but it is still an awful piece of crap...

and i do mean awful, and i do mean crap.

(the good news is that it updates itself automatically...
the bad news is that it seems to update itself constantly.
the ugly news is that, despite updates, it never improves.
i suspect the updates are just to plug the security holes.)

one of the worst things about this early version is that
it can't handle more than 300k of text without choking.

300k is not a lot of text. (the king james bible is 2 megs.)

so people creating .epub files have to chop up their book
into bite-sized morsels so this piece of crap can handle it.
because the old machines cannot update their old version.

so, just like web developers still have to work around ie6,
.epub creators will have to bear this burden for a long time,
even though most e-reader machines have better chips now.
(the market is still too small to be writing off any customers.)

as if this legacy crap wasn't bad enough, the technocrats who
make their living off .epub are already developing a new .epub3.
because, you know, they must perpetuate their making-a-living.

so even though the world doesn't have a decent implementation
of an .epub viewer-program at _this_ time (over a decade after the
format first become adopted by the corporate publishing industry),
we will soon be witness to a whole new crop of "standard features"
which will also be implemented inconsistently. aren't we so lucky?

meanwhile, the world of paper-books is crumbling all around us...

-bowerbird

I have been dealing with this issue, too. We are developing a new platform for digital cookbooks and for us the ability to have well designed pages is critical. I've been talking with various foundries and I've been getting very different messages. So far, we have two foundries which are offering to provide us a package of 6000+ fonts for an annual license of a big over $12,000.

Our approach is to build the pages in HTML5 and use @fontface to integrate the fonts. When someone purchases a cookbook from us they would get the HTML5 files and fonts loaded from our server onto their iPad in a .zip file. So far only Hoefler & Frere-Jones has categorically refused to license for this type of deployment. We happen to have one author who uses their Knockout typeface. So, we need to find a suitable substitute. That isn't great news. If we were to embed the font in the app itself, then they would allow that for an $800 annual fee.

We need a solution that allows authors/designers/publishers to create digital books using the typefaces that we use for print without any additional fees. For many books it would be prohibitive to have an additional $800 annually tacked on to the costs of the digital publication. I don't think anyone would have a problem with some security around embedded fonts in HTML or ePub3 documents. But, the current solution won't work long-term. Books are going digital and a dramatic increases in costs for typefaces can't be supported financially in the long-term.

Build a list of approved fonts (ones that don't have
draconian licensing restrictions) that your authors
should stick to. For existing works that rely on fonts
with prohibitive conditions, find suitable substitutes
and convert to those.

You might consider hiring a consultant well-versed
in font licenses as well as font style matching. One
such person to consider would be Stephen Coles,
co-founder and editor of Typographica.

hhp

But those won’t work off line right? I’d like to start this discussion all over again. There should be a consensus, and it should take into consideration both small and big actors while providing income for type designer and a reasonable protection against pirating. When WOFF support is here, cross platform and cross browser, hopefully licensing fees will sort itself out.

>Books are going digital and a dramatic increase in costs for
>typefaces can't be supported financially in the long-term.

Of course, it's obvious. Except to the folks who sell typefaces. When God wants to be unkind he makes you a part of the copyright industry and sends fairy-godmothers like Microsoft and Adobe to watch over you.

>income for type designer and a reasonable protection against pirating

There is a simple solution to this. It flows from the fact that very, very few fonts made for graphics will also work well in browsers without adaptation for the purpose. (Epub rendering engines are browser engines. I don't know of any exceptions or why anyone would want to deviate and re-invent the wheel. Amazon has flat-out announced that HTML5 will be it's publishing language going forward.)

What foundries should be licensing for this work are their fonts post-processed and re-tasked for the web.
Got OTFs with a million kerning pairs and advanced OT features guaranteed to send a tickle up your leg? Great, keep selling them. (Yeah, I know, licensing them.) But please, keep them off the web because they don't belong there.
Instead, toss the fracking kerning pairs out the window ('cause browser support stinks and CSS can handle the kerning where it's absolutely necessary, anyway) and license a font that's -
 • sub-setted with web publishing in mind
 • converted to TTF - the format with the broadest support and, in Windows rendering envionments, a necessity
 • tweaked with adequate TrueType hinting, normalized vertical metrics, scaling, whatever is necessary - for web publishing. (Epub being a subset of web publishing. Is iPad going to be the ONLY platform for you? I don't think so.)

The idea that fonts created for graphic design work can be licensed for the web and/or epub AS IS and make a customer happy is delusional. As is the idea that there is a market for those very same fonts bundled in an epub wrapper and/or posted on a web server. Anyone who designs for the web, or it's cousin e-pub, are finding this out now, bit by bit. It's an astounding situation, really. Talk about elephants in the room, wow.

But once you realize that those fonts can fork into two distinct products - one font, the "original", for print as is, and a post-processed version, the "web font", for e-publishing there is no problem.
What you've exposed to "piracy" is a low-cost spin-off. And a spin-off that works better for the customer's purpose.

This is one thing I've been spending a lot of time working on for the past year and I'm about to hang a shingle - offering a service that takes fonts, as is, and adapts them at a very reasonable cost, for e-publishing.

>We happen to have one author who uses their Knockout typeface.
>So, we need to find a suitable substitute.

Please contact me, we can help with this.

Richard Fink
Blog: Readable Web
Font Director: Kernest/Konstellations