Sigil to MOBI tutorials by pdurrant

[st_albert]

Originally Posted by Hitch

At the end of the day, I've found the simplest thing to do is to run a hand-crafted (Sigil) epub through Calibre thus: my epub->.mobi in Calibre; then that same .mobi->epub, again in Calibre, and then use that second, Calibre-generated epub, drag-n-drop it on KindleGen and get a Kindle-ready .mobi file which will withstand the rigors of K4PC second layer of encryption. The entire "problem" is not really anything more than the fact that the toc is named differently by the two different formats.

Hitch

Doesn't that process end up stripping out the extra <guide> elements that crutlidge was concerned about originally, though?

OTOH, you do get a kindlegen-created mobi with an inline toc that way.

ETA: Aha! But, I see you can edit the second epub in sigil, add back the semantics, edit the content.opf and change the "text" semantic to "start-reading," re-zip, and then kindlegen -> mobi and hey, presto! TOC and semantic index, both working!

A bit convoluted, but not TOO bad. And that's why they pay us the big bucks, no?

[pdurrant]

Hi everyone. Sorry I've not been contributing, despite being named in the title.

I've been asked about what to do with blockquotes and Kindlegen, as sometimes they don't seem to work.

The answer is that Kindlegen (& Mobipocket Creator) don't handle blockquotes well. They will only apply to the first paragraph immediately following the blockquote open tag. Ughh...

If you're aiming at generating ePub and Kindle/Mobipocket from the same source, I've found it's necessary to limit the formatting choices in the ePub — keeping the CSS very simple. But even then there are lots of pitfalls. See the thread here: https://www.mobileread.com/forums/showthread.php?t=96061

[crutledge]

Being ever the optimist, I posted this to the Mobipocket.com forum.

I find two major problem with kindlegen.

I perform the fillowing call: c:\kindlegen book.epub.

kindlegen reports the following:Info(prcgen): Building table of content URL: C:\Users\Charles\AppData\LocalTemp\MTDFLCIX\OEBPS\ toc.ncx.
No toc appears in book.mobi.

Kendlegen ignores something as common as <blockquote>...</blockquote>. There is no indent and no space above/below the snippit.

This makes the mobi file unusable for release.

Can we expect a fix for this in the near future?

I will post the reply, if ever.

[crutledge]

Since kindlegen does not handle <blockquote>, I experimented with the following class:

.block{
	padding-bottom: 4px;
	padding-top: 4px;
	padding-left: 3em;
}

This doesn't work either so I guess more is wrong than <blockquote>. No padding.

By keeping the toc and list of illustrations from the PG file (with some re-formatting) any data in the opf guide shows up in the contet menu of the Mobireader and works fine. The toc and loi work also.

I'm out of ideas.

[pdurrant]

Originally Posted by crutledge

Since kindlegen does not handle <blockquote>, I experimented with the following class:

.block{
	padding-bottom: 4px;
	padding-top: 4px;
	padding-left: 3em;
}

This doesn't work either so I guess more is wrong than <blockquote>. No padding.

padding is completely ignored by kindlegen. margin-top and margin-bottom might work.

[Snowman]

I've found that mobi <blockquote> will work as long as there are NO <p></p> tags within the <blockquote></blockquote> block. Use <div></div> instead (or naked lines separated by <br>).

You might want to define a ".p" class with the same characteristic as you are using for <p>, so you can state <div class="p"> to gain a pseudo-para.

This is sorta implied in the Kindle Formatting Guide in the example in the section on Nested TOC Guideline.

Also, be careful if you use 'margin- top/bottom' in the blockquote style, since the mobi/kindle reader will round any fractions up - so 1.2em becomes 2em - which is probably not at all what you wanted. Similarly, the left margin indent is 1em (implemented in the *reader*), unless the 'margin-left' setting is used, in which case the value is used as an increment in em to the pre-defined 1em indent display.

