0.5.901 (0.6.0 beta) avaliable

[meme]

Originally Posted by mesquite

But looking through the list classes <li class="blah blah blah"> is counting each individual split in the ePUB document. There isn't really 88 its more like well... 87 and number thus as is. What do I need to fix in the inline ToC to make it output the same for MOBI as it does for ePub?.

The issue is that Mobi does not support styles for list items. The Inline TOC HTML is using list items, but styling them so that no number is shown. Mobi ignores this and shows the numbers for the items.

There are a few ways around this:

1. I modify the code that generates the inline TOC to just use indented paragraphs. This would make it work on both. I'm tempted to do this - its not difficult - but the only question is that EPUB3 uses a list item format for its TOC and the format was trying to emulate that. On the other hand, there aren't any other EPUB3 features yet so it could be dealt with later. And I think this is going to generate a lot of questions that could be avoided.
2. If you are already using Calibre, then don't use the inline TOC. Just tell Calibre to create the inline TOC for you at the start of the book.
3. Use Regex to remove the ol tags, and replace the li tags with p tags (with an indented style if you want).
   

[mesquite]

Originally Posted by meme

The issue is that Mobi does not support styles for list items. The Inline TOC HTML is using list items, but styling them so that no number is shown. Mobi ignores this and shows the numbers for the items.

There are a few ways around this:

1. I modify the code that generates the inline TOC to just use indented paragraphs. This would make it work on both. I'm tempted to do this - its not difficult - but the only question is that EPUB3 uses a list item format for its TOC and the format was trying to emulate that. On the other hand, there aren't any other EPUB3 features yet so it could be dealt with later. And I think this is going to generate a lot of questions that could be avoided.
2. If you are already using Calibre, then don't use the inline TOC. Just tell Calibre to create the inline TOC for you at the start of the book.
3. Use Regex to remove the ol tags, and replace the li tags with p tags (with an indented style if you want).
   

Okay well as I stated my HTML is very minute so a bit more in depth explaining would help. Even looking at regex sticky I was in over my head. looking at your reply might have negated my plan which was to remove the <li></li> tags from each one and use </br> but that has been deprecated from XHTML hasn't it?

[Doitsu]

Since inline TOCs are only needed for Kindle books, why not follow Amazon's recommendation and use divs?

Their publishing guideline recommends the following:

<style> 
   div.chapter { margin-left: 1em} 
   div.subchapter { margin-left: 2em} 
</style> 

<div>Section 1</div> 
<div class="chapter">Chapter 1</div> 
<div class="chapter">Chapter 2</div> 
<div class="chapter">Chapter 3</div> 
<div class="subchapter">Subchapter 1</div> 
<div class="subchapter">Subchapter 2</div> 
<div class="chapter">Chapter 4</div> 
<div class="subchapter">Subchapter 1</div> 
<div>Section 2</div>

[meme]

If I remove the list items, then using divs looks like a good suggestion. I've just gotten into the habit of using p tags, but technically these aren't paragraphs Probably should update them in the user guide for a few of pages.

