Help: missing embedded fonts after ePub3 transfer to Kindle

[jhowell]

Nightjar, my understanding is that you want to sell books that can be read on Kindle apps and devices (and on other platforms), but not through the Amazon store. So you are producing EPUBs that the customer can use with send-to-kindle for conversion and delivery. That seems reasonable to me.

You also say that a MOBI produced from your EPUB using Kindle Previewer (Amazon calls this a Master MOBI) will work correctly on Kindle devices when sideloaded. When the user selects Publisher Font then the fonts you added to the book are displayed. But when you use send-to-kindle with the same EPUB the resulting book still shows the Publisher Font option on the Kindle, but does not actually display the included fonts.

In order to diagnose this I suggest that you post an EPUB that demonstrates this problem, either a sample or a public domain book. Then I or others here can follow your procedure and analyze the resulting files produced to see what is different or missing. That may lead to an understanding of what is going wrong and possibly a solution.

[Hitch]

Originally Posted by jhowell

Nightjar, my understanding is that you want to sell books that can be read on Kindle apps and devices (and on other platforms), but not through the Amazon store. So you are producing EPUBs that the customer can use with send-to-kindle for conversion and delivery. That seems reasonable to me.

You also say that a MOBI produced from your EPUB using Kindle Previewer (Amazon calls this a Master MOBI) will work correctly on Kindle devices when sideloaded. When the user selects Publisher Font then the fonts you added to the book are displayed. But when you use send-to-kindle with the same EPUB the resulting book still shows the Publisher Font option on the Kindle, but does not actually display the included fonts.

In order to diagnose this I suggest that you post an EPUB that demonstrates this problem, either a sample or a public domain book. Then I or others here can follow your procedure and analyze the resulting files produced to see what is different or missing. That may lead to an understanding of what is going wrong and possibly a solution.

I agree, because we (my company) are not having this issue at all. We are building ePUBs that display the fonts exactly as they should, from ePUB, not from MOBI. Something is very hinky here, so if we could SEE a sample, it would be useful.

@Wolfie: arguing about the specs isn't helping anybody. The old KF7/KF8 crap is long gone now, mostly. Even if he agreed with you, it wouldn't solve his problem, so let's drop that, eh?

Hitch

[Nightjar]

Originally Posted by jhowell

In order to diagnose this I suggest that you post an EPUB that demonstrates this problem, either a sample or a public domain book. Then I or others here can follow your procedure and analyze the resulting files produced to see what is different or missing. That may lead to an understanding of what is going wrong and possibly a solution.

Originally Posted by Hitch

Something is very hinky here, so if we could SEE a sample, it would be useful.

Ok, after quite a long time I still haven't found a solution, so I have made a sample template based on the Epub3 standard template we created from scratch. It is 100% valid with both EPUBCheck 5.0.0 and Ace by DAISY. CSS3 is also valid, with the exception of a minor sets of hyphens warnings.
Our pre-publication tests usually include checking ebooks with:

* Adobe Digital Editions v.4.5.11
* Apple iPad
* Apple Books (macOS)
* Kindle Paperwhite 2022
* Kindle Fire HD 7"
* Samsung Galaxy Tab 3

This is the current situation:

ePub3 -> SendtoKindle -> Kindle reader: Publisher fonts missing (although the reader reports them as active)
ePub3 -> Sideload via USB -> Kindle reader (documents folder): File not recognized
KP3 generated mobi (.mobi+.azw3) -> SendtoKindle -> Kindle reader: Publisher fonts missing (although the reader reports them as active)
KP3 generated mobi (.mobi+.azw3) -> Sideload via USB -> Kindle reader: Publisher fonts OK

All other non-Kindle readers are working 100%, displaying content with the correct custom fonts.

It seems that the only way to get a Kindle reader recognize our custom fonts is to create a .mobi+.azw3 package through Kindle Previewer 3 and to upload this file via USB.

So, there seems to be no way to send an ePub3 file to any Kindle reader while retaining the custom fonts, as it seems they are being stripped out using SendtoKindle or the file can't be recognized if sideloaded.

Any help would be greatly appreciated. I enclose my sample ePub3 file.