For my own purposes, I assumed 16px=1em, and found that the css definition 'blockquote{margin: 8px 0 8px 0;}' (the left margin is ALWAYS in ems) works about as well as I care to get without a lot of extra effort.

regards

Snowman.

[crutledge]

Originally Posted by Snowman

I've found that mobi <blockquote> will work as long as there are NO <p></p> tags within the <blockquote></blockquote> block. Use <div></div> instead (or naked lines separated by <br>).

You might want to define a ".p" class with the same characteristic as you are using for <p>, so you can state <div class="p"> to gain a pseudo-para.

This is sorta implied in the Kindle Formatting Guide in the example in the section on Nested TOC Guideline.

Also, be careful if you use 'margin- top/bottom' in the blockquote style, since the mobi/kindle reader will round any fractions up - so 1.2em becomes 2em - which is probably not at all what you wanted. Similarly, the left margin indent is 1em (implemented in the *reader*), unless the 'margin-left' setting is used, in which case the value is used as an increment in em to the pre-defined 1em indent display.

For my own purposes, I assumed 16px=1em, and found that the css definition 'blockquote{margin: 8px 0 8px 0;}' (the left margin is ALWAYS in ems) works about as well as I care to get without a lot of extra effort.

regards

Snowman.

This is the answer from a very helpful lady to a query in the Amazon forums:

Re blockquotes, I'm guessing that you have <p> tags inside the blockquote tags? If you are, I think the paragraph formatting is overriding the blockquote formatting. I'd recommend applying a "blockquote" style to those paragraphs, rather than relying on native blockquote styling based on the blockquote tags. It's not that you're doing any wrong as such - just that Kindlegen is a little quirky in how it applies formatting. Alternatively, if you use the blockquote tags to enclose text, and don't use any paragraph tags inside the blockquote, it'll format the way you expect. It just won't do it, as far as I know, when paragraph tags are used inside the blockquote.

- Donna

I haven't tested yet but seems reasonable. Mobi is quirky.

Snowman, you are a genius.

[crutledge]

I went in and changed all the <p> tags inside the block with the <div> tag. Every one displayed as desired. Now I only have to fine tune the spacing.

I leave in the in-line toc and loi in the file, mark the sections w/ the desired semantics, edit the OPF as needed and use kindlegen. A beautiful mobi file results. I then save the toc and loi xthml files to the working folder in case I have further need and then delete the toc and loi from the sigil file. Busy but worth the effort.

Thanks for all the help.

[crutledge]

This is the response the a query about the generation of a mobi toc from an epub from Sigil

As far as I know, Kindlegen won't create an HTML table of contents if one doesn't already exist. I haven't seen it do that in practice, and know of no way to make it do that. It uses the NCX file to create a "logical" table of contents that the Kindle device can use to enable section navigation, but that's not the same as an HTML toc which forms part of the book, and which the user can view and access directly, using the "Go To... Table of Contents" Kindle (or other e-reader) menu command.

If the book doesn't already contain an HTML table of contents, you should consider creating one if it's appropriate - a straightforward novel, for example, with 45 chapters called simply "Chapter One", "Chapter Two", etc, would result in a rather tedious and essentially meaningless HTML Table of Contents, although having the NCX navigation file would still be a good idea. You would then need to amend the NCX file to include a navigation point for the HTML Table of Contents, and amend the OPF file as follows:

1. Add an item to the manifest section if the HTML ToC is in a separate HTML file.
2. Add an item to the spine section to reference the HTML ToC in the reading order.
3. Add a type="toc" reference item to the guide section to point to the HTML ToC.

- Donna

[Hitch]

Errr, crutledge:

Response by whom, please? Or, rather, from whence? Amazon?

Thx,

Hitch

[crutledge]

Originally Posted by Hitch

Errr, crutledge:

Response by whom, please? Or, rather, from whence? Amazon?

Thx,

Hitch

Same as previous report. Amazon forums.