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

[Jellby]

Originally Posted by Hitch

Although: again, as I've said before, who would be full of righteous indignation if a print book used Georgia, say, instead of Garamond, or vice-versa? NO ONE.

I would have some indignation at least if I found a printed book with poor kerning, missing ligatures (like "fi" being a ligature but not "fj"), or different font for some characters (why does "à" look thicker than "a"?). I'd mostly think the publisher is rather crappy and wish it was an e-book so I can fix it.

What would cause me more indignation is finding these problems in an e-book with an embedded font. They should have left the embedded font out and let me chose the right one.

[Hitch]

Originally Posted by Jellby

I would have some indignation at least if I found a printed book with poor kerning, missing ligatures (like "fi" being a ligature but not "fj"), or different font for some characters (why does "à" look thicker than "a"?). I'd mostly think the publisher is rather crappy and wish it was an e-book so I can fix it.

What would cause me more indignation is finding these problems in an e-book with an embedded font. They should have left the embedded font out and let me chose the right one.

Yes, Jellby, of course.

On the other hand, as we all know, kerning in ebooks is an entirely different kettle of fish, AND, to top it off, most layout houses now barely kern, or kern automatically--not by hand!--and hope for the best.

It's extremely like the new mindset that "AAAAHHH!!! Typos MUST be fixed RIGHT. THIS. SECOND!," as if the reader's head will explode if the author doesn't rapidly fix his book and reupload it at the KDP, et al. It's absurdity. It's a paradigm shift from a mere 10 years ago, and it serves NO ONE well. I've ranted about this here before. It encourages bad writers to continue writing ("oh, well, I can always fix it and upload a new book") and has turned readers--who should be able to buy a book with a reasonable expectation that it's been edited and proofed--into unpaid proofers for mediocre writers and bad publishers.

There are, like it or not, good reasons for some uses of fonts.

Hitch

[JSWolf]

Speaking of embedded fonts, what would be the best way to get the reader (not the device, but the person) to know to turn on the publisher font on a Kindle? I'm thinking a note that says something like "This eBook contains embedded fonts, please turn on publisher fonts if your device has such an option.".

[Hitch]

Originally Posted by JSWolf

Speaking of embedded fonts, what would be the best way to get the reader (not the device, but the person) to know to turn on the publisher font on a Kindle? I'm thinking a note that says something like "This eBook contains embedded fonts, please turn on publisher fonts if your device has such an option.".

Jon:

That's exactly our recommendation. In fact, were I an author, (of things other than ninety-bajillion posts in a forum full of my peeps), I'd have the SRL (text) location open to JUST that page "Howdy, this book was laid out for your enjoyment at X. If you'd like to see X, please turn on Publisher Fonts. If not, we respect your choice to view the book as you best see fit."

Otherwise, it's an uphill battle. I had someone (this was pretty riotous, in hindsight), belligerently tell me on another "forum" that I was full of it, we didn't embed fonts, yadda-yadda, (this is another "professional bookmaker," mind you, who learned 90% of what he knows from me, the irony of which is not lost upon me), and so on and so forth. Right up to the point I realized that this moron didn't know to turn on publisher fonts. AHEM.

Just for the sake of pointing out the reality of using fonts: attached find a book that was done in FF, for iBooks, and then in reflowable for other vendors. With fonts. (Museum client). Just for fun. :-)

Hitch

[JSWolf]

Originally Posted by Hitch

Jon:

That's exactly our recommendation. In fact, were I an author, (of things other than ninety-bajillion posts in a forum full of my peeps), I'd have the SRL (text) location open to JUST that page "Howdy, this book was laid out for your enjoyment at X. If you'd like to see X, please turn on Publisher Fonts. If not, we respect your choice to view the book as you best see fit."

That's a good idea to have the eBook open at the place that tells readers to turn in the fonts. I'm not 100% sure, but you might also have to do with with Kobo Readers. I'm not sure yet until I get one in November.