Thanks!

[Hitch]

Originally Posted by Nightjar

Ok, after quite a long time I still haven't found a solution, so I have made a sample template based on the Epub3 standard template we created from scratch. It is 100% valid with both EPUBCheck 5.0.0 and Ace by DAISY. CSS3 is also valid, with the exception of a minor sets of hyphens warnings.
Our pre-publication tests usually include checking ebooks with:

* Adobe Digital Editions v.4.5.11
* Apple iPad
* Apple Books (macOS)
* Kindle Paperwhite 2022
* Kindle Fire HD 7"
* Samsung Galaxy Tab 3

This is the current situation:

ePub3 -> SendtoKindle -> Kindle reader: Publisher fonts missing (although the reader reports them as active)
ePub3 -> Sideload via USB -> Kindle reader (documents folder): File not recognized
KP3 generated mobi (.mobi+.azw3) -> SendtoKindle -> Kindle reader: Publisher fonts missing (although the reader reports them as active)
KP3 generated mobi (.mobi+.azw3) -> Sideload via USB -> Kindle reader: Publisher fonts OK

All other non-Kindle readers are working 100%, displaying content with the correct custom fonts.

It seems that the only way to get a Kindle reader recognize our custom fonts is to create a .mobi+.azw3 package through Kindle Previewer 3 and to upload this file via USB.

So, there seems to be no way to send an ePub3 file to any Kindle reader while retaining the custom fonts, as it seems they are being stripped out using SendtoKindle or the file can't be recognized if sideloaded.

Any help would be greatly appreciated. I enclose my sample ePub3 file.

Thanks!

Jesus wept! Do you really use all those fonts? IN the file? Every single one?

And, on an unrelated topic, why are you using that article CSS throughout? That's not meant for ongoing content; it's meant for independently distributable content, like...like an article or blog piece inside something else, that's being individually called out. You have it around every single paragraph? Or damn near all. Why?

(lastly, also, px does not work worth a damn, for indentation and margins, in Kindle ePubs, just so you know.)

DO let us know if you really use all those fonts, please. There is a reason I am asking.

Hitch

[Nightjar]

Originally Posted by Hitch

Do you really use all those fonts? IN the file? Every single one?

We only use 3 different fonts: 1 serif and 2 sans serif. And of course there are all the related variants (italic, bold, bold italic, and so on). Of course, if you count them all, the total is quite high, so we will probably get rid of the condensed sans serif versions, which will reduce the total number – and the total size – by more than 40%.
In any case, we have always used quite a wide variety of fonts since the publication of our very first ebook 11 years ago, and it has never been a problem to produce ePub2, Apple and Kindle ebooks.

Originally Posted by Hitch

why are you using that article CSS throughout? That's not meant for ongoing content; it's meant for independently distributable content, like...like an article or blog piece inside something else, that's being individually called out. You have it around every single paragraph? Or damn near all. Why?

We have some very specific typographical rules. For example, one of these states that the very first line of text after a blank line should not be indented, and our CSS programmer suggested to use the <article> tag to manage this kind of layout and maintain full compatibility with WCAG 2.0 AA accessibility requirements.

[JSWolf]

Originally Posted by Nightjar

Ok, after quite a long time I still haven't found a solution, so I have made a sample template based on the Epub3 standard template we created from scratch. It is 100% valid with both EPUBCheck 5.0.0 and Ace by DAISY. CSS3 is also valid, with the exception of a minor sets of hyphens warnings.
Our pre-publication tests usually include checking ebooks with:

* Adobe Digital Editions v.4.5.11
* Apple iPad
* Apple Books (macOS)
* Kindle Paperwhite 2022
* Kindle Fire HD 7"
* Samsung Galaxy Tab 3

This is the current situation:

ePub3 -> SendtoKindle -> Kindle reader: Publisher fonts missing (although the reader reports them as active)
ePub3 -> Sideload via USB -> Kindle reader (documents folder): File not recognized
KP3 generated mobi (.mobi+.azw3) -> SendtoKindle -> Kindle reader: Publisher fonts missing (although the reader reports them as active)
KP3 generated mobi (.mobi+.azw3) -> Sideload via USB -> Kindle reader: Publisher fonts OK

