Some problems/bugs in Sigil

[man2010]

Originally Posted by Notjohn

That was never my understanding.... Well, the developers may care about the conversion, but I don't think they did anything to smooth it. It was Amazon that opened its KDP platform to epub format, and things that Amazon did (or didn't do) that occasionally doubled the cover and that sets the Start Reading Location.

(Good to see you on this forum, Man2010!)

Hiya, Notjohn. OK, I got it.

[man2010]

Originally Posted by DiapDealer

Because Gumbo (the Sigil html parsing engine) does not grok entities.

Thanks. This answers my main question.

Originally Posted by DiapDealer

As for some sort of warning that an epub is not 100% ready to be converted to a Kindlebook ... that's just not going to be an integral feature of Sigil. Someone could write a validation plugin that could check for common kindle conversion bug-bears, though. There could even be an output plugin that fixes some of those bugbears. In fact; almost all of the points you raise sound like perfect examples of where plugins can come the rescue.

Sounds great. I used to know C++ well, about 10 years ago. Would it be difficult for me to write the plug-in? In any case, I will post a detailed list of problems to check for during Sigil-to-Kindle conversion in a separate thread, so that others can have a crack at it, if they wish.

Originally Posted by DiapDealer

I guess I'd need to see some specific examples of where/when this "mangling" occurs. Because if a Kindle can properly display the numerical/named entity, then it should have absolutely no problem displaying the character it represents. Either the necessary glyph is included in the Kindle's fonts, or they're not. I fail to see how Sigil's conversion of entities to characters can be the cause of any improper Kindle rendering. But again... you could always preserve a list entities that you deem to be problematic on Kindles if you like--though it's my contention that as far as Kindles go: what's good for the entity is good for the char. Numerical or named entities don't magically create renderable glyphs out of thin air, after all.

As described in the first post, this problem occurred in an EPUB file produced by musical software called Finale 2012. Here is the original post on the KDP forum (3 years ago). My guess is that it was a bug in KindleGen 2.3 or 2.4 that was later fixed (I was unable to reproduce this problem recently with any musical codes).

[man2010]

Originally Posted by Turtle91

Also, just because a reader is using a smartphone does not make the TOC unusable. It depends entirely on the app you are using. If your app doesn't support multi-level TOC/NCX then change apps, or complain to the maker of your app.

No, NCX is a separate issue. Sigil's HTML table of contents is unusable on any smartphone reading app because this TOC is single-spaced (too tightly spaced), and I miss the mark 2 times out of 3 when I try to tap on something. If the TOC has 1em extra spacing between items by default, then there is no problem. A lot of people use smartphones to read ebooks, therefore, if you produce an EPUB with such a tightly spaced HTML TOC, then many end users will be frustrated with such a buggy TOC where you cannot tap what you want.

[rubeus]

Originally Posted by man2010

No, NCX is a separate issue. Sigil's HTML table of contents is unusable on any smartphone reading app because this TOC is single-spaced

Any? I 'm using Mantano on my Z1C and do not have any problems at all. So this counterexample falsifies your statement.

[theducks]

Originally Posted by man2010

No, NCX is a separate issue. Sigil's HTML table of contents is unusable on any smartphone reading app because this TOC is single-spaced (too tightly spaced), and I miss the mark 2 times out of 3 when I try to tap on something. If the TOC has 1em extra spacing between items by default, then there is no problem. A lot of people use smartphones to read ebooks, therefore, if you produce an EPUB with such a tightly spaced HTML TOC, then many end users will be frustrated with such a buggy TOC where you cannot tap what you want.

The bug is with the viewer software not adapting to the device.

NCX is not formatable for that reason. The device is responsible for presentation in a way that works.

[BetterRed]

Originally Posted by man2010

Sounds great. I used to know C++ well, about 10 years ago. Would it be difficult for me to write the plug-in?

Most (all ?) Sigil plugins are primarily written in Python. I believe other languages are theoretically possible.

BR

[DiapDealer]

Originally Posted by BetterRed

Most (all ?) Sigil plugins are primarily written in Python. I believe other languages are theoretically possible.

BR

