KindleGen vs calibre

[HarryT]

Originally Posted by virtual_ink

Lastly, and very worryingly, when I use the internal TOC (the toc on a page within the text) to navigate, the headings I've used as hyperlink destinations display incorrectly.

i.e.: If I view the 'Chapter 1' heading by scrolling through the book, the heading style appears almost as I have designed it (perhaps a little larger than it does in the epub).

BUT, if I use the TOC text links to navigate to that destination, the heading style applied to 'Chapter 1' has changed! It now appears much smaller than the CSS specifies.

That means that your hyperlink is taking you somewhere inside the tags for the header. ie, you have something like:

<H1><A name="chapter_1">CHAPTER 1</A></H1>

The key thing to bear in mind with a Mobi file is that when you follow a hyperlink in a Mobi book, it renders the page from the exact point you jump to, so when you click the "Chapter 1" hyperlink, the code above will render as:

CHAPTER 1</H1>

which is of course meaningless. You need to make sure that you have something like:

<A name="chapter_1"><H1>CHAPTER 1</H1></A>

which will render correctly when you jump to the anchor.

[DiapDealer]

reading in Kindle app on iPad

I can't verify what the issues with Kindle for iPad might be, but with regard to the Kindle device itself:

The front cover image is repeated on the second page

I've never experienced that issue so I can't help much

There is no navigational TOC

Not exactly sure what you mean, but the toc.ncx file will only be used to create chapter "jump points" that can be navigated using the Kindle's five-way controller. They'll be represented as dots on the progress bar. If there is no in-line (html with the "toc" semantic assigned) toc, kindlegen does not create one from the toc.ncx.

Justified text doesn't hyphenate
Headings (aligned left in CSS) do hyphenate

The Kindle doesn't hyphenate. Period. There will be occasional ragged-right lines in justified text.

CSS working properly? Does Kindle treat H1, H2 etc in a default fashion? Or does it use the CSS? If the former, am I best to style all headings with P tags in order for Kindle to use my CSS?

Some CSS works fine, some... not so much. Use KindlePreviewer (just drag & drop the epub on it) to test. You can also use MobiUnpack.py to see what html kindlegen produces. The biggest pain in the ass is that kindlegen doesn't support multiple CSS classes assigned to elements. So:

<p class="bigger bolder>Blah, blah, blah</p>

ain't gonna fly. You'd have to do something like:

<p class="bigger"><span class="bolder">Blah, blah, blah</span></p>

With kindlegen, the less CSS—and the simpler the CSS—the better. Complicated doesn't work. It all has to be flattened into html 3.2 attributes inside the mobi (no CSS in mobi) by the converter program.

[DiapDealer]

Originally Posted by Ron.

I guess I am odd, I create the book in notetab, the opf and the ncx then use kindlegen to create the mobi. making a epub then converting it to mobi seems an added step.

For many, creating an ePub with Sigil (or other GUI editor) is much easier than dealing with raw markup manually (not to mention creating opf's and ncx's manually). And if those people are going to release a mobi AND an ePub version of the same book, it makes sense that they want to maintain one "source." ePub->MOBI.

Of course, if you're handy with html, and familiar with the ins and outs of the OPF, NCX file(s), then skipping the ePub creation entirely (or making it later) will probably make the most sense. MOBI->ePub.

[st_albert]

@ virtual_ink, re: repeated cover image in Mobi created by kindlegen from epub.