Otherwise, it's an uphill battle. I had someone (this was pretty riotous, in hindsight), belligerently tell me on another "forum" that I was full of it, we didn't embed fonts, yadda-yadda, (this is another "professional bookmaker," mind you, who learned 90% of what he knows from me, the irony of which is not lost upon me), and so on and so forth. Right up to the point I realized that this moron didn't know to turn on publisher fonts. AHEM.

Gotta love the idiots who think they know it all and that one piece of information they don't know is what screws them up big time.

Just for the sake of pointing out the reality of using fonts: attached find a book that was done in FF, for iBooks, and then in reflowable for other vendors. With fonts. (Museum client). Just for fun. :-)

Very nice! iBooks can have some very nice looking eBooks if you don't mind that it won't look the same in any other program. The non-iBooks versions are well done too considering you cannot get the exact same look.

[Hitch]

Originally Posted by JSWolf

That's a good idea to have the eBook open at the place that tells readers to turn in the fonts. I'm not 100% sure, but you might also have to do with with Kobo Readers. I'm not sure yet until I get one in November.

I'll ask Barb, here in the office. She's our resident Kobo expert. (n.b.: she's not actually "in" the office right HERE. She's in our Toronto office. Yup, that's us, an International Megalopoly.)

Gotta love the idiots who think they know it all and that one piece of information they don't know is what screws them up big time.

That "guy" is really vicious. I seriously don't know what's wrong with him. I wrote to ECR and told them that I was done posting at those forums, because a) I'd lived up to what they'd asked--that I post helpful tidbits, 4 years ago, and b) that guy is loony. And a bit scary, were I the kind of person who gets scared in that sense. He posted this incredibly long thread, full of images of "how great Jutoh is," with this ranting diatribe about how BAD Sigil is and how "real" ebookmakers don't use it, etc. He also called me a liar for saying we make books in code, and that only "idiots and liars" do that. I mean, it was beyond vitriolic. I don't get it: what does HE care about how we make books? if we're losing money, because I'm "an idiot" to code in HTML by hand, why should he care? Anyway, enough of that s**t, really. The net is just a barrel full of insane monkeys.

Very nice! iBooks can have some very nice looking eBooks if you don't mind that it won't look the same in any other program. The non-iBooks versions are well done too considering you cannot get the exact same look.

Well, Jon, that's quite decent of you. ;-) I'm rather proud of those, (the reflowable ones at Amazon and Nook, et al), although from a technological standpoint, we've done far harder. But those are quite pretty and more importantly, the client was DELIGHTED. (Always good!). There is probably code in them that would make my eye do the eyebrow-up-scrunched-other-eye thing, if I looked closely at them again, but...

Curiously enough, crappy marketer that I am, I don't even have those screenshots up on our Samples page. {sigh}.

Hitch

[dgatwood]

Originally Posted by JSWolf

Speaking of embedded fonts, what would be the best way to get the reader (not the device, but the person) to know to turn on the publisher font on a Kindle? I'm thinking a note that says something like "This eBook contains embedded fonts, please turn on publisher fonts if your device has such an option.".

I did that on my books, but I took it one step farther. I created a special font called "blankfont":

https://www.gatwood.net/fonts/BlankF...nt-Regular.otf

that is exactly what the name implies: a blank font. On my fonts page, I have the following code:

PHP Code:

span.hidden {
        font-family: "BlankFont";
        font-style: normal;
        font-weight: normal;
        color: red;
}

...

<p>... <span class="hidden"><span class="insidehidden">*** If you
can see this text, your reader is overriding the default
font. *** </span></span> ... </p> 


If memory serves, the inner span's bogus "insidehidden" class with no font declaration is deliberate, as it tickles certain bugs in certain readers, encouraging readers whose font override functionality is buggy to fall back to the paragraph font when they otherwise would not.

On readers that handle fonts correctly, the entire "hidden" span collapses into a zero-width inline element. On readers that abusively override the font selection, it shows up as red text in the reader's default paragraph font.