The basic framework is Python--and is fairly robust. One could technically use a very simple python wrapper to launch an executable written in just about any other language (or launch other scripts--so long as the interpreter for that scripting language is installed and available on the user's machine).

[Doitsu]

Originally Posted by man2010

Would it be difficult for me to write the plug-in? In any case, I will post a detailed list of problems to check for during Sigil-to-Kindle conversion in a separate thread, so that others can have a crack at it, if they wish.

Shameless plug: I wrote a simple KindleGen plugin that'll warn the user if the cover image wasn't defined or if the TOC and Start Reading guide items are missing. (It doesn't fix anything, though.)

The code has become a bit convoluted, but you might be able to use it as the basis for your own plugin and add custom checks and fixes.

As for writing a plugins yourself, it couldn't be easier thanks to the well-designed Plugin Runner framework; it offers convenience functions for pretty much anything you need to manipulate ePubs, and if you get stuck both DiapDealer and KevinH will usually come up with some helpful ideas.

[Turtle91]

Originally Posted by man2010

No, NCX is a separate issue. Sigil's HTML table of contents is unusable on any smartphone reading app because this TOC is single-spaced (too tightly spaced), and I miss the mark 2 times out of 3 when I try to tap on something. If the TOC has 1em extra spacing between items by default, then there is no problem. A lot of people use smartphones to read ebooks, therefore, if you produce an EPUB with such a tightly spaced HTML TOC, then many end users will be frustrated with such a buggy TOC where you cannot tap what you want.

I wasn't referring to just the ncx. The html is completely controllable by the person creating the TOC. Please refer to the comments about styling your own HTML TOC - and then saving it so that Sigil will use YOUR style sheet whenever it creates a new TOC.

It is completely under your control. Don't blame Sigil.

....and, FWIW, I read on my smartphone 99.99% of the time and have never had a problem with the HTML TOC - or the ncx TOC for that matter. I use Marvin on the iPhone 4s/5/5s/6/6s and have family members that use other android apps. I highly recommend - again - staying away from the kindle format/kindle app if you want to have any real control over how your book is displayed.Why go through all the hassle trying to convert ePub into kindle to then try and read with a substandard app - just use a better app in the first place!

Cheers,

[Toxaris]

Originally Posted by DiapDealer

The basic framework is Python--and is fairly robust. One could technically use a very simple python wrapper to launch an executable written in just about any other language (or launch other scripts--so long as the interpreter for that scripting language is installed and available on the user's machine).

That is actually what I did with the ePUBOptimizer plugin. Basically because the program already existed and is written in another language. The ePUBCheck plugin is a wrapper for the java program.

[man2010]

Originally Posted by Doitsu

Shameless plug: I wrote a simple KindleGen plugin that'll warn the user if the cover image wasn't defined or if the TOC and Start Reading guide items are missing. (It doesn't fix anything, though.)

The code has become a bit convoluted, but you might be able to use it as the basis for your own plugin and add custom checks and fixes.

As for writing a plugins yourself, it couldn't be easier thanks to the well-designed Plugin Runner framework; it offers convenience functions for pretty much anything you need to manipulate ePubs, and if you get stuck both DiapDealer and KevinH will usually come up with some helpful ideas.

Thanks a lot for the info, I will get started next week.

[exaltedwombat]

Originally Posted by Turtle91

I highly recommend - again - staying away from the kindle format/kindle app if you want to have any real control over how your book is displayed.Why go through all the hassle trying to convert ePub into kindle to then try and read with a substandard app - just use a better app in the first place!

Are an appreciable number of us really just creating eBooks for our own personal consumption? If you know exactly what it's going to be read on, why not take COMPLETE control over layout and save as PDF?

For those of us publishing rather than hoarding, Kindle versions are a practical necessity.

[DiapDealer]

Originally Posted by exaltedwombat

Are an appreciable number of us really just creating eBooks for our own personal consumption?

Yes. Quite a lot actually. Probably more than aren't. But you're right, both the publisher-type user and the curator-type user tend to forget the other type exists.

[theducks]

The advantage of the EPUB way, is when you change devices (and you will), it is easy to fine tune for the new device.

With PDF

[Notjohn]

Originally Posted by Turtle91

Please refer to the comments about styling your own HTML TOC - and then saving it so that Sigil will use YOUR style sheet whenever it creates a new TOC.

I didn't know that! Where are these comments, in the online manual?