Months of Runaround From KDP Support: Font Embedding Fails...HELP!

[dgatwood]

Originally Posted by JSWolf

I just tried this using Bluefire Reader and it didn't work. I overrode the default embedded font and I did not see BlankFont show up in red at all.

IIRC, Bluefire uses a sane, non-evil approach to font overrides, as opposed to the truly defective ones that the above code is designed to catch—that is to say, if you specify a style on an element that includes a font, Bluefire honors it. For my purposes, I was okay with a reader overriding the body font, so long as it didn't override any of the decorative fonts used for non-body content.

If you want something that catches *every* instance of a font override, you have to approach it similarly, but with different CSS:

• Set the base font for an entire HTML file to blankfont.
• Include a paragraph of explanatory text, and give that paragraph a font override (with !important, in the inline style, which should give it absolute precedence over everything else).
• Follow it with a paragraph that has no font specified.

A conforming reader that isn't overriding the font will display an empty paragraph instead of that second paragraph. A reader that is overriding the font in any way will display the contents.

[Tony_A20]

Originally Posted by Hitch

Well...gods know I have tons of advice. Whether any of it is useful or not is not necessarily guaranteed. ;-)

Can you give me some better examples of what it is you are not achieving? I am, literally, not following. You should not have any issues applying regular styling to paragraphs that have fonts, unless (no offense) you are doing something wrong. I mean, see attached. All of those are styled--a BOATLOAD, particularly the one with the sidebar. (I think that the Ollie North book only has a chapter-head font, but...same diff.)

Can we get some actual code samples in here? Otherwise, I'm really flailing.

Hitch

Hello Hitch, Sorry I've taken so long to post a reply. Here is the code I'm using. It works, but I don't understand why I had to do it this way.

@font-face { font-family: marg; /* named after person writing */
font-style: normal;
font-weight: normal;
src:url(AlexBrush-Regular.ttf); }

.marg
{font-family: marg, serif;
font-size: 150%;
font-weight: normal;
line-height: 100%;
margin-top: 0%;
margin-bottom: 0.5%;
text-align: left;
text-indent: 0%;}

.margindent
{font-family: marg, serif;
font-size: 150%;
font-weight: normal;
line-height: 100%;
margin-top: 0%;
margin-bottom: 0%;
text-align: left;
text-indent: 50%;}

div.letter /* For handwritten font script used in personal letters */
{margin-top: 1%;
margin-bottom: 1%;
margin-left: 1%;
margin-right: 1%;}

<div class="letter">
<br />
<p class="margindent">London,</p>
<p class="margindent">October 29, 1898.</p>
<p class="marg">Dear Raymond,</p>
<p class="marg">
How horrible it must have been to have your leg amputated and become a crippled invalid. However, our lives must go on, and as you well know I abhor imperfection of person and therefore regret to inform you that I have engaged Messrs. Radford and Wilson to seek a divorce. I'm sure you will find solace in your desire to maintain my personal happiness.
</p>
<p class="marg">Margaret</p>
</div>

I found I could not get the font to work if I tried to declare the font as:
<div class="letter marg">. I had to set the font class on every paragraph.

As well, I could not get the font to indent unless I used a separate declaration and repeated all the selectors used in the "marg" class.

I was expecting something like this would work:
.marg (selectors as above)

.margindent
{text-indent: 50%;}

<div class="letter marg">
<br />
<div class="margindent>
<p>London,</p>
<p>October 29, 1898.</p>
</div>
<p >Dear Raymond,</p>
<p>
How horrible …
</p>
<p>Margaret</p>
</div>

So, what do you think I did wrong?

Tony

[Hitch]

Is that how you typed it?

<div class="letter marg">

Is that exact method of using multiple classes working for anything else, other than fonts?

Hitch

[Tony_A20]

Hello Hitch,

Yes, that's how it's typed.

As far as I know it's a standard method of applying multiple CSS declarations. I use it all the time.

Here are a few examples from my latest e-book:
<div class="breakbefore breakafter"> applies page breaks around chapters
<div class="pullquote quote-bg"> applies a pull-quote text and background
<p class="first greybx"> sets no indent for first line and puts para in a grey background box

I've had no problems applying up to 5 CSS declarations to one tag.

Anyway, what about my code? Should it have worked the way I thought or is it necessary to repeat the whole font declaration just to add another selector?

Should the <div class="letter marg"> have worked?

Tony

[odedta]

If you run your code through Calibre's "Check Book" tool you should get the following error:

The font family name specified in the CSS @font-face rule: "marg" does not match the font name inside the actual font file: "AlexBrush". This can cause problems in some viewers. You should change the CSS font name to match the actual font name.

Adding a few classes to an HTML element using spaces is the way to do it and is supported. I believe that if you fix the above error it should work.

