Help: missing embedded fonts after ePub3 transfer to Kindle

[Quoth]

Whatever about epub3 vs epub2 it's bogus to claim epub3 is needed to meet accessibility laws. That's my main point.

Also for regular fiction an epub3 conversion from docx adds nothing the epub2 doesn't do.

When there are many useful features to epub3 (maths being the most important) they lost sight of ebooks and have tried to make it compete with web pages and multimedia apps. Fixed layout was a nonsense as PDF does that and it's not a real ebook format as real ebooks need to reflow.

[JSWolf]

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

After looking at the ePub 3 code, it's very easy to make it work for both ePub 2 and ePub 3. But as it stands, this ePub is ePub 3 only as the formatting does not work with ePub 2. One of the stupidest things done with ePub 3 is to change things that did not need to be changed. ePub 3 should have been ePub 2 with additions. <figure> is a good example of useless code in ePub 3. <div> works just fine in place. <section> with a class is also not a good idea. Again, <div> works. hv and rem are also stupid stuff. You see the problem is going to be that you will sell your ePub 3 and when it doesn't work, people will stop buying your eBooks.

You can make your ePub 3 ePub 2 compatible and still keep with the new EU rules. But you have to do it. This is more important then embedded fonts that you don't actually need.

[KevinH]

"figure" and "figcaption" are actually wonderful changes as they semantically tell the accessbility e-reader so much more about the document structure than a generic "div" with a possible child "img" tag and possible following "p" tag for a caption. In addition, many epub3 layout engines already know to avoid page breaks when generating the page with figure and figcaption.

Since this thread should be about epub3 to kindle font losses and not epub2 vs epub3, I will stop there.

[Hitch]

Originally Posted by KevinH

"figure" and "figcaption" are actually wonderful changes as they semantically tell the accessbility e-reader so much more about the document structure than a generic "div" with a possible child "img" tag and possible following "p" tag for a caption. In addition, many epub3 layout engines already know to avoid page breaks when generating the page with figure and figcaption.

Since this thread should be about epub3 to kindle font losses and not epub2 vs epub3, I will stop there.

Kevin:

I, certainly, am not claiming that ePUB2 is somehow the end-all and be-all or that we require it for accessibility, etc. but the damned reality is that some vendors, for example, to this day, require ePUB2 to pass their intake. It's frustrating as s**t for those of us stuck in the commercial end of bookmaking. I wish that I could just say to the minions, "hey, gang, let's all switch up to ePUB3 and roll with that," when certain vendors--is it still Lulu, I think, amongst others?--won't accept ePUB3, or are using an ePUBcheck that's so damned old (yup, looking at you, again, Lulu), you can't get there from here. Those are distinct but related problems. I'd love to be able to just create ePUB3 with ePUB2 fallback, but it doesn't work that way. In that way, ironically, it's actually easier to do KDP than "One ePUB to Rule Them All."

For those who are privileged enough to do their own eBooks, or their own company's eBooks, huzzah. But not all of us can do that. Yes, sure, ePUB2 is on its way out--but slowly, slowly catchee monkey and this particular monkey is bloody geriatric and using a damned walker as it heads for the door.

I love fig and figcaption myself. I wish I could use them with impunity.

That's all I'm saying.

Hitch

[KevinH]

Hi Hitch, Understood and agree. If they do not accept epub3, then epub2 it must be.

[JSWolf]

Originally Posted by Hitch

Kevin:

I, certainly, am not claiming that ePUB2 is somehow the end-all and be-all or that we require it for accessibility, etc. but the damned reality is that some vendors, for example, to this day, require ePUB2 to pass their intake. It's frustrating as s**t for those of us stuck in the commercial end of bookmaking. I wish that I could just say to the minions, "hey, gang, let's all switch up to ePUB3 and roll with that," when certain vendors--is it still Lulu, I think, amongst others?--won't accept ePUB3, or are using an ePUBcheck that's so damned old (yup, looking at you, again, Lulu), you can't get there from here. Those are distinct but related problems. I'd love to be able to just create ePUB3 with ePUB2 fallback, but it doesn't work that way. In that way, ironically, it's actually easier to do KDP than "One ePUB to Rule Them All."

For those who are privileged enough to do their own eBooks, or their own company's eBooks, huzzah. But not all of us can do that. Yes, sure, ePUB2 is on its way out--but slowly, slowly catchee monkey and this particular monkey is bloody geriatric and using a damned walker as it heads for the door.

I love fig and figcaption myself. I wish I could use them with impunity.

That's all I'm saying.

Hitch

And don't forget software that doesn't understand ePub 3. Kobo won't display the sample ePub 3 properly because the version of RMSDK used is too old. And Kobo devices are not old. So you cannot say to forget old devices because not all new devices will work. And there are ways to deal with the ePub 3 so it works as ePub 3 with ePub 2 fallback.

Have a look at Android and how many "supposed" ePub readers won't work properly with this demo ePub.

In this demo, just do this...

<figure>
<div class="someclass">

In the CSS, there's no need for rem. use em. Forget hv and use % with height and width.

[Hitch]

Originally Posted by jhowell

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.

