Adobe Fonts Not All Handled Properly by Calibre

[mazdaspeed]

Since Adobe CC Fonts are licensed for EPUB distribution, I export them using InDesign to a reflowable EPUB, and the packaged .epub file contains the subset fonts, as well as the encryption.xml file to extract them.

Calibre opens the EPUB with the Adobe fonts already subset, however, I am recently finding that some Adobe fonts are being mishandled when using bold, applying bold to some characters and not to others.

This is not true of all Adobe fonts, and I'm having great difficulty narrowing down the issue. Neither is the issue just local to Calibre, since when I convert using Kindle Viewer, the bold inconsistencies carry through the conversion.

Here's a screenshot and an explanation:

In the screenshot, the first "Chapter 1" is using "h1.h1SerifChapter".
The second "Chapter 1" is using "h1.ChapterHeading".
Both are bold fonts.
As you can see, the "Ch" and "e" are bold (or bolder?) and the other characters are not.

https://www.mobileread.com/forums/at...1&d=1655152696

Here are the relevant parts of my CSS:

@font-face {
src: url(../WarnockPro-BoldDisp.otf);
font-family: "Warnock Pro Display";
font-weight: bold;
font-style: normal;
font-stretch: normal;
}
@font-face {
font-family: "Kepler Std Disp";
font-style: normal;
font-weight: bold;
src: url(../KeplerStd-BoldDisp.otf);
}
h1.h1SerifChapter {
color: #606060;
font-family: "Warnock Pro Display", serif;
font-size: 1.8rem;
font-style: normal;
font-weight: bold;
line-height: 1.2;
margin: 0.5em 0 0.2em 0;
orphans: 1;
text-align: center;
text-indent: 0;
widows: 1;
}
h1.ChapterHeading {
color: #606060;
font-family: "Kepler Std Display", serif;
font-size: 1.8em;
font-style: normal;
font-variant: normal;
font-weight: bold;
line-height: 1.2;
margin: 0.5em 0 0.2em 0;
orphans: 1;
text-align: center;
text-indent: 0;
widows: 1;
}

Anyone have any ideas?

[jhowell]

I suggest trying without subsetting the fonts in case something is going wrong with that.

[JSWolf]

Originally Posted by jhowell

I suggest trying without subsetting the fonts in case something is going wrong with that.

If they are also obfuscated, then remove that.

[Quoth]

Originally Posted by mazdaspeed

Since Adobe CC Fonts are licensed for EPUB distribution, I export them using InDesign to a reflowable EPUB, and the packaged .epub file contains the subset fonts, as well as the encryption.xml file to extract them.

Anyone have any ideas?

1) Don't use Adobe CC Fonts. They won't pass any normal upload for distribution as they are encrypted. Only use unencrypted fonts.

2) Use Indesign for paper, not ebooks. It's a terrible tool for ebooks. MS Word or LO Writer (extra Save As in docx) and then Sigil or Calibre. Make sure you use paragraph and heading styles sensibly.

3) There are no shortage of good free fonts for ebooks. Subsetting works and saves a lot on font used for headings.

[mazdaspeed]

So, here's a follow-up on this matter after a couple weeks of intense troubleshooting.

Many of the eBooks I publish are 500 pages and up, and with our organization's standard promotional pages and their associated images, I can easily approach an EPUB file size of 2Mb if the font files don't subset into reasonable sizes. For this reason, Adobe Fonts are preferable because InDesign subsets them into quite small file sizes of about 25Kb-35Kb. I do understand that Calibre will subset fonts, but not this efficiently.

InDesign both embeds and subsets the fonts when it exports to EPUB, and what I've learned over the past couple of weeks is that InDesign often creates paragraph and character spans that are dual purpose in nature, and may apply 2 span attributes to a single span when styling a portion of text (forgive me if my html/CSS nomenclature is less than perfect).

As such, you can get something like the following in your CSS output, where a span uses a combination of two span declarations. Here's an excerpt of some actual html/CSS from a promotional page, where my character style, "BoldCharaRPI" could be combined with two or more different font faces, sizes, etc:

Spoiler:

<p class="pSerifNoIndent">While we were distributing <span class="BoldCharaRPI _idGenCharOverride-10">Rising Press International</span> publications.</p>