[Tony_A20]

Hello odedta, Thanks for your reply.

I tried changing the @font-face to font-family: AlexBrush; and replacing "marg" with "AlexBush" and despite what Calbre may think, it doesn't make any difference. The family-name can be anything provided the src: is correctly identified.

From MDN
@font-face
{
[ font-family: <family-name>; ]?
...
}
family-name
Specifies a name that will be used as the font face value for font properties. ( i.e. font-family: <family-name>; )

An online example is:
@font-face
{
font-family: MyHelvetica;
src: url(MgOpenModernaBold.ttf);
}

So, Calibre's error message is incorrect.

What is happening is this:

This works,

<div class="letter">
<p class="marg">This is a test.</p>
</div>

This doesn't,

<div class="letter marg">
<p >This is a test.</p>
</div>


The problem seems to be combining the font class with anything else.
Multiple classes cause the font to fall back to the default/inherited font BUT, the other properties are correctly applied.

However if this CSS declaration is made:

p.inherit
{
font-family: inherit;
}

then this works:

<div class="letter marg">
<p class="inherit">This is a test.</p>
<p class="inherit">This is a second line.</p>
</div>

So, the font "marg" is being correctly applied by the division tag, but the para tag is nevertheless inheriting the font-family from somewhere else. Forcing the paragraph tag to inherit the font-family from the division tag declaration corrects the inheritance, but only for one para tag at a time.

So the situation is: state the "inherit" class on every tag, or state the "marg" tag on every tag, because the font-family property is not inherited. And that's the case with changing the font indent—nothing about the embedded font is inherited, any change/use must repeat the full CSS description.

The next question is: Why doesn't an embedded font become the new default after use?

Tony

[Tony_A20]

I found this on the web.

"The font-family property is special in the sense that the initial value is not fixed in the specification but defined to be browser-dependent. This means that the browser’s default font family is used. This value can be set by the user."

I believe the above is the underlying cause of the font-family application problems I experienced.

An embedded font is dependent on a CSS or styling description and the font family cannot become a default. Therefore the font-family description must be applied to each individual use either by repeating the font-family class or by forcing the font-family use by means of the "inherit" property.

End of story.

Tony

[Hitch]

Originally Posted by Tony_A20

Hello odedta, Thanks for your reply.

I tried changing the @font-face to font-family: AlexBrush; and replacing "marg" with "AlexBush" and despite what Calbre may think, it doesn't make any difference. The family-name can be anything provided the src: is correctly identified.

Spoiler:

From MDN
@font-face
{
[ font-family: <family-name>; ]?
...
}
family-name
Specifies a name that will be used as the font face value for font properties. ( i.e. font-family: <family-name>; )

An online example is:
@font-face
{
font-family: MyHelvetica;
src: url(MgOpenModernaBold.ttf);
}

So, Calibre's error message is incorrect.

What is happening is this:

This works,

<div class="letter">
<p class="marg">This is a test.</p>
</div>

This doesn't,

<div class="letter marg">
<p >This is a test.</p>
</div>

The problem seems to be combining the font class with anything else.
Multiple classes cause the font to fall back to the default/inherited font BUT, the other properties are correctly applied.

However if this CSS declaration is made:

Spoiler:

p.inherit
{
font-family: inherit;
}

then this works:

<div class="letter marg">
<p class="inherit">This is a test.</p>
<p class="inherit">This is a second line.</p>
</div>

So, the font "marg" is being correctly applied by the division tag, but the para tag is nevertheless inheriting the font-family from somewhere else. Forcing the paragraph tag to inherit the font-family from the division tag declaration corrects the inheritance, but only for one para tag at a time.

So the situation is: state the "inherit" class on every tag, or state the "marg" tag on every tag, because the font-family property is not inherited. And that's the case with changing the font indent—nothing about the embedded font is inherited, any change/use must repeat the full CSS description.

The next question is: Why doesn't an embedded font become the new default after use?

Tony

I'm going to have to see--and I know that this sounds odd--if we use multiple CSS classes anywhere. For MOBI, I mean. I don't think we do. ID's and classes, yes, of course. I asked Barb (the best bookmaker here, bar none) if she did, and she said she did, but ...I don't think so. I don't believe that any of us can think of multiple classes actually working, not for MOBI. Not with conflicting or not clearly-conformed styles. I just think that the mobi conversion loses its mind.

FWIW.

Hitch

[Doitsu]

Originally Posted by Hitch

I'm going to have to see--and I know that this sounds odd--if we use multiple CSS classes anywhere. For MOBI, I mean. I don't think we do. ID's and classes, yes, of course. I asked Barb (the best bookmaker here, bar none) if she did, and she said she did, but ...I don't think so. I don't believe that any of us can think of multiple classes actually working, not for MOBI. Not with conflicting or not clearly-conformed styles. I just think that the mobi conversion loses its mind.

