Quote:
Originally Posted by konstantinus
Here is the book file.
Attachment 168090
It contains non-breaking spaces:
Attachment 168091
After conversion, they are replaced by & # 160;
I managed to leave them in their original form only with the help of the command in powershell. Maybe there really is a problem in the system settings, I don’t know.
P.S. The presence of characters & # 160; in the text leads to the following result:
Attachment 168092 |
Perhaps you might want to check the following post (or the entire thread it comes from). The renderer used by Kobo for kepubs has some issues with non-breaking spaces. See GeoffR's post (
GeoffR post 5 ) or the entire thread at
KEPUB and non-breaking space for more information.
I did some testing with a file which has numerous non-breaking spaces and after conversion to kepub, it didn't matter if I had the character or numeric entity as far as how the display looked.
I'll double check this with the book you attached but suspect I will see the same behaviour.
Edit: I looked at the epub file you attached. The non-breaking space used was the numeric (#160) form despite no Kobo spans or other evidence that it had been converted to kepub. I did a quick bulk replace in Sigil and tried a kepub conversion. The & nbsp entities were all converted back to numeric entities so I edited them back to & nbsp. I've attached that file here though the kepub seems to have been shrunk to k.
One other item is that before and after conversion, the file made both Flightcrew and epubcheck very unhappy. You might to check and fix those errors—garbage in, garbage out comes to mind. fb2mobi.py does not seem to do a very good job of generating epub code.