span.BoldCharaAcrosticEPUB {
font-style:normal;
font-weight:bold;
}
span.BoldCharaEPUB {
font-style:normal;
font-weight:bold;
}
span.BoldItalicCharaEPUB {
font-style:italic;
font-weight:bold;
}
span.FtntRefNumEPUB {
font-style:normal;
font-weight:bold;
vertical-align:super;
}
span.ItalicCharaMyriadEPUB {
font-style:italic;
font-weight:normal;
}
span.ItalicCharaScriptEPUB {
font-family:"Kepler Std Medium", serif;
font-style:italic;
font-weight:500;
}
span.ItalicLightCharaEPUB {
font-style:italic;
font-weight:normal;
}
span.ScriptVerseNumEPUB {
font-family:"Kepler Std Light", serif;
font-size:0.75em;
font-style:normal;
font-weight:600;
}
span.ScrptBlckVrsRefEPUB {
font-style:normal;
font-weight:normal;
}
span.SemiboldCharaEPUB {
font-style:normal;
font-weight:bold;
}
span.SemiboldItalicEPUB {
font-style:italic;
font-weight:bold;
}
span.BoldCharaRPI {
font-style:normal;
font-weight:bold;
}
span.BoldItalicCharaRPI {
font-style:italic;
font-weight:bold;
}
span.ItalicCharaMediumRPI {
font-style:italic;
font-weight:normal;
}
span.SemiboldCharaRPI {
font-style:normal;
font-weight:bold;
}
span._idGenCharOverride-1 {
font-family:"Myriad Pro Light";
}
span._idGenCharOverride-2 {
font-family:"Kepler Std Light";
}
span._idGenCharOverride-3 {
font-family:"Kepler Std Medium";
}
span._idGenCharOverride-4 {
font-family:"Kepler Std Light";
font-size:58%;
}
span._idGenCharOverride-5 {
font-size:0.818em;
}
span._idGenCharOverride-6 {
font-family:"Kepler Std";
}
span._idGenCharOverride-7 {
font-family:"Myriad Pro Light";
font-size:58%;
}
span._idGenCharOverride-8 {
font-family:"Minion Pro SmBd";
font-size:58%;
}
span._idGenCharOverride-9 {
font-family:"Minion Pro Med";
}
span._idGenCharOverride-10 {
font-family:"Minion Pro";
}
span._idGenCharOverride-11 {
font-family:"Adobe Caslon Pro";
}

The above CSS example might be excessive to make my point, but it's the actual number of spans generated in my most recent publication. I always rename the _idGenCharaOverride-NN to something that makes sense to me, but I left them here for the example of actual InDesign output for a single book.

Back when I was not defining my eBook fonts, and simply used serif and sans-serif font families, I would rename and/or remove most of the "_idGenCharOverride-NN" from my markup, keeping only what was necessary for Bold, Italic, BoldItalic, etc.

However, this cannot be the case when using subset fonts exported by InDesign, because InDesign calculates every iteration of a font applied to the text in your working document, and subsets the font file to only the necessary characters within it. As such, don't expect to be able to swipe a subset Adobe font from one EPUB and use it in another, as it likely will give you problems like the one I pictured in my initial post.

I'm now getting Kindle to process attributes such as: "font-weight: 500" for a semibold font, assuming it's applied to a subset font that uses the 500 weight. If I don't have the applicable font file embedded, then it won't work. However, after 2 weeks of hair-pulling I just successfully published a KDP book using 11 iterations of 3 font faces.

Adobe fonts work perfectly, when utilized perfectly. There are no shortcuts.

Now, many will ask, why are you specifying fonts, anyway? The answer is that I'm creating a Brand. I really don't care what font the end user chooses to read the book with, but I do care what the book looks like the first time the book is opened -- namely, just like the paperback. I would also like to think I'm choosing fonts that are pleasing to read, but that's an expectation beyond this scope.

I know someone said, "don't use InDesign for EPUBs," but I'm not going to throw my work out after creating the paperback. That just doesn't make sense. Besides, Adobe has made leaps and bounds with EPUB export, since 2020. I highly recommend it.

With that said, and with my latest EPUB published using Calibre as a finishing tool, it's time to make another contribution to the Calibre project. Keep up the good work, David!

[mazdaspeed]