AFAIK, you can have multiple classes, and as long as they don't contradict each other, nothing unexpected happens. However, if they do contradict each other the style last defined in the stylesheet wins, which might lead to unexpected results.

I've created a simple test file with two html files that contain exactly the same code and two stylesheets with exactly the same styles. The only difference is that in the second stylesheet the first style was moved to the end of the stylesheet.

HTML code

<body>
  <h3>Chapter 1</h3>

  <div class="first third">
    <p class="third first">It was a dark and stormy night.</p>

    <p class="first second">And so it began...</p>

    <p>The End.</p>
  </div>
</body>

page 1 style

.first {
    text-align: left;
    color: green;
    font-weight: bold;
    font-family: sans-serif;
    font-size: 1.5em;
}

.second {
    text-align: right;
    color: blue;
    font-family: monospace;
    font-style: oblique;
    font-size: 1em;
}

.third {
    color: red;
    font-variant: small-caps;
    text-align: center;
}

page 2 style

.second {
    text-align: right;
    color: blue;
    font-family: monospace;
    font-style: oblique;
    font-size: 1em;
}

.third {
    color: red;
    font-variant: small-caps;
    text-align: center;
}

.first {
    text-align: left;
    color: green;
    font-weight: bold;
    font-family: sans-serif;
    font-size: 1.5em;
}

As you can see, rearranging the styles makes a difference.

[Hitch]

Originally Posted by Doitsu

AFAIK, you can have multiple classes, and as long as they don't contradict each other, nothing unexpected happens. However, if they do contradict each other the style last defined in the stylesheet wins, which might lead to unexpected results.

I've created a simple test file with two html files that contain exactly the same code and two stylesheets with exactly the same styles. The only difference is that in the second stylesheet the first style was moved to the end of the stylesheet.

HTML code

<body>
  <h3>Chapter 1</h3>

  <div class="first third">
    <p class="third first">It was a dark and stormy night.</p>

    <p class="first second">And so it began...</p>

    <p>The End.</p>
  </div>
</body>

page 1 style

.first {
    text-align: left;
    color: green;
    font-weight: bold;
    font-family: sans-serif;
    font-size: 1.5em;
}

.second {
    text-align: right;
    color: blue;
    font-family: monospace;
    font-style: oblique;
    font-size: 1em;
}

.third {
    color: red;
    font-variant: small-caps;
    text-align: center;
}

page 2 style

.second {
    text-align: right;
    color: blue;
    font-family: monospace;
    font-style: oblique;
    font-size: 1em;
}

.third {
    color: red;
    font-variant: small-caps;
    text-align: center;
}

.first {
    text-align: left;
    color: green;
    font-weight: bold;
    font-family: sans-serif;
    font-size: 1.5em;
}

As you can see, rearranging the styles makes a difference.

Doits:

How'd you build that mobi? I mean, I see an azw3 file. Did you build that with Calibre or KG?

Vis-a-vis multiple classes: if memory serves, yes, we use them, but I think it's a matter of, KG is so "fragile," and the end-results so irrationally unpredictable at KDP, that we tend to stick to "simpler," in terms of coding, because if you have anything even slightly out of line, you either get the inverse of what you're expecting or as you say, unpredictable results.

I am not really sure why there's a problem with stating the class for each p, however. Sure, it would be nice to just do a div dec, and not have to style the p classes therein, but other things don't carry over p tags, so...why would fonts?

And, yes, sure, order *would* matter, when no other method of determining precedence, for inheritance, is specified--wouldn't you think?

Hitch

[Doitsu]

Hitch:

Originally Posted by Hitch

How'd you build that mobi? I mean, I see an azw3 file. Did you build that with Calibre or KG?

I used Kindlegen to build the .mobi file and Kindleunpack to extract the .azw3 file.

Originally Posted by Hitch

I am not really sure why there's a problem with stating the class for each p, however. Sure, it would be nice to just do a div dec, and not have to style the p classes therein, but other things don't carry over p tags, so...why would fonts?

I haven't got the faintest idea either, and without access to all source files all I can do is speculate. IIRC, Kindlegen doesn't like some embedded fonts that ADE and other ePub readers have no problems with. Maybe the OP's font is one of them.

Originally Posted by Hitch

And, yes, sure, order *would* matter, when no other method of determining precedence, for inheritance, is specified--wouldn't you think?

Order always matters.

[Tony_A20]

Hitch,

I've used the multiple class notation without any problems whatsoever. I design the classes I use to provide incremental styling, and I don't worry about conflicting properties because I try to make sure there are none, but if there were, I would expect the last property applied would replace any previous, conflicting property, and that might be a problem when listing multiple classes.

