kdp / azw3 / calibre / mobi

[joe 1]

I've done a bit of searching on this but as yet have not found an answer. Hoping someone here can help me.

I'm working on a textbook that I created in LibreOffice, and I want to publish it for Kindle. I originally tried LO's epub output but that created a mess.

I attempted to use Kindle Create but it choked when opening the file.

I then imported my book into calibre and I was able to manually fix the problems in the generated html. I generated an epub from calibre and uploaded it to KDP. In the online previewer, it looks great -- no problems at all. But then I downloaded the mobi from KDP and emailed it to my Kindle account so I could open it in the Kindle app on my iPhone. I found that it looked very different from the online preview -- fonts and tables were wrong.

For fun, I tried converting my epub to mobi using kindlegen, and got the same result as through kdp -- incorrect fonts and tables. Strangely, calibre did a better job generating a mobi than kindlegen; the fonts were correct but the tables were still wrong.

I could manually tweak the html so that the tables look a little better, but still not as good as the KDP online previewer.

I think what's happening is that KDP is converting my epub into a dual azw3/mobi. The online preview is showing the azw3 version but I can only download the mobi.

So I can either: a) upload my epub -- newer Kindle devices will get the azw3 and display correctly, while older devices will get the mobi version and will look horrible, or b) fix the mobi as best I can and upload that -- it will not look great on any device but not horrible either.

Am I correct about my options? Is there anything else I can do to tweak the mobi version without sacrificing the azw3 version?

[jhowell]

Originally Posted by joe 1

But then I downloaded the mobi from KDP and emailed it to my Kindle account so I could open it in the Kindle app on my iPhone. I found that it looked very different from the online preview -- fonts and tables were wrong.

The file that you download from KDP is a Master-MOBI, containing both the old MOBI7 and newer KF8 (azw3) formats in one file.

The Kindle for iOS app does not support KF8, so what you will see on that device for a personal document emailed to your account is the MOBI7 version with limited formatting. That is what owners of older Kindle devices who purchase your book will see.

Install Amazon's Kindle Previewer (PC or Mac) if you want a better look at how your book will appear to most customers.

[Notjohn]

I use the website Word2CleanHtml dot Com to get rid of all excess html from Word docs. Then I open a new epub2 in Sigil and simply paste the clean html between the opening and closing body tags. All paragraphs are retained, and all italics and boldfacing. Headings are mere boldface, but those are easily converted to the appropriate heading, and the chapters separated after a link has been added to my stock style sheet.

Out of curiosity, I tried the same routine on an OpenOffice Writer document, saved as a doc file, and it worked fine except that instead of a plain-vanilla paragraph tag it yielded a p class="normal" tag, which I change to plain vanilla with a quick search & replace.

I assume the same would happen with a LibreOffice document. No need to involve Calibre with its idiosyncratic styles. Sigil saves as epub, of course, and a validated epub has always converted flawlessly for me on the KDP platform.

[joe 1]

Originally Posted by jhowell

The file that you download from KDP is a Master-MOBI, containing both the old MOBI7 and newer KF8 (azw3) formats in one file.

The Kindle for iOS app does not support KF8, so what you will see on that device for a personal document emailed to your account is the MOBI7 version with limited formatting. That is what owners of older Kindle devices who purchase your book will see.

Install Amazon's Kindle Previewer (PC or Mac) if you want a better look at how your book will appear to most customers.

Thank you -- that's very helpful. I didn't realize the downloaded mobi contained both formats. When I opened it with Kindle Previewer, it looked perfect.

But do I have any control over the mobi format that's included? That is, can I upload a combined azw3 and mobi, and not let kdp do the mobi conversion?

[jhowell]

Originally Posted by joe 1

But do I have any control over the mobi format that's included? That is, can I upload a combined azw3 and mobi, and not let kdp do the mobi conversion?

You can upload a Master-MOBI produced by Kindle Previewer or kindlegen instead of uploading an EPUB, but that will be the same as what KDP produces from your uploaded EPUB.

If you are talking about a combined file produced by calibre (MOBI-both format) I recommend against doing that. Calibre's files are good enough for readers, but they lack some of the internal components needed for a properly published book on Amazon.

---

I will add that your book will be converted to a variety of Kindle formats by Amazon and be available on old and new devices. I would strive to make it look good on the latest apps/devices that support the most advanced format (KFX-Enhanced Typesetting) and have it be at least readable on older devices and formats (MOBI7 and KF8).

[joe 1]

Originally Posted by jhowell

You can upload a Master-MOBI produced by Kindle Previewer or kindlegen instead of uploading an EPUB, but that will be the same as what KDP produces from your uploaded EPUB.

Ok, that makes sense. So using Previewer/Kindlegen, I can't manually tweak the HTML that's used for the MOBI format only, right?

My problem is that I have tables with borders. In Previewer they look great, but in the MOBI format there are no borders. I can "force" them to display by adding "border=1" to all of the TABLE elements; that looks a little better in MOBI but screws up the display in KF8 format. I was hoping for a way to add the "border=1" to tables for only the MOBI format.