As for Encryption with Adobe Fonts. Per Adobe's EULA, encryption is not required when the font is properly subset. In order to even get Kindle Previewer to read the "Publisher Font" you must scrap the encryption.xml file that is generated by InDesign. Simply include a blank (header-only) encryption.xml file.

[DNSB]

Originally Posted by mazdaspeed

As for Encryption with Adobe Fonts. Per Adobe's EULA, encryption is not required when the font is properly subset. In order to even get Kindle Previewer to read the "Publisher Font" you must scrap the encryption.xml file that is generated by InDesign. Simply include a blank (header-only) encryption.xml file.

May I ask how you are removing the encryption from the font files themselves? My preferred method is to open the epub in Sigil, right-click each font file and set the encryption to none. When you remove the encryption from all the font files, Sigil will remove the unneeded encryption.xml file.

[mazdaspeed]

In re-reviewing the EULA for Adobe Originals fonts, I must retract part of my previous statement. I'm not providing legal advice.

It appears the font is to be subset AND encrypted. However, it's my present understanding the encryption.xml file is not what encrypts the font. It would be good if someone could speak to this that better understands it.

In the meantime, until I get this understood, I will be de-publishing the one eBook that I just finished.

[Tex2002ans]

Originally Posted by mazdaspeed

In re-reviewing the EULA for Adobe Originals fonts, I must retract part of my previous statement. I'm not providing legal advice.

The ultimate topic on this was last year:

• 2021: "Embedding Adobe Fonts into a Kindle title"
  
  • (Especially see Post #5 + Post #34)

(And/or all other responses written by Hitch.)

Long story short, what Adobe says about "our cloud/embedded fonts working in ebooks" is complete hogwash in reality.

Trying to sell such an ebook in any of the actual stores (Amazon, B&N, Kobo, etc.) won't work.

Originally Posted by Quoth

1) Don't use Adobe CC Fonts. They won't pass any normal upload for distribution as they are encrypted. Only use unencrypted fonts.

Correct.

You'd have to purchase fonts separately and get actual embedded licenses (which cost MUCH more than normal fonts).

(See topic above + the tons of "embedded fonts" topics over the years.)

For example, Hitch's amazing:

• 2016: "Embedding font (word)" (Post #25)

or some other minor discussion in:

• 2021: "ePub chinese fonts"

where I summarized some of the embedded fonts knowledge + referenced Hitch's posts.

(Again, Hitch is the ultimate resource on this topic.)

Originally Posted by Quoth

2) Use Indesign for paper, not ebooks. It's a terrible tool for ebooks.

Stop this.

If you know how to use Styles properly, it's fine. (Just like Word/LibreOffice with Styles is fine.)

Yes, it's mostly designed for a Print-first workflow, but the ebook section of it is "okay".

You also get more control over HTML/EPUB output compared to Word (because of Style Mapping).

- - -

Side Note: Yes, a lot of the InDesign output is junk... but if you're one of the 1% that knows how to use it properly...

Side Note #2: I like to bash Adobe/InDesign (and Microsoft) as much as anyone, and will steer people clear when needed or if I think it's the completely wrong tool for the job...

But in this specific case, continuing to use InDesign is fine.

No need to recommend throwing everything out and use completely different tools when it's not applicable to the topic at hand (font embedding stuff).

Originally Posted by Quoth

MS Word or LO Writer (extra Save As in docx) and then Sigil or Calibre. Make sure you use paragraph and heading styles sensibly.

Yes, of course. Same can be done in InDesign.

And if you use your Styles properly, you can even map:

• Word/LibreOffice Styles <-> InDesign Styles -> HTML/EPUB Classes.

Originally Posted by mazdaspeed

Now, many will ask, why are you specifying fonts, anyway? The answer is that I'm creating a Brand. I really don't care what font the end user chooses to read the book with, but I do care what the book looks like the first time the book is opened -- namely, just like the paperback. I would also like to think I'm choosing fonts that are pleasing to read, but that's an expectation beyond this scope.

Doesn't work this way in reality.

IF insisting on using embedded fonts, use them very sparingly (headings, title pages, etc.). To try to force them as the body text is asking for trouble.

I won't rehash reasoning why. Read the above topics + the 10+ years of "embedded fonts" discussion on MobileRead.