The thing I didn't know about, was the specification status of an embedded font-family not being inheritable. I understand why such a decision was made, but I don't understand why the special status of the font-family is not better known. I couldn't find anything specific about it in the CSS or HTML spec.

Kindlegen doesn't seem to mind, nor KDP. In fact, I've found the latest release of Kindlegen to be surprisingly forgiving and tolerant, and not at all concerned about many errors. On the other hand, it manages to mention warnings and errors for things (absolute and relative positioning) that the Kindle Publishing Guidelines say are supported—and work. Errors have to be pretty bad nowadays before Kindlegen refuses to produce a .mobi e-book.

I think your doubts about using multiple classes are unfounded. Give it a try.

Tony

[Hitch]

Originally Posted by Tony_A20

Hitch,

I've used the multiple class notation without any problems whatsoever. I design the classes I use to provide incremental styling, and I don't worry about conflicting properties because I try to make sure there are none, but if there were, I would expect the last property applied would replace any previous, conflicting property, and that might be a problem when listing multiple classes.

The thing I didn't know about, was the specification status of an embedded font-family not being inheritable. I understand why such a decision was made, but I don't understand why the special status of the font-family is not better known. I couldn't find anything specific about it in the CSS or HTML spec.

Kindlegen doesn't seem to mind, nor KDP. In fact, I've found the latest release of Kindlegen to be surprisingly forgiving and tolerant, and not at all concerned about many errors. On the other hand, it manages to mention warnings and errors for things (absolute and relative positioning) that the Kindle Publishing Guidelines say are supported—and work. Errors have to be pretty bad nowadays before Kindlegen refuses to produce a .mobi e-book.

I think your doubts about using multiple classes are unfounded. Give it a try.

Tony

Tony:

It's highly likely that our experience with mobi format, over the last 5 years, has indeed made us overcautious, but one thing you should be aware of: what works today won't necessarily work tomorrow, at the KDP. And it changes pretty abruptly, sans warning and with EXCEEDINGLY little forgiveness (I mean...are you testing on K4iOS, in a live environment? With incremental inheriteds?).

I don't mean to be so retro that I go "old school" prc, and we don't, but...I know that some of the reading apps, iOS particularly, ARE fragile. That one breaks when you look at it, so...yes, I am probably overcautious.

Hitch

[Peter Ahlstrom]

I had a weird error with KDP and font embedding yesterday. KDP reencoded the fonts (that I was using for headings) and stripped out unused letters—except some of the "unused" letters were actually used on an html file toward the end of the ebook, and viewing the Paperwhite view in Kindle Previewer had those letters replaced with a default font. It looked terrible. (On the Kindle Fire preview pages, it was loading the font from my computer, so the error wasn't visible.)

I fixed this by making a "display:hidden" paragraph on the title page of the book that used all of those letters. Now the previously missing letters are embedded correctly and displayed fine on that late html file. The only letters that are missing from the embedded fonts now are the ones that are actually not used in the book.

Before I got this error, my fonts were refusing to embed at all (after running through KDP; kindlegen embedded them fine). I fixed that error by following the advice earlier in this thread: explicitly classing any tag that used an embedded font and getting rid of multiple-classed tags.

[Hitch]

Originally Posted by Peter Ahlstrom

I had a weird error with KDP and font embedding yesterday. KDP reencoded the fonts (that I was using for headings) and stripped out unused letters—except some of the "unused" letters were actually used on an html file toward the end of the ebook, and viewing the Paperwhite view in Kindle Previewer had those letters replaced with a default font. It looked terrible. (On the Kindle Fire preview pages, it was loading the font from my computer, so the error wasn't visible.)

I fixed this by making a "display:hidden" paragraph on the title page of the book that used all of those letters. Now the previously missing letters are embedded correctly and displayed fine on that late html file. The only letters that are missing from the embedded fonts now are the ones that are actually not used in the book.

Before I got this error, my fonts were refusing to embed at all (after running through KDP; kindlegen embedded them fine). I fixed that error by following the advice earlier in this thread: explicitly classing any tag that used an embedded font and getting rid of multiple-classed tags.

Peter:

Have you checked the post-KDP book on an iOS device? With an .azk file? Our experience with :hidden on the iOS K4iPad app has been murky and unpredictable, at best.

And, yes: that's what happens, along with a host of other, undefined, unexplained and inexplicable font weirdnesses at the KDP. That's why I'm a big believer in, no matter how fancy the layout LOOKS, keep the coding as simple as possible, even if it's more work. It's just wildly unpredictable in terms of what will work. We're at the point that if a book has fonts, we test-load it at the KDP to see the post-upload mobi--just to be sure.

Hitch