Quote:
Originally Posted by DiapDealer
Because Gumbo (the Sigil html parsing engine) does not grok entities.
|
Thanks. This answers my main question.
Quote:
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.
Quote:
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).