I discovered the @media amzn-kf8 conditional expression which would do what I need, but it works with css only and not inline HTML properties.

If I can't get it to work, I will just leave it as-is... I agree with you that I'm better off supporting newer formats at the expense of older formats.

[jhowell]

Originally Posted by joe 1

My problem is that I have tables with borders. In Previewer they look great, but in the MOBI format there are no borders. I can "force" them to display by adding "border=1" to all of the TABLE elements; that looks a little better in MOBI but screws up the display in KF8 format. I was hoping for a way to add the "border=1" to tables for only the MOBI format.

Some CSS styles are converted to HTML3 equivalents in kindlegen for MOBI7 format. For example the style border:solid; becomes the border="1" attribute. Media queries @media amzn-kf8 and @media amzn-mobi can be used to target CSS to a particular format. By combining these you can have borders in one format and not another.

Others here have a lot more experience in this area, hopefully some of them will chime in with more details.

[hobnail]

Originally Posted by jhowell

Some CSS styles are converted to HTML3 equivalents in kindlegen for MOBI7 format. For example the style border:solid; becomes the border="1" attribute. Media queries @media amzn-kf8 and @media amzn-mobi can be used to target CSS to a particular format. By combining these you can have borders in one format and not another.

Isn't the HTML in the MOBI7 that's in a master MOBI/dual MOBI essentially the old HTML we had before there was CSS (HTML4)? That's what I think you're implying but perhaps it could be more explicitly stated.

[jhowell]

Originally Posted by hobnail

Isn't the HTML in the MOBI7 that's in a master MOBI/dual MOBI essentially the old HTML we had before there was CSS (HTML4)?

MOBI7 supports a subset of HTML3. The old Mobipocket documentation listed the tags and attributes supported. It was taken down, but is available via the Internet Archive.

Kindlegen converts a subset of the CSS in the source file to the equivalent HTML3 markup supported by MOBI7 format. I do not know of any documentation of which CSS features are supported by that conversion.

[JSWolf]

The problem is that while you can do more advanced formatting with KF8, Mobi is a limiting factor since your eBook also have to work on obsolete devices that only support Mobi. For most books this is not an issue. But for some, it is. This is why I think Amazon should allow eBooks to be KF8 only and not support Mobi where that's not feasible.

[stumped]

tables are a bad idea, generally, for reflowable books
what looks great on one test device can look awful or be cropped on other different sized devices.

if the whole table width will not fit on a users' screen with their preferred font size, then the renderer is probably going to crop some of the text

[JSWolf]

Originally Posted by stumped

tables are a bad idea, generally, for reflowable books
what looks great on one test device can look awful or be cropped on other different sized devices.

if the whole table width will not fit on a users' screen with their preferred font size, then the renderer is probably going to crop some of the text

Or wrap the text and make it look not good.

[stumped]

from experience, I have had books where text was cropped off. the last one was a library loan & by a big name author, so professionally formatted ???

using an editor to see the code, to find out why, revealed that it was using a ( unnecessary) table around the preamble to each chapter. long preambles were being cut off when rendered

its more common with game strategy guides which use table cells to describe attributes/ spell properties, armor properties.....
A lazy author may have lifted much of that from web sites with little or no tidying. Those table rows are more likely to get side cropped, or as you say, wrapped into a messy presentation

[jhowell]

Originally Posted by JSWolf

The problem is that while you can do more advanced formatting with KF8, Mobi is a limiting factor since your eBook also have to work on obsolete devices that only support Mobi. For most books this is not an issue. But for some, it is. This is why I think Amazon should allow eBooks to be KF8 only and not support Mobi where that's not feasible.

I doubt that MOBI7 will be going away any time soon. Publishers need to make the best of the current situation.

Besides the older Kindle devices that only support it, MOBI7 is also used as the basis for the primary format in Amazon's Kindle Cloud Reader (read.amazon.com) and as the fallback format in reflowable books produced using Amazon's Kindle Create publishing tool.

The discussion in this thread so far has been about tables. Previous threads on this topic have focused on the differences in how images are displayed between MOBI7 and KF8 and how to adapt books to have them display as nicely as possible in both formats. That is often a bigger concern for publishers.

Originally Posted by stumped

tables are a bad idea, generally, for reflowable books
what looks great on one test device can look awful or be cropped on other different sized devices.

I agree that tables should be avoided in e-books when possible. Section 10.5 of the Amazon Kindle Publishing Guidelines has some suggestions on creating tables, such as keeping them small and simple. The KFX renderer in newer Kindle apps and devices has a pop-up table viewer that helps a bit.

Many will suggest replacing tables with images, but that has some downsides. For example the text will not be in the reader's chosen font. Also text search and dictionary lookups will not function.

[stumped]

my encounter was with an epub library loan
I suspect that big publisher decides to reissue big author's old stuff as ebook, contracts out to lowest bidder, who just rams the hardback layout through a conversion program with little or no actual proof reading.
so you get tables, and ridiculous font choices that may have looked great in hardback, back in the day... .