Amen, brother, amen.

I'm sorry, but that's just how it is. As I said above, upthread, we've been doing this 13 years and I have yet to see 25 fonts pass unmolested, pretty much. Now, granted, a) KDP has gotten significantly better, and b) given the problems we've seen, we no longer even try to do that many, in recent years, but still...I've seen this backfire more times than I'd like to say.

Fonts stripped completely; fonts substituted; we know for a fact that for years, there was an actual limit on calls to Arial, that you could use. No matter what you did--had it as a p style, or called it some other way, when you reached the limit, it would stop appearing.

Just...perhaps it's all solved, and now everything works as it "ought," but it didn't for at least a decade.

Hitch

[Nightjar]

Ok, thanks also to all your suggestions, I made a new set of tests and can confirm that the "mess" with the CSS code and the embedded font is caused ONLY by the transfer of the ePub3 file through SendtoKindle app/webpage or via email to the Kindle reader's own address.

Our ePub3 currently on sale on Amazon displays all the correct (custom) fonts with any substantial changes to the CSS. The ebook looks quite similar to the preview displayed by Kindle Previewer 3. But the only way we had to be 100% sure was to buy one copy of our own ebook from the Kindle store.

This means that there is apparently no way to sideload an ePub3 onto a Kindle device without risking major CSS changes being applied. I think the only way around is to convert the ePub3 to a .mobi+.azw3 package via Kindle Previewer 3.

Below is how the look of a page changes on 3 different systems:



So, right now I'm stuck at a crossroad: my previous ePub2 template does not comply with WCAG 2.0 AA accessibility requirements, and my recent ePub3 template isn't backward compatible with older ePub2-only reading devices and software.

Any suggestion on what is the best path to follow?

Thanks!

[Hitch]

Originally Posted by Nightjar

Ok, thanks also to all your suggestions, I made a new set of tests and can confirm that the "mess" with the CSS code and the embedded font is caused ONLY by the transfer of the ePub3 file through SendtoKindle app/webpage or via email to the Kindle reader's own address.

Our ePub3 currently on sale on Amazon displays all the correct (custom) fonts with any substantial changes to the CSS. The ebook looks quite similar to the preview displayed by Kindle Previewer 3. But the only way we had to be 100% sure was to buy one copy of our own ebook from the Kindle store.

This means that there is apparently no way to sideload an ePub3 onto a Kindle device without risking major CSS changes being applied. I think the only way around is to convert the ePub3 to a .mobi+.azw3 package via Kindle Previewer 3.

Below is how the look of a page changes on 3 different systems:



So, right now I'm stuck at a crossroad: my previous ePub2 template does not comply with WCAG 2.0 AA accessibility requirements, and my recent ePub3 template isn't backward compatible with older ePub2-only reading devices and software.

Any suggestion on what is the best path to follow?

Thanks!

Well, nobody hates to suggest this more than I, but what about simply making two ePUBs? One for ePUB2.x and one for ePUB3.x? The vendors that take each are pretty well delineated. Wouldn't that be easier than your gang trying to learn media queries based on devices, based on screen-sizes, etc.?

Hitch

[JSWolf]

Have you fixed the code so it works with ePub 2? If you do fix the code, then maybe it will work.

[Nightjar]

Originally Posted by Hitch

what about simply making two ePUBs? One for ePUB2.x and one for ePUB3.x?

This is a possibility, but it wouldn't have a long life. You know perfectly well the EU Accessibility Act, but here in Italy there is a new law based on it stating that as of June 28th, 2025 all new ebooks will have to comply with all those new requirements. So, in any case it would be better to make our ebooks 100% accessible from now on.

Originally Posted by JSWolf

Have you fixed the code so it works with ePub 2? If you do fix the code, then maybe it will work.

This is one of the two paths I have to choose. But I think that fixing the code won't be easy. In any case, the suggestions you posted will be hepful, thanks.

[jhowell]

Originally Posted by Nightjar

You know perfectly well the EU Accessibility Act, but here in Italy there is a new law based on it stating that as of June 28th, 2025 all new ebooks will have to comply with all those new requirements.

I wonder whether Amazon will need to stop selling Kindle books in Italy?

[Nightjar]

Originally Posted by jhowell

I wonder whether Amazon will need to stop selling Kindle books in Italy?

Ever since the ancient Romans, our lawmakers have been famous throughout the world for enacting laws that may be ahead of their time or simply absurd.

[JSWolf]

Originally Posted by Nightjar

This is a possibility, but it wouldn't have a long life. You know perfectly well the EU Accessibility Act, but here in Italy there is a new law based on it stating that as of June 28th, 2025 all new ebooks will have to comply with all those new requirements. So, in any case it would be better to make our ebooks 100% accessible from now on.

This is one of the two paths I have to choose. But I think that fixing the code won't be easy. In any case, the suggestions you posted will be hepful, thanks.

Looking at your sample, it would be very easy to fix it so it works with ePub 2.

[JSWolf]

Originally Posted by jhowell

I wonder whether Amazon will need to stop selling Kindle books in Italy?

It may not just be Amazon having to stop selling eBooks and/or Readers in Italy.