Print ≠ Cellphones (LCD/OLED) ≠ E-ink

Fonts that work well in one technology won't work well in others.

And lots of the advanced CSS3 that InDesign may insert (font-kerning, letter-spacing, etc.) might "look correct on the surface", but will explode when users decide to change fonts.

[JSWolf]

Originally Posted by Quoth

1) Don't use Adobe CC Fonts. They won't pass any normal upload for distribution as they are encrypted. Only use unencrypted fonts.

2) Use Indesign for paper, not ebooks. It's a terrible tool for ebooks. MS Word or LO Writer (extra Save As in docx) and then Sigil or Calibre. Make sure you use paragraph and heading styles sensibly.

3) There are no shortage of good free fonts for ebooks. Subsetting works and saves a lot on font used for headings.

2. If you do use InDesign for both eBooks and pBooks, then be preared to dive into the code for the eBook and clean it up. You will need to know HTML/CSS.

3. Unless you really do need to have a specific font, don't embed. On most Kindles, even if you do embed, they won't be setting Publisher Default. So they won't see the embedded font(s). On ePub, you may end up pissing off your readers with a font they don't like.

[JSWolf]

InDesign embeds fonts when you don't actually need them. Looking at mazdaspeed's code, it's awful. It can be made a lot neater when edited by hand.

Most of those spans and the CSS code can go away. Just use the appropriate <i> and <b>. Also, the font references can go as those are not fonts that work well on eInk screens. When you want to use a sans-serif font, use font-family: sans-serif; and let the reading program use it's default sans-serif font.

With not much time, I can take most of those spans and get rid of them and keep all the bold/italics in the HTML. I've edited a lot of eBooks made with InDesign and when I am done, they are so much better. The code is better, the formatting is better, the embedded fonts are gone (in most cases and even if not, only one or two fonts are left). Don't assume the fonts you use for print work for eBooks. These are two different formats and what works for one may not work for the other.

For example, pBooks do need some L/R margins because of the spine of the book. But an eBook does not need L/R margins. An eBook does not need a line height. An eBook does not need 1/3rd or 1/4th of the screen taken up with the chapter header. An eBook does not need *** for a section break to say you are at or near the end of the printed page. An eBook does not need a disclaimer that it's illegal to sell without the cover. An eBook needs larger (subset is too small) characters for footnote markers.

So learn to code so you can fix the mess left behind by InDesign. It's not difficult to do.

But with spans, please don't do use them for bold and/or italics. Just no.

[JSWolf]

Originally Posted by mazdaspeed

Since Adobe CC Fonts are licensed for EPUB distribution, I export them using InDesign to a reflowable EPUB, and the packaged .epub file contains the subset fonts, as well as the encryption.xml file to extract them.

Calibre opens the EPUB with the Adobe fonts already subset, however, I am recently finding that some Adobe fonts are being mishandled when using bold, applying bold to some characters and not to others.

This is not true of all Adobe fonts, and I'm having great difficulty narrowing down the issue. Neither is the issue just local to Calibre, since when I convert using Kindle Viewer, the bold inconsistencies carry through the conversion.

Here's a screenshot and an explanation:

In the screenshot, the first "Chapter 1" is using "h1.h1SerifChapter".
The second "Chapter 1" is using "h1.ChapterHeading".
Both are bold fonts.
As you can see, the "Ch" and "e" are bold (or bolder?) and the other characters are not.

https://www.mobileread.com/forums/at...1&d=1655152696

Here are the relevant parts of my CSS:

@font-face {
src: url(../WarnockPro-BoldDisp.otf);
font-family: "Warnock Pro Display";
font-weight: bold;
font-style: normal;
font-stretch: normal;
}
@font-face {
font-family: "Kepler Std Disp";
font-style: normal;
font-weight: bold;
src: url(../KeplerStd-BoldDisp.otf);
}
h1.h1SerifChapter {
color: #606060;
font-family: "Warnock Pro Display", serif;
font-size: 1.8rem;
font-style: normal;
font-weight: bold;
line-height: 1.2;
margin: 0.5em 0 0.2em 0;
orphans: 1;
text-align: center;
text-indent: 0;
widows: 1;
}
h1.ChapterHeading {
color: #606060;
font-family: "Kepler Std Display", serif;
font-size: 1.8em;
font-style: normal;
font-variant: normal;
font-weight: bold;
line-height: 1.2;
margin: 0.5em 0 0.2em 0;
orphans: 1;
text-align: center;
text-indent: 0;
widows: 1;
}