Inline TOCs are not only needed for Kindles. They are also useful if you want a TOC in your book, or want one that looks slightly different (more/less items) than the regular TOC (and some devices don't indent their regular TOC).

[mesquite]

This is putting me in over my head if I do the div, do I create a style sheet in the conversion option in Calibre? I like where the update with Sigil is going with the inline and was thrilled to see it available just got the nasty shock of the numbered ToC after the conversion.

[Ahmad Samir]

Originally Posted by DiapDealer

Couple of things I'm noticing about 0.5.901:

On Windows... the supplied binary is not substituting the html entities for the three characters (soft-hyphen and m- and n-dash) as the code (and the devs) seems to suggest it should. I've tried on XP, Vista, Win7 32-bit, and Win7 64-bit. The original source of the ePub remains unchanged... entity stays entity and character stays character.

If you switch from CV -> BV then back to CV, do the entities appear as expected?

From src/Sigil/BookManipulation/CleanSource.cpp, Tidy in Sigil is configured to preserve entities:

tidyOptSetBool( tidy_document, TidyPreserveEntities, yes );

from the Tidy manual page:

preserve-entities

              Type:    Boolean
              Default: no
              Example: y/n, yes/no, t/f, true/false, 1/0

              This option specifies if Tidy should preserve the well-formed entitites as found in the input.

[capidamonte]

A simple workaround is to just change <ol></ol> to <ul></ul>.

You do get a middot in MOBI, but, well, you can also have easily inset multi-level section lists, which is nice.

Not complete, I know, but it's simple and it gets rid of the numbers.

Aloha,

[JSWolf]

I think the idea of letting Calibre convert toc.ncx to an inline ToC is the best and most simple of ways to get a ToC in a Mobi file.

[DiapDealer]

Originally Posted by Toxaris

When I look at the Sigil page about generating (I don't know if it is correct), there are two methods.
1. Use Qt SDK with MingW for compiling (nmake method?)
2. Use Visual Studio

Perhaps with the Visual Studio method it works. Will Visual Studio Express (free version) do the trick?

No... MingW isn't mentioned as one of the Windows methods on Sigil's Wiki or the INSTALL.txt file provided with the source (although I'm sure it could be finagled as well). There's the Windows SDK (still uses MSVC compiler, but everything must be done via the command-line with 'nmake')... and there's the method that uses Full blown Visual $tudio project files. Both methods need the Qt libraries.

I'm not sure which method the devs use to produce the distributed Windows Binaries, but it doesn't seem to provide the entity substitution either. That's why I was confused about the claim that certain characters were being converted to entities since version 4. I'm just not seeing that happen on Windows with 0.5.3 or the latest beta (stock binary or built from source). *shrugs*

Originally Posted by Ahmed Samir

If you switch from CV -> BV then back to CV, do the entities appear as expected?

No, they just don't appear as expected. Not even when saving/closing Sigil and reopening do the entities appear. \u00ad stays \u00ad and \u2014 stays \u2014. I just assumed this was the planned behavior until I started looking at the source.

Originally Posted by JSWolf

I think the idea of letting Calibre convert toc.ncx to an inline ToC is the best and most simple of ways to get a ToC in a Mobi file.

Simple? Yes. Best? Not really yours to decide. I welcome the inline ToC generation feature of Sigil... it's not like people are going to be forced to use it or anything. They still have choices. And contrary to your perpetual anti-inline-TOC-in-ePubs campaign, some people still prefer to include them in their ePubs--regardless of if they're ever going to be converted to MOBI (and certainly regardless of the fact that you'd rather they didn't ).

[theducks]

Originally Posted by Toxaris

My guess would be that the conversion of ePUB to Mobi either ignores the 'list-style-type: none' or that is not supported on Mobi.

Maybe changing the list style from ol to ul
At least, in that case, the op will only get bullet marks (not those kind )

[user_none]

Originally Posted by Doitsu

Since inline TOCs are only needed for Kindle books, why not follow Amazon's recommendation and use divs?

If people make Kindle books Amazon can produce their own Kindle book editor.

I've changed ol to ul. ul actually makes more sense because the numbers might not match with actual chapter numbers.

As for building on Windows. I use the Microsoft SDK. MinGW might work but I've never used it. At some point in the future I plan on moving to MinGW. Once that happens Microsofts compiler will no longer be supported.

Entities, I have no idea why the replacement is not working on Windows. As Windows is a minority platform for developers this might me some time until it gets fixed or looked at. If it even does get fixed. In later versions the plan is to remove as much automatic magic as possible and move it into user callable plugins.

@crutledge can you send me (john@niw.cx) an example file that crashes Sigil. I'll look into it.

Beta 2 (0.5.902) should be ready later today or tomorrow. Hopefully.

[user_none]

Originally Posted by DiapDealer

**Also note that when building on Windows with the SDK nmake method, the ckeditor files are not being copied when executing 'nmake makeinstaller' and because of that, are not being included in the installer. There are no errors in the build process, ckeditor just isn't being included in the package. The cmake PRE_BUILD 'make_directory' command to create the ckeditor folder in the temp directory is working... but the cmake POST_BUILD 'copy_directory' command doesn't appear to be having the desired effect (src/Sigil/CMakeLists.txt). Doesn't seem to make a difference whether building with the SDK on XP or Win7

Am I just missing something in the Windows build process/environment?

I'm building on Windows with the MS SDK. Clean unzip for the source with nmake makeinstaller. At one point what you're seeing was true. I'm guessing you are using an existing build dir. You need to rerun cmake otherwise the changes to the CMakeLists.txt be used.

Also, if you're not using the latest checkout do so. I don't think you are because you posted yesterday and git has been broken for the past few days.

[DiapDealer]

Originally Posted by user_none

Entities, I have no idea why the replacement is not working on Windows. As Windows is a minority platform for developers this might me some time until it gets fixed or looked at. If it even does get fixed.

No big deal for me. I don't really consider it "broken" in the first place. I was mostly confused by the reports that it (character to entity substitution) was supposed to be happening all along—when I just wasn't seeing it in practice. I was looking to tweak any substitution behavior that didn't agree with me, but since it appears that no characters are being replaced with entities in the Windows versions... no tweaking necessary.

In later versions the plan is to remove as much automatic magic as possible and move it into user callable plugins.

I get excited whenever the "P" word gets mentioned (though I know it's probably a ways off yet).

[user_none]

Moderator Notice
Closing thread as a new beta is available.