All other non-Kindle readers are working 100%, displaying content with the correct custom fonts.

It seems that the only way to get a Kindle reader recognize our custom fonts is to create a .mobi+.azw3 package through Kindle Previewer 3 and to upload this file via USB.

So, there seems to be no way to send an ePub3 file to any Kindle reader while retaining the custom fonts, as it seems they are being stripped out using SendtoKindle or the file can't be recognized if sideloaded.

Any help would be greatly appreciated. I enclose my sample ePub3 file.

Thanks!

Looking at your code, it really needs fixing. It's not ePub 2 compatible. The formatting is quote poor when viewed with a program that doesn't know ePub 3 such as ADE 2.0.1. So for any program that doesn't deal with ePub 3, this sample is not going to work well. It's going to work very poorly. Thinks you can do is fix the cover so it displays properly, fix the large image so it displays properly, do not use <figure> and use <div> instead so your class works. Also, don't use <sectio>n with a class, again, use <div>.

Don't use rem, use em. Don't use px. Use em. For width, don't use calc. Don't use justify-content, use text-align.Don't use display: flex;. Just get rid of it. don't use vh. Use %.

Download and install ADE 2.0.1 and use that to test your code as that version does not know ePub 3. That way you can see what your code does and doesn't do. For now, your code is no good for ePub 2 compatibility.

[Hitch]

Originally Posted by Nightjar

We only use 3 different fonts: 1 serif and 2 sans serif. And of course there are all the related variants (italic, bold, bold italic, and so on). Of course, if you count them all, the total is quite high, so we will probably get rid of the condensed sans serif versions, which will reduce the total number – and the total size – by more than 40%.
In any case, we have always used quite a wide variety of fonts since the publication of our very first ebook 11 years ago, and it has never been a problem to produce ePub2, Apple and Kindle ebooks.

With 28 fonts, you've never had a problem with Kindle showing and displaying those fonts? hHnestly, I find that exceedingly hard to believe. Kindle renderers have been acutely sensitive to more than a few fonts--I'd say, 10 at the absolute outside--for years now. In fact, typically, if we submitted that many fonts, ALL the fonts would be removed--ripped out entirely--and I've seen that more than once. You're saying you routinely submit 25-ish fonts and that's never happened?

We have some very specific typographical rules. For example, one of these states that the very first line of text after a blank line should not be indented, and our CSS programmer suggested to use the <article> tag to manage this kind of layout and maintain full compatibility with WCAG 2.0 AA accessibility requirements.

Right--we use the same typographic rules. What's that got to do with using article? Why not just use a regular CSS call? There's nothing that indicates that article should be used for your purpose; it's literally meant to identify something unique, something that should be extracted and read by itself--not the next paragraph-in-sequence. Seriously, look it up if you don't believe me.

Hitch

[Nightjar]

Originally Posted by Hitch

With 28 fonts, you've never had a problem with Kindle showing and displaying those fonts? hHnestly, I find that exceedingly hard to believe. Kindle renderers have been acutely sensitive to more than a few fonts--I'd say, 10 at the absolute outside--for years now. In fact, typically, if we submitted that many fonts, ALL the fonts would be removed--ripped out entirely--and I've seen that more than once. You're saying you routinely submit 25-ish fonts and that's never happened?

Nope. I said right from the start that we created a new ePub3 version from scratch. And this came after having successfully published ePub2+mobi versions for more than a decade. If you want to know the average number of fonts we used, I can say that on average we used 12 font files with no problems at all on Kindle readers.

I was looking for an answer just to understand why when I create a mobi+azw3 package using Kindle Previewer 3 to convert my ePub3 file, the ebook does look perfect on any Kindle reader. However, when I send the very same ePub3 file using SendtoKindle or email to the Kindle reader address, the results are horrible, with missing fonts and other CSS flaws that ARE NOT PRESENT on the mobi/azw file converted from the very same ePub3 source.

This means that something is getting modified or stripped out by Amazon in the process. But you all know that Amazon is dismissing mobi/azw file loading, so I'm back to square one.

