kdp / azw3 / calibre / mobi

[JSWolf]

Originally Posted by jhowell

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.



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.

I'm not saying to drop Mobi. I'm saying to allow KF8 only eBooks where they use advanced formatting that Mobi won't work well enough with.

Yes, some tables should be avoided. But the problem is that if you were to make this eBook in Mobi properly, it would need table images. which to some might be unreadable.

What I don't get is why Amazon created KF8 with advanced features if they were keeping Mobi that doesn't have any advanced features. The problem is that you can do things in KF8 that don't work in Mobi. Amazon should allow eBooks to move on as needed. They already allow things like Kindle-in-Motion to not work on old Kindles.

[DaleDe]

Originally Posted by jhowell

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.

Instead of the archive you could use our wiki page EBook_HTML

[joe 1]

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.

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

Ooo - I wasn't aware of that. That must might do the trick. I will give it a shot.

[Hitch]

Originally Posted by JSWolf

I'm not saying to drop Mobi. I'm saying to allow KF8 only eBooks where they use advanced formatting that Mobi won't work well enough with.

Yes, some tables should be avoided. But the problem is that if you were to make this eBook in Mobi properly, it would need table images. which to some might be unreadable.

What I don't get is why Amazon created KF8 with advanced features if they were keeping Mobi that doesn't have any advanced features. The problem is that you can do things in KF8 that don't work in Mobi. Amazon should allow eBooks to move on as needed. They already allow things like Kindle-in-Motion to not work on old Kindles.

Dude, there isn't a KF8-only format, other than Print Replica and that's the Format Of Last Resort.

You can do tables in Mobi-KF8. It's not impossible and of course you can create reasonable borders. What you can't do is create foofy borders or anything fancy. And those tables will, by and large, also work in KF7.

The other problem is that if you have very large tables, they'll "turn off" Enhanced Typesetting and you don't want that, either. So...without seeing your tables or knowing more, I can't really advise on "use table" or "use images."

Hitch

[JSWolf]

Originally Posted by Hitch

The other problem is that if you have very large tables, they'll "turn off" Enhanced Typesetting and you don't want that, either. So...without seeing your tables or knowing more, I can't really advise on "use table" or "use images."

Hitch

I've never see fake text (graphics in place of proper text) that actually looked good enough.

[Hitch]

Originally Posted by JSWolf

I've never see fake text (graphics in place of proper text) that actually looked good enough.

Wolfie, dear...

Why am I not surprised that you'd say that?

When you say, "looked good enough," to whose standards? Simply yours? You know as well as the rest of us that we have to do the best we can in the situation, which is, not all devices have great table support. And even those that do, still can have issues with HTML tables.