Anyone have any ideas?

Get rid of the embedded fonts. Get rid of the colors. Get rid of the line-height. rem needs to be em. Change the margin shorthands to be individual margin statements. Widows and Orphans go in the body CSS code.

I've reduced your CSS to one simple class.

h2 {
  font-weight: bold;
  margin-top: 0.8em;
  margin-bottom: 0.8em;
  text-align: center;
  text-indent: 0;
}

<h2>Chapter 1</h2>

[JSWolf]

Originally Posted by mazdaspeed

In re-reviewing the EULA for Adobe Originals fonts, I must retract part of my previous statement. I'm not providing legal advice.

It appears the font is to be subset AND encrypted. However, it's my present understanding the encryption.xml file is not what encrypts the font. It would be good if someone could speak to this that better understands it.

In the meantime, until I get this understood, I will be de-publishing the one eBook that I just finished.

encryption.xml is what lets the reading program decrypt the fonts so they can be displayed. But you don't need it as you don't need the fonts.

[mazdaspeed]

It would be nice if Adobe, Amazon, Apple, IDPF, etc. would step-up and clarify these extremely important issues surrounding licensing EPUB fonts, and the hazards thereof. Across the EPUB creation community there is absolutely no consensus on the matter.

I've read everything from "don't mess with the encryption.xml", to "remove the encryption.xml" completely, to "just don't use Adobe or licensed fonts." Well, for one thing, most fonts are licensed in one way or another, and every place that is distributing them makes disclaimers about how they are not giving legal advice for their usage... This includes Google Fonts.

Adobe, for all their hyped inclusiveness for EPUB, doesn't specify precisely how to encrypt or obfuscate to their satisfaction -- as though there's any difference in that terminology. What I do know is that Adobe InDesign subsets and "encrypts" the fonts when exporting EPUBs, and it packages an encryption.xml into the EPUB file that KDP won't process to my satisfaction.

If I strip the encryption.xml file of everything but its header, then it does work for KDP. If this is not satisfactory to Adobe, then they need to speak up. I've done my part by paying the monthly subscription and following directions as closely as I can.

I read a 2015 post from Smashwords that said they reject anything with the encryption.xml file, and another that said Apple removes it themselves. What I think may be the case is that Amazon and the aggregators use its presence as a red flag against problematic EPUBs, as there are many who are not meticulous in what they are doing.

The encryption.xml file does not contain any encryption code, but is simply a list of encrypted, subset fonts that Adobe processed on export, and its data appears nowhere else in the EPUB package. The data looks something like this:

<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:conta iner" xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
<enc:EncryptedData>
<enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding" />
<enc:CipherData>
<enc:CipherReference URI="OEBPS/font/ACaslonPro-Bold.otf" />
</enc:CipherData>
</enc:EncryptedData>
<enc:EncryptedData>
<enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding" />
<enc:CipherData>
<enc:CipherReference URI="OEBPS/font/ACaslonPro-Semibold.otf" />
</enc:CipherData>
</enc:EncryptedData>


From what I've read in a couple other places, it is the Adobe-generated <dc:identifier> that contains the encryption keys, and that this should not be altered in any way, including the order it's placed in the content.opf file. Ex.:
<dc:identifier id="bookid">urn:uuid:628f239d4-1za5-4731-b227-ce1f89dc2e97</dc:identifier>

As such, I've been adding a second <dc:identifier> that uses the ISBN, like so:
<dc:identifier id="isbn">urn:isbn:9781548950752</dc:identifier>

Whether all that info is completely accurate, I don't know, but for now this is working for me. Again, I stress that I am trying to follow the rules, pay the fees, and not trying to circumvent costs. These costs should be easily recoverable for anyone serious about the business.

[JSWolf]

mazdaspeed, what is it about DO NOT EMBED FONTS don't you get? The fonts you show in your sample code DO NOT NEED TO BE EMBEDDED. You do not need to try to make the eBook look like the pBook by embedding the same fonts the pBook sues.