[JSWolf]

Originally Posted by Nightjar

Nope. I said right from the start that we created a new ePub3 version from scratch. And this came after having successfully published ePub2+mobi versions for more than a decade. If you want to know the average number of fonts we used, I can say that on average we used 12 font files with no problems at all on Kindle readers.

I was looking for an answer just to understand why when I create a mobi+azw3 package using Kindle Previewer 3 to convert my ePub3 file, the ebook does look perfect on any Kindle reader. However, when I send the very same ePub3 file using SendtoKindle or email to the Kindle reader address, the results are horrible, with missing fonts and other CSS flaws that ARE NOT PRESENT on the mobi/azw file converted from the very same ePub3 source.

This means that something is getting modified or stripped out by Amazon in the process. But you all know that Amazon is dismissing mobi/azw file loading, so I'm back to square one.

When you finish your ePub, subset the fonts and you'll see which ones can be deleted because they are not used.

Also, are you going to fix the code so it works properly with both ePub 2 and ePub 3?

[Hitch]

Originally Posted by Nightjar

Nope. I said right from the start that we created a new ePub3 version from scratch. And this came after having successfully published ePub2+mobi versions for more than a decade. If you want to know the average number of fonts we used, I can say that on average we used 12 font files with no problems at all on Kindle readers.

I was looking for an answer just to understand why when I create a mobi+azw3 package using Kindle Previewer 3 to convert my ePub3 file, the ebook does look perfect on any Kindle reader. However, when I send the very same ePub3 file using SendtoKindle or email to the Kindle reader address, the results are horrible, with missing fonts and other CSS flaws that ARE NOT PRESENT on the mobi/azw file converted from the very same ePub3 source.

This means that something is getting modified or stripped out by Amazon in the process. But you all know that Amazon is dismissing mobi/azw file loading, so I'm back to square one.