Note that this approach is entirely compatible with well-behaved readers that change only the body tag's font, because a reader stylesheet that overrides the font on the body tag (and only the body tag) won't cause that hidden text to appear. However, if you really need to force the body text to a particular font, declare a paragraph style with a font choice and !important. Then, odds are good that any reader that overrides the paragraph font will also get tripped up by the canary above, and any reader that doesn't won't be.

[Hitch]

Originally Posted by dgatwood

I did that on my books, but I took it one step farther. I created a special font called "blankfont":

<snippage>

If memory serves, the inner span's bogus "insidehidden" class with no font declaration is deliberate, as it tickles certain bugs in certain readers, encouraging readers whose font override functionality is buggy to fall back to the paragraph font when they otherwise would not.

On readers that handle fonts correctly, the entire "hidden" span collapses into a zero-width inline element. On readers that abusively override the font selection, it shows up as red text in the reader's default paragraph font.

Note that this approach is entirely compatible with well-behaved readers that change only the body tag's font, because a reader stylesheet that overrides the font on the body tag (and only the body tag) won't cause that hidden text to appear. However, if you really need to force the body text to a particular font, declare a paragraph style with a font choice and !important. Then, odds are good that any reader that overrides the paragraph font will also get tripped up by the canary above, and any reader that doesn't won't be.

That, my friend, is very, very clever. Well done, that!

Hitch

[JSWolf]

Originally Posted by dgatwood

I did that on my books, but I took it one step farther. I created a special font called "blankfont":
<see original message for the bit snipped out>

If memory serves, the inner span's bogus "insidehidden" class with no font declaration is deliberate, as it tickles certain bugs in certain readers, encouraging readers whose font override functionality is buggy to fall back to the paragraph font when they otherwise would not.

On readers that handle fonts correctly, the entire "hidden" span collapses into a zero-width inline element. On readers that abusively override the font selection, it shows up as red text in the reader's default paragraph font.

Note that this approach is entirely compatible with well-behaved readers that change only the body tag's font, because a reader stylesheet that overrides the font on the body tag (and only the body tag) won't cause that hidden text to appear. However, if you really need to force the body text to a particular font, declare a paragraph style with a font choice and !important. Then, odds are good that any reader that overrides the paragraph font will also get tripped up by the canary above, and any reader that doesn't won't be.

That is brilliant! I'll have to try it.

[Tony_A20]

Hello Quiris,

Thanks for posting the KDP Team status update (however cryptic).

Although I’m not exactly sure what the writer means by the use of “*” this is what I understand:

Two HTML documents were tested each with the same content, but with different styling declarations.

The document contents were:

<h1>test</h1>
<p>test</p>

The first document (20), had the style p {font-family: “Lobster 1.4”;}

The second document (21) had the style p, h1 {font-family: “Lobster 1.4”;}

When the first document (20) was parsed by the KDP upload software, the Lobster font used for the paragraph tag was considered more significant than the default font used for the heading tag, and consequently was considered applicable to the complete document body.

Apparently , because the heading tag used a default style rather than the style assigned to the document body, it caused an error situation and a KDP software error handling routine disallowed and removed the conflicting font from the document.

When the second document (21) was examined by the KDP upload software, the Lobster font was again assigned as a document-wide parameter.

In this document, because there was no difference in font use between the tagged text and the body parameter, no program editing error occured, the error trap did not execute, and the font was included in the document.

If my understanding is correct, there are three separate errors in the KDP upload software:


1. The algorithm used to determine font use and applicability is logically incorrect.
2. The arbitrary application of a partictular font to the whole document thereby essentially negates any default expectations and cause an error condition.
3. The error handling solution to the problem caused by 2. is incorrect.

Conclusion: poor system analysis, poor design, poor programming.

Solution: none proposed by the KDP Team.

A shot-in-the-dark work-around for us poor users:

Choose and list all used fonts in the body tag leaving no default text.
Assign a separate style selector classification for each type of font use.
Complain like hell to KDP.

Is my understanding correct; is the work-around nonsense?

Tony

[JSWolf]

Originally Posted by Hitch