This is a known issue (see post #4 above). To circumvent it you must edit the epub and (assuming your cover image is displayed in its own .xhtml file named "cover_page.xhtml) remove the "cover_page.xhtml" or its equivalent. Just the xhtml file, not the cover image itself. Delete it from the manifest as well.

Then in the <guide> section of content.opf (or equivalent) be sure that there is a type=cover item whose href= reference points to the cover image itself (e.g. href="Images/cover.jpg" or such).

While you're at it, include a type=text name="Start Reading" guide entry pointing at the place where you want the book to open.

Save the edited epub under a new name, and use it to convert to mobi with kindlegen. That should fix the double cover issue.

Or try calibre. IIRC it handles this one for you. I could be wrong about that though.

And DiapDealer gave you the fair dinkum about the various TOC files. With Kindlegen, you have to supply your own inline toc.xhtml in the epub you're converting.

[JSWolf]

Originally Posted by virtual_ink

Cripes. I have just done my first conversion from epub to mobi (using kindlegen, reading in Kindle app on iPad) and the results are somewhat alarming:

Try Calibre to convert the same ePub to Mobipocket and post the results. I'd be interested in reading about this.

[DiapDealer]

Originally Posted by JSWolf

Try Calibre to convert the same ePub to Mobipocket and post the results. I'd be interested in reading about this.

It's a given that calibre does a much better job of converting the ePub's CSS into coherent (and visually similar) mobi's. That's not really even a question.

The problem is that since MOBI is still ultimately a proprietary format, many want to ensure complete compatibility with Kindle devices/apps by using the approved tools. Especially if it's a commercial project. I may be being a bit alarmist just to make a point, but what if there's a tiny detail that's been overlooked in calibre's (or anybody's) assumptions about the MOBI format? Would it not then be possible that a future Kindle firmware/software update could render previous calibre converted MOBI's defective in some way?

Basically I'm saying that just because calibre conversions may be easier and even often look better... that ain't the whole picture.

[JSWolf]

Originally Posted by DiapDealer

It's a given that calibre does a much better job of converting the ePub's CSS into coherent (and visually similar) mobi's. That's not really even a question.

The problem is that since MOBI is still ultimately a proprietary format, many want to ensure complete compatibility with Kindle devices/apps by using the approved tools. Especially if it's a commercial project. I may be being a bit alarmist just to make a point, but what if there's a tiny detail that's been overlooked in calibre's (or anybody's) assumptions about the MOBI format? Would it not then be possible that a future Kindle firmware/software update could render previous calibre converted MOBI's defective in some way?

Basically I'm saying that just because calibre conversions may be easier and even often look better... that ain't the whole picture.

If a future Kindle renderer changes the way Mobi from Calibre looks, then I'd have to call bugs in the Kindle renderer. What we currently get from Calibre is actually not too too bad given the format.

[DiapDealer]

Originally Posted by JSWolf

If a future Kindle renderer changes the way Mobi from Calibre looks, then I'd have to call bugs in the Kindle renderer. What we currently get from Calibre is actually not too too bad given the format.

Dude, I want to thank you from the bottom of my heart for completely ignoring/misinterpreting/not getting what I tried to explain.

[virtual_ink]

Originally Posted by HarryT

That means that your hyperlink is taking you somewhere inside the tags for the header. ie, you have something like:

<H1><A name="chapter_1">CHAPTER 1</A></H1>

The key thing to bear in mind with a Mobi file is that when you follow a hyperlink in a Mobi book, it renders the page from the exact point you jump to, so when you click the "Chapter 1" hyperlink, the code above will render as:

CHAPTER 1</H1>

which is of course meaningless. You need to make sure that you have something like:

<A name="chapter_1"><H1>CHAPTER 1</H1></A>

which will render correctly when you jump to the anchor.

Thanks Harry, this sounds like the problem. I've tried your fix but am having problems as my H tags contain the following:

<h1><id="toc_marker-2" class="chapterheader"><span class="Bold">Chapter 1<br/>Subheading for Chapter 1</span><span class="Bold-Italic">including these bold itals within the subtitle</span><span class="Bold"> subtitle continues in roman bold</span></h1>

I've tried switching this to:

<id="toc_marker-2"/> <class="chapterheader"><span class="Bold"><h1>Chapter 1<br/>Subheading for Chapter 1</span><span class="Bold-Italic">including these itals within the subtitle</span><span class="Bold"> subtitle continues in roman bold</h1></span>

But it won't validate. here's the error message:
Element type "id" must be followed by either attribute specifications, ">" or "/>".

[DaleDe]

Originally Posted by DiapDealer

It's a given that calibre does a much better job of converting the ePub's CSS into coherent (and visually similar) mobi's. That's not really even a question.

The problem is that since MOBI is still ultimately a proprietary format, many want to ensure complete compatibility with Kindle devices/apps by using the approved tools. Especially if it's a commercial project. I may be being a bit alarmist just to make a point, but what if there's a tiny detail that's been overlooked in calibre's (or anybody's) assumptions about the MOBI format? Would it not then be possible that a future Kindle firmware/software update could render previous calibre converted MOBI's defective in some way?

Basically I'm saying that just because calibre conversions may be easier and even often look better... that ain't the whole picture.

It has been fairly well reverse engineered and this is documented in our wiki under MOBI however, Amazon can and does mess with the format but surprisingly it is only a short period of time before the Calibre folks have reverse engineered the changes. Amazon can't drastically change anything since there are thousands of books out there in this format and they can't break them so the format changes can only be additions and compatible new features. So you worries are not too realistic. The format in some form has been around for a decade.

Dale

[JSWolf]

Originally Posted by virtual_ink

Thanks Harry, this sounds like the problem. I've tried your fix but am having problems as my H tags contain the following:

<h1><id="toc_marker-2" class="chapterheader"><span class="Bold">Chapter 1<br/>Subheading for Chapter 1</span><span class="Bold-Italic">including these bold itals within the subtitle</span><span class="Bold"> subtitle continues in roman bold</span></h1>

I've tried switching this to:

<id="toc_marker-2"/> <class="chapterheader"><span class="Bold"><h1>Chapter 1<br/>Subheading for Chapter 1</span><span class="Bold-Italic">including these itals within the subtitle</span><span class="Bold"> subtitle continues in roman bold</h1></span>

But it won't validate. here's the error message:
Element type "id" must be followed by either attribute specifications, ">" or "/>".

Change to...

<h1 id="toc_marker-2" class="chapterheader"><span class="Bold">Chapter 1<br/>Subheading for Chapter 1</span><span class="Bold-Italic">including these bold itals within the subtitle</span><span class="Bold"> subtitle continues in roman bold</span></h1>

That should work as it will jump to the h1 tag and not after it.

[virtual_ink]

Thanks JSWolf. I think that would work - however, I actually posted code from the wrong file! For the record, here's what I should have posted, and it works.

Original code:
<h2 id="toc_marker-6" class="sectiontitle"><span class="Bold"><a id="Contributors"/>Contributors</span></h2>

Edited code:
<a id="Contributors"/><h2 id="toc_marker-6" class="sectiontitle"><span class="Bold">Contributors</span></h2>

This validates, and works in Kindle (with no lost H tags!). Thanks all for your help.

@DiapDealer

There is no navigational TOC

Not exactly sure what you mean, but the toc.ncx file will only be used to create chapter "jump points" that can be navigated using the Kindle's five-way controller. They'll be represented as dots on the progress bar. If there is no in-line (html with the "toc" semantic assigned) toc, kindlegen does not create one from the toc.ncx.

I assumed Kindle would have a similar navigational TOC to iBooks (the one accessed with the little icon at the top of the page). From what I understand now, the Kindle device doesn't have that function, and must have a TOC page within the text. Please correct me if I'm wrong.

What threw me, was that in the Kindle app for iPad - if I use the 'Go to' icon - a submenu opens and an option for 'Table of Contents' is greyed out with a note "Not available for this title".

As I have a linked TOC page at the front of the book, perhaps I am providing all that is needed. What you are describing in the progress bar sounds helpful. i wonder why Kindlegen isn't generating this from the original epub toc.ncx

[Ron.]

Originally Posted by virtual_ink

Thanks JSWolf. I think that would work - however, I actually posted code from the wrong file! For the record, here's what I should have posted, and it works.

Original code:
<h2 id="toc_marker-6" class="sectiontitle"><span class="Bold"><a id="Contributors"/>Contributors</span></h2>

Edited code:
<a id="Contributors"/><h2 id="toc_marker-6" class="sectiontitle"><span class="Bold">Contributors</span></h2>

This validates, and works in Kindle (with no lost H tags!). Thanks all for your help.

@DiapDealer



I assumed Kindle would have a similar navigational TOC to iBooks (the one accessed with the little icon at the top of the page). From what I understand now, the Kindle device doesn't have that function, and must have a TOC page within the text. Please correct me if I'm wrong.

What threw me, was that in the Kindle app for iPad - if I use the 'Go to' icon - a submenu opens and an option for 'Table of Contents' is greyed out with a note "Not available for this title".

As I have a linked TOC page at the front of the book, perhaps I am providing all that is needed. What you are describing in the progress bar sounds helpful. i wonder why Kindlegen isn't generating this from the original epub toc.ncx

the mobi needs and inline (html) table of contents in addition to the ncx file, the ncx file on the kindle is only used for the 5 way controller and to display the chapter points at the bottom.


you need to have the inline table of contents and for it to link correctly you need to add

<guide>
<reference type="toc" title="Table of Contents" href="filename.html#bookmark"/>
</guide>

in your opf file, if not the option to jump to the table of contents will be greyed out.

[DiapDealer]

Originally Posted by DaleDe

It has been fairly well reverse engineered and this is documented in our wiki under MOBI however, Amazon can and does mess with the format but surprisingly it is only a short period of time before the Calibre folks have reverse engineered the changes. Amazon can't drastically change anything since there are thousands of books out there in this format and they can't break them so the format changes can only be additions and compatible new features. So you worries are not too realistic. The format in some form has been around for a decade.

Fair enough. I admitted in my post that it was a pretty alarmist stance in the first place.

My point was simply that there's some people who aren't comfortable submitting calibre generated MOBI's to Amazon (regardless of how nice they may look). Call it paranoid, call it what you will. I love calibre and use it extensively, but if I'm going to ask someone to spend their hard-earned dollars to buy my product from Amazon to read on their Kindle, it's going to be built by Amazon approved publishing programs.

That's just a personal thing, but I'm sure there are others who feel the same way.

[pdurrant]

Originally Posted by DiapDealer

My point was simply that there's some people who aren't comfortable submitting calibre generated MOBI's to Amazon (regardless of how nice they may look). Call it paranoid, call it what you will. I love calibre and use it extensively, but if I'm going to ask someone to spend their hard-earned dollars to buy my product from Amazon to read on their Kindle, it's going to be built by Amazon approved publishing programs.

That's just a personal thing, but I'm sure there are others who feel the same way.

I do. I wouldn't want to submit a calibre-generated mobipocket file to the Kindle Store.

But there is a solution. Generate using calibre. Then unpack using the mobiunpack script, and then re-compile using Kindlegen.

All the neat CSS interpretation by calibre, and a kindlegen generated file as well.