Yes, but we've used ePUB2 for mobi-building since...IDK, 2013, I think and we've still run into massive issues with that many fonts. I don't know if you're embedding fonts that you don't actually call--that could easily be it--or what, but I've seen the font-stripping thing more than a few times and we counsel our customers now to keep the font overload to a minimum. (and of course, for design reasons, it's best anyway.)

Amazon is dismissing email-to-kindle MOBI loading, certainly. Given that they are still supporting MOBI for FXL, I would suspect that until that's changed, sideloading a mobi will still be viable.

I still have NO idea why your CSS consultant or whatever he is made that recommendation to you. Seriously.

I would point out that as vexatious as Jon (Wolfie) can be, he's not wrong about ePUB2 backwards compatibility for the non-Amazon vendors. FWIW. Probably still a LOT more ePUB2-reading devices in the wild out there than there are ePUB3.0. if that code is indicative of your ePUB-vendor offering. I know, that's not what you asked--but he's not wrong.

Hitch

[Nightjar]

Hitch and JSWolf thank you for your advice, even if it does not solve my problem.

Probably like many non-European members of this forum, you are not aware of the so-called European Accessibility Act.

We started making a template in ePub3 format not just as an experiment, but because within about two years all European publishers and retailers will be obliged to sell only and exclusively ebooks that are fully accessible. And this means creating new ebooks and updating already published ones that perfectly follow the accessibility standards of ePub3 and WCAG 2.0.

Thus, from June 2025 maintaining compatibility with ePub2 reading devices will be totally out of the question, not because it is not technically possible, but because the law will impose the sale exclusively of ebooks in ePub3 format.

The European Accessibility Act – how does it impact publishers?

So I hope you can put yourself in the shoes of a small publisher like yours truly, who is already starting to go crazy to make his catalogue compatible with the incoming European Accessibility Act.

Thanks anyway

[Hitch]

Originally Posted by Nightjar

Hitch and JSWolf thank you for your advice, even if it does not solve my problem.

Probably like many non-European members of this forum, you are not aware of the so-called European Accessibility Act.

We started making a template in ePub3 format not just as an experiment, but because within about two years all European publishers and retailers will be obliged to sell only and exclusively ebooks that are fully accessible. And this means creating new ebooks and updating already published ones that perfectly follow the accessibility standards of ePub3 and WCAG 2.0.

Thus, from June 2025 maintaining compatibility with ePub2 reading devices will be totally out of the question, not because it is not technically possible, but because the law will impose the sale exclusively of ebooks in ePub3 format.

The European Accessibility Act – how does it impact publishers?

So I hope you can put yourself in the shoes of a small publisher like yours truly, who is already starting to go crazy to make his catalogue compatible with the incoming European Accessibility Act.

Thanks anyway

I'm surprised that you think that I have no EU customers, and am somehow blithely unaware of the Accessibility Act. In fact, that's why I find the "article" CSS so surprising, but hey....

WHEN I have time this weekend, assuming I have any, I will take another look at this file, but speaking bluntly, I think it's simply that you are using the Mail-to-Kindle, which has been notoriously 2-3 steps behind, rendering-wise, for at least 10 years. It wasn't that long ago that it was still rendering KF7, and if you are sending MOBI to it, it may yet be, compared to emailing the ePUB. Have you tried emailing the ePUB?

Hitch

[jhowell]

Originally Posted by Nightjar

Ok, after quite a long time I still haven't found a solution, so I have made a sample template based on the Epub3 standard template we created from scratch. It is 100% valid with both EPUBCheck 5.0.0 and Ace by DAISY. CSS3 is also valid, with the exception of a minor sets of hyphens warnings.
...
Any help would be greatly appreciated. I enclose my sample ePub3 file.

I downloaded your EPUB and was able to confirm that sending it to a Kindle device as a personal document using send-to-kindle results in significantly different rendering when compared with sideloading a Master MOBI file produced from it using the Kindle Previewer.

I copied the AZW3/KF8 send-to-kindle file from my Kindle and compared it to the Master MOBI and the original EPUB using calibre's editor. The CSS in the Master MOBI file produced using the Kindle Previewer is almost identical to the original EPUB. However there are several changes to the CSS in the send-to-kindle file. Most of the call outs to the embedded fonts have been stripped.

Amazon does not adhere to industry standards. They only provide vague "guidelines" on how source files should be formatted for Kindle e-books.

Amazon's publishing process is picky about what it allows for embedded publisher fonts. And unfortunately the rules are undocumented. Experienced book formatters have learned what to use and what to avoid by trial and error. The best advice I have seen is to keep things as simple as possible.

The current version of the Kindle Previewer performs only a subset of the processing that is done when a book is published on Amazon. And it used to be that personal documents converted by Amazon using send-to-kindle were also minimally processed.

That changed recently. It appears that with the introduction of the Kindle Scribe Amazon has revamped the send-to-kindle pipeline to be much closer to what published books go through. That allows the Scribe to use Amazon's newer KFX format for personal documents. (It is necessary because the Scribe's annotation features all rely on KFX.) Unfortunately for you it means that more restrictions now apply.

[Quoth]

Originally Posted by Nightjar

Thus, from June 2025 maintaining compatibility with ePub2 reading devices will be totally out of the question, not because it is not technically possible, but because the law will impose the sale exclusively of ebooks in ePub3 format.

The European Accessibility Act – how does it impact publishers?

This is totally misrepresenting the act and that article and the vast majority of ereaders and apps for epub used by readers will still only do a subset of epub3, if any of it.

Epub2 can meet the needs of the act anyway.

Also Amazon has over 90% of English Language ebook market.

[KevinH]

As I have tried to point out previously many times, epub2 is on its way out and rightly so given its limitations for many languages. Just because epub2 is good enough for english basic fiction does not make it a good choice. Furthermore an e-reader need not support all of epub3 to be useful (javascript support is not mandatory for example). Many epub3 e-readers are using webkit derived browser engines that support just about everything.

That said making an epub3 backwards compatible with epub2 only e-readers (for basic fiction) does not in any way prevent or preclude meeting Accessibility standards. You can easily do both with epub3.

IMHO, we should not be promoting the continued use of epub2 when more accessible epub3s can be made that can be made to be backwards compatible (for basic fiction) with ancient epub2 only e-readers, Amazon conversion, and etc.