I'll ask Barb, here in the office. She's our resident Kobo expert. (n.b.: she's not actually "in" the office right HERE. She's in our Toronto office. Yup, that's us, an International Megalopoly.)

Thanks. It'll be a while before I could check for myself.

That "guy" is really vicious. I seriously don't know what's wrong with him. I wrote to ECR and told them that I was done posting at those forums, because a) I'd lived up to what they'd asked--that I post helpful tidbits, 4 years ago, and b) that guy is loony. And a bit scary, were I the kind of person who gets scared in that sense. He posted this incredibly long thread, full of images of "how great Jutoh is," with this ranting diatribe about how BAD Sigil is and how "real" ebookmakers don't use it, etc. He also called me a liar for saying we make books in code, and that only "idiots and liars" do that. I mean, it was beyond vitriolic. I don't get it: what does HE care about how we make books? if we're losing money, because I'm "an idiot" to code in HTML by hand, why should he care? Anyway, enough of that s**t, really. The net is just a barrel full of insane monkeys.

I would 100% stay away from him. He sounds insane. To be honest, it doesn't matter how eBooks are made as long as the code is neat and the formatting is good.

Well, Jon, that's quite decent of you. ;-) I'm rather proud of those, (the reflowable ones at Amazon and Nook, et al), although from a technological standpoint, we've done far harder. But those are quite pretty and more importantly, the client was DELIGHTED. (Always good!). There is probably code in them that would make my eye do the eyebrow-up-scrunched-other-eye thing, if I looked closely at them again, but...

All three versions look good. You do change how you do things (for the better) but when you did them back then, you still got them to look good. I have eBooks I've modified that I'd look at now and cringe. The formatting is fine. The code, not as fine.

Curiously enough, crappy marketer that I am, I don't even have those screenshots up on our Samples page. {sigh}.

Hitch

So get them up on your spiffy new website. They should be there to showcase what you can do with the same book on different platforms.

[JSWolf]

Originally Posted by dgatwood

On readers that handle fonts correctly, the entire "hidden" span collapses into a zero-width inline element. On readers that abusively override the font selection, it shows up as red text in the reader's default paragraph font.

Note that this approach is entirely compatible with well-behaved readers that change only the body tag's font, because a reader stylesheet that overrides the font on the body tag (and only the body tag) won't cause that hidden text to appear. However, if you really need to force the body text to a particular font, declare a paragraph style with a font choice and !important. Then, odds are good that any reader that overrides the paragraph font will also get tripped up by the canary above, and any reader that doesn't won't be.

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.

[HarryT]

Originally Posted by JSWolf

Speaking of embedded fonts, what would be the best way to get the reader (not the device, but the person) to know to turn on the publisher font on a Kindle? I'm thinking a note that says something like "This eBook contains embedded fonts, please turn on publisher fonts if your device has such an option.".

This is precisely what many Kindle books that contain embedded fonts do.

[Tony_A20]

Hello Hitch,
Just wanted to let you know your assistance has really helped.

I have been successful in getting two fonts embedded and working in HTML and even built into a .mobi file using Kindlegen that appears okay on Kindle for PC.

I still have problems applying indents and other classes to the embedded fonts in HTML. Doubling up on classes (class="embeddedfont indent") kills the embedded font, and applying additional styling classes to a <span> tag (as you did in your example) does nothing. I'm disappointed that applying <div class="embeddedfont> doesn't apply the font to the whole division so that other styling classes can be attached to subordinate tags.

Do you have any advice?

Tony

[Hitch]

Originally Posted by Tony_A20

Hello Hitch,
Just wanted to let you know your assistance has really helped.

I have been successful in getting two fonts embedded and working in HTML and even built into a .mobi file using Kindlegen that appears okay on Kindle for PC.

I still have problems applying indents and other classes to the embedded fonts in HTML. Doubling up on classes (class="embeddedfont indent") kills the embedded font, and applying additional styling classes to a <span> tag (as you did in your example) does nothing. I'm disappointed that applying <div class="embeddedfont> doesn't apply the font to the whole division so that other styling classes can be attached to subordinate tags.

Do you have any advice?

Tony

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