Slight non-sequitur: I have a customer (a white-label job, so the dude isn't my direct customer) that INSISTS he must have "pop-up tables." He doesn't understand that the only popping-up is zooming, as images. He's not HAPPY with html tables. Beats me, but he insisted that we had to change the HTML tables that we created, for ~30% of his tables, to be images, so that they would "pop up" when tapped.

Yup, being a Mercenary Ho sucks, but, at least I can say 'Hey, the client wanted it." ;-)

Hitch

[JSWolf]

Originally Posted by Hitch

Wolfie, dear...

Why am I not surprised that you'd say that?

When you say, "looked good enough," to whose standards? Simply yours? You know as well as the rest of us that we have to do the best we can in the situation, which is, not all devices have great table support. And even those that do, still can have issues with HTML tables.

Slight non-sequitur: I have a customer (a white-label job, so the dude isn't my direct customer) that INSISTS he must have "pop-up tables." He doesn't understand that the only popping-up is zooming, as images. He's not HAPPY with html tables. Beats me, but he insisted that we had to change the HTML tables that we created, for ~30% of his tables, to be images, so that they would "pop up" when tapped.

Yup, being a Mercenary Ho sucks, but, at least I can say 'Hey, the client wanted it." ;-)

Hitch

Usually these images are too small and do not look all that readable. On a 300DPI eInk screen, these graphics can be even harder to read. Plus, in most cases, the graphic text is smaller then the actual text.

You do have some odd clients.

[Hitch]

Originally Posted by JSWolf

Usually these images are too small and do not look all that readable. On a 300DPI eInk screen, these graphics can be even harder to read. Plus, in most cases, the graphic text is smaller then the actual text.

SOOOO, what you really meant to say isn't that table graphics suck, but that cheap bookmakers or inept boobs put crappy graphics in there that aren't of decent quality, right? I wouldn't disagree with that sentiment.

You do have some odd clients.

Brother, you have NO idea. Today--today--(in 2020, mind you!) I'm dealing with a submitted manuscript that is 99.8K words long and contains...314 paragraphs.

How can that be, you ask?

Well, Wolfie, I'll tell you--it happens because if you type an entire book, like so:

typety-type-type-type-type-type-type. [end of paragraph text]tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab[start of new paragraph text]...

You get a few hundred paragraphs, 11298 tabs (yes, really!) and a file that could never be uploaded at KDP without making a high holy mess of it.

That's the BEST client I'm dealing with so far today. Seriously, this job has probably aged me 25 years in 10.

Hitch

[JSWolf]

Originally Posted by Hitch

SOOOO, what you really meant to say isn't that table graphics suck, but that cheap bookmakers or inept boobs put crappy graphics in there that aren't of decent quality, right? I wouldn't disagree with that sentiment.

Yes, I'll go with that as it fits.

Brother, you have NO idea. Today--today--(in 2020, mind you!) I'm dealing with a submitted manuscript that is 99.8K words long and contains...314 paragraphs.

How can that be, you ask?

Well, Wolfie, I'll tell you--it happens because if you type an entire book, like so:

typety-type-type-type-type-type-type. [end of paragraph text]tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab-tab[start of new paragraph text]...

You get a few hundred paragraphs, 11298 tabs (yes, really!) and a file that could never be uploaded at KDP without making a high holy mess of it.

That's the BEST client I'm dealing with so far today. Seriously, this job has probably aged me 25 years in 10.

Hitch

Where do they get their ideas? At least that tabbed mess can be fixed fairly easily with search/replace.

[Tex2002ans]

Originally Posted by JSWolf

Where do they get their ideas? At least that tabbed mess can be fixed fairly easily with search/replace.

You would think, you would think... but no, there are abominations you wouldn't believe. (Think multi-indented levels of "lists-within-lists" and "footnotes-within-footnotes"... all with tabs/spaces.)

I believed that too until Hitch actually showed me one. Some things are just best left in the depths of hell!

[Hitch]

Originally Posted by Tex2002ans

You would think, you would think... but no, there are abominations you wouldn't believe. (Think multi-indented levels of "lists-within-lists" and "footnotes-within-footnotes"... all with tabs/spaces.)

I believed that too until Hitch actually showed me one. Some things are just best left in the depths of hell!

You remember the one that had what, 200K words of the main narrative text...all in the footnotes? Because the idjit working on it started typing a new "page" AFTER the footnotes, never thinking to put their cursor after the actual body text. Nooooo...let's put the body text IN the footnotes and wait, let's put footnotes IN this body-footnote text!

I mean, honestly, you cannot imagine the things I've seen. Granted, it's not like being a cop, fireman, paramedic, warrior, etc.; I can't claim that this job has given me PTSD, but it's a near thing. Post-Traumatic Conversion Syndrome.

:-)

Hitch

[JSWolf]

Hitch, do you try to teach people about styles in Word?

[Hitch]

Originally Posted by JSWolf

Hitch, do you try to teach people about styles in Word?

Every.single.day.

And out of 5,000+ books now, and ~4500 customers, give or take, I've had...
.
.
.
.
.
.
One. One that bothered to learn them. Oh, wait, I'm lying. Two.


Hitch

[Notjohn]

Originally Posted by jhowell

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.

Thank you for that last bit of information! I have a visceral dislike of Kindle Create, and I'm rather pleased that it has another limitation I didn't know about. I'm awfully grateful for the testing and reporting that you do.

[joe 1]

Ok, I'm almost there. My tables are now showing up with borders! But now I'm having a problem with fonts.

If I use calibre to generate a MOBI from my original epub, I am seeing monospace fonts where I have used "font-family: monospace". But if I use any of the Amazon tools with my epub, I do not get any monospace fonts.

Is there a trick to specifying monospace fonts in CSS so that it gets set properly by Kindle Create / Previewer?