Font Obfuscation

[kso]

Hi,

I've probably overlooked any posts about who is actually responsible for the obfuscation of fonts I would like to embed in Kindle books (to be sold on Amazon). Same question applies to books sold as EPUB (Apple, Smashwords etc). Is it me, the book creator, or the distributor when creating the final file for distribution?

I presume it's Amazon (and for EPUBs distributors like Apple, B&N and others). But I have been known to mis-presume.

I've read some technical posts about font obfuscation, but I'm not sure where to insert this into a workflow where required, and more importantly, if I have to touch fonts at all or just include them to be handled by the relevant poblishing system.

Thanks for any pointers.

Klaus

[phillipgessert]

You’ll have to do it.

[JSWolf]

You could do font subsetting and forget the obfuscation. The obfuscation can easily be removed. But a subset font is not going to be useful outside of that eBook.

[Quoth]

Font subsetting and make sure the main body font(s) are freely redistributable. Fonts embedded in a PDF and in an ebook are not treated the same under some font providers licences.

AFAIK no retailer obfuscates fonts.

Also no DRM as it is no barrier to pirates and is a pain to valid purchasers. It's snake oil and only the DRM selling companies and pirates benefit.

Font subsetting can also save a lot of space.

[JSWolf]

Originally Posted by Quoth

Font subsetting and make sure the main body font(s) are freely redistributable. Fonts embedded in a PDF and in an ebook are not treated the same under some font providers licences.

AFAIK no retailer obfuscates fonts.

Also no DRM as it is no barrier to pirates and is a pain to valid purchasers. It's snake oil and only the DRM selling companies and pirates benefit.

Font subsetting can also save a lot of space.

I thought Amazon obfuscates embedded fonts.

[jhowell]

As far as I can tell none of Amazon's documentation for publishers mentions font obfuscation. (If anyone knows differently I would appreciate a link.)

I do know that neither Amazon's Kindle Previewer or the older kindlegen support input files with obfuscated fonts. Kindlegen would include the fonts without the key needed to deobfuscate them resulting in unusable fonts. Kindle Previewer will just silently strip them out. Perhaps obfuscated fonts will be handled correctly if the EPUB is instead uploaded to Amazon, but I wouldn't count on it.

Font subsetting can be problematic if not done carefully. The book rendering process can introduce characters that were not present in the original content and problems will occur if those characters are not present in the font. Two examples are automatic list numbering and ligature substitution.

[jhowell]

Originally Posted by JSWolf

I thought Amazon obfuscates embedded fonts.

KF8 format supports font obfuscation, but since the key needed to decrypt is included with each font it is as worthless as EPUB font obfuscation.

KFX format doesn't use any type of font obfuscation.

[Tex2002ans]

Originally Posted by JSWolf

You could do font subsetting and forget the obfuscation.

Originally Posted by kso

I've read some technical posts about font obfuscation, but I'm not sure where to insert this into a workflow where required, and more importantly, if I have to touch fonts at all or just include them to be handled by the relevant poblishing system.

I'd do it at the very end, if ever.

But as was mentioned above, subsetting the fonts should be okay. This will remove all unused characters, minimizing the filesize while making it foolish to transfer to other books. This embedded font will also work much better across a variety of readers.

Nowadays, the easiest way to subset is probably through Calibre:

Method #1

If converting from another format, under Look & Feel, there's a checkbox for Subset all embedded fonts.

Method #2

Or in the Calibre Editor, Tools > Subset embedded fonts.

Calibre Editor also lets you easily embed fonts in your EPUB with Tools > Embed referenced fonts. (Although you'll have to already have the correct CSS.)

* * *

There are many other tools/methods for embedding/subsetting out there. A lot of this was written about in the great thread:

2019: "Font Best Practices"

[Quoth]

Originally Posted by jhowell

Font subsetting can be problematic if not done carefully. The book rendering process can introduce characters that were not present in the original content and problems will occur if those characters are not present in the font. Two examples are automatic list numbering and ligature substitution.

Elsewhere it's pointed out that automatic list anything tends to break so better to explicitly have the indentfier text typed in. Solves issue of font.

I don't like automatic ligature substitution. I want ligatures or not according to the source docx. Can that be avoided on KF7, KF8, KFX and epub2? Our Amazon content is from an epub2 upload. Only Smashwords gets a Kindle upload (a dual mobi made from the epub2 in Calibre).

[jhowell]

Originally Posted by Quoth

I don't like automatic ligature substitution. I want ligatures or not according to the source docx. Can that be avoided on KF7, KF8, KFX and epub2? Our Amazon content is from an epub2 upload. Only Smashwords gets a Kindle upload (a dual mobi made from the epub2 in Calibre).

Ligatures are sometimes substituted for character pairs based on the user's font selection in KFX format (Enhanced Typesetting). I do not know of any way for the publisher to control that. Since they do not occur for every font it appears that the KFX renderer is smart enough to recognize fonts that lack them.

Ligature substitution does not happen when reading in MOBI7 or KF8 format so it is not an issue for your dual MOBI.

[Quoth]

Thanks!
OK, so not a problem on epub2 -> Amazon KDP -> KFX
OR
Dual mobi from Calibre to Smashwords.

What about kepub from Kobo, when they are sent an epub2?

[kso]

Thanks for all the pointers.

To summarise, obfuscation is required by some font vendors and not, as I thought, by whoever sells an ebook to the reader (Amazon, Apple, B&N etc). So these vendors are "out" if it's not a general requirement.

@JSWolf: I just learned today that subsetting (or modifying---as in fixing---things like kerning) is not permitted by some vendors. These are out, too.

A current discussion on Hacker News (https://news.ycombinator.com/item?id=28403484") talked about this and other license issues that made me come to the conclusion that apart from Public Domain, SIL Open Font and comparably licensed fonts it's just not worth the hassle picking apart lawyer created legalese. List is getting really short now.

That leaves just a handful of font vendors (plus free fonts, OFL, Google etc). I like the Fontspring approach, but their catalogue lacks in some respects (which is probably me having the wrong taste).

@jhowell: Thanks for the examples to look out for when subsetting. I would have tripped over ordered lists (but left all the ligs unchanged just in case). Btw: I believe inserting a "zero width non joiner" prevents many (all?) renderers from showing a ligature where the zwnj is meant to force two individual letters. But I haven't checked this with the latest KPV as I had some other rather silly alignment issues.

@Tex2002ans: In the end I'm not even sure if I will subset at all. I tend to use small fonts to avoid bloat anyway, but the final decision depends on a few tests I'll have to do to see how much fonts can be shrunk.

Thanks again folks.

klaus

[JSWolf]

Subsetting can shrink fonts quite a bit. It also means nobody can take the font and use it for something else as it's not complete. I've subset a lot in the past and I've had no problem with RMSDK or KF8 on a Kindle.

[phillipgessert]

I usually use an SIL font and subset it anyway for tidiness. I only use it for chapter heads, but that’s a good tip about discretionary ligatures. I’d not thought of that.

Seems to me that most sensible fonts used in print would have a pretty-close equivalent with an open license. So I like to avoid the tangle of “real” obfuscations.

[JSWolf]

Originally Posted by phillipgessert

I usually use an SIL font and subset it anyway for tidiness. I only use it for chapter heads, but that’s a good tip about discretionary ligatures. I’d not thought of that.

Seems to me that most sensible fonts used in print would have a pretty-close equivalent with an open license. So I like to avoid the tangle of “real” obfuscations.

Calibre subsets very well and ligatures are not lost.