Spaces being altered by Book View in 0.7.4

[Geoff_C8]

I realise this topic has been covered in another thread, but my experience is slightly different, and i thought it worth posting because I suspect many others will discover this the hard way.

I was forced to upgrade from 0.7.1 to 0.7.4 because I had installed Maverick 10.9.1 on my MacBook. I immediately found that making any edits in Book View caused   to be replaced initially by

$#160; where $ is &

and later to just a space. As I had rather lazily used the construct <p height="40">&nbsp;</p> to achieve a certain size spacing, this was eventually rendered useless.

I took the advice given in the other thread to add to my css so that I could create the spaces I needed by adding a class to those elements where a space was needed either above, or below. So I am no longer bothered that this behaviour occurs, although I did have to put in a few hours to recode over 20,000 lines. But I feel sorry for any folks creating books in French.

I have found Sigil a very useful tool, and so I am glad I have a work around.

thanks
Geoff

[Alt68er]

Hi Geoff,

great that you are sharing information / solutions.

But: it still would be greater resp. more helpful (at least for me as newbie) if you would have put a link to the thread where you found the hint for the css-file. I'd like to modify my stylesheet but don't know how.

Please be so kind and post the link.

Thanks a lot,
Peter

[Toxaris]

Just add a margin-bottom or margin-top for a paragraph style and apply that style.

[Geoff_C8]

Originally Posted by Alt68er

Please be so kind and post the link.

Thanks a lot,
Peter

Hi Peter,

As already indicated, a margin top or margin bottom setting is required. This is the code I used, to create two classes that can be used:

 .spacetop {
		margin-top: 3em;
		text-indent: 0
   }

  .spacebot {
		margin-bottom: 3em;
		text-indent: 0
   }

Obviously I could also have modified an existing specific element, but that did not suit me in this case. This code is applied simply by using

<p class="spacetop"> 

or <h4 class="spacebot"> and so on

Geoff

[Alt68er]

Thanks to both of you.

Sorry, but that was a misunderstanding because I thought that you had found a solution for the replacement of nbsp by #160....

But thanks again!

Peter

[DiapDealer]

Originally Posted by Alt68er

Thanks to both of you.

Sorry, but that was a misunderstanding because I thought that you had found a solution for the replacement of nbsp by #160....

But thanks again!

Peter

Unless there's some really strange situation going on (or just an aesthetic preference), there's no real need for a "solution." The named and numeric entities achieve an identical result.

The only way to stop non-breaking spaces (either the character or the named entity) from ever being converted to its decimal entity equivalent (#160) is to revert to Sigil v0.7.3 (or earlier), or to alter the source for v0.7.4 and compile your own custom version.

[Geoff_C8]

Originally Posted by DiapDealer

Unless there's some really strange situation going on (or just an aesthetic preference), there's no real need for a "solution." The named and numeric entities achieve an identical result.

The only way to stop non-breaking spaces (either the character or the named entity) from ever being converted to its decimal entity equivalent (#160) is to revert to Sigil v0.7.3 (or earlier), or to alter the source for v0.7.4 and compile your own custom version.

Well that would be true, excepting I have observed, but not actually discerned exactly what causes it, that eventually all the numeric entities are converted into a real space, and that then means the reader ignores that line. The decimal equivalent is not the issue, and I did note that above, but perhaps not stress enough, its the final conversion into a plain old text space that is the issue. In the first thread talking about this, the OP said it went from &nbsp; to " " In my case it had an interim translation to the numeric equivalent before going to " "

The forum thread I first found this discussed was here: http://www.mobileread.mobi/forums/sh...d.php?t=212681

Geoff

[DiapDealer]

Sorry, I've never experienced the issue of the numeric entity being changed to a normal space in 0.7.4 before. I DO remember there being an issue with previous incarnations of Sigil where the nbsp named entity was being converted to a normal space, though. The thread you linked to was a problem where the unicode non-breaking space character was being converted to a normal space. That was a whole different ball of wax (and since fixed).

The exact steps to duplicate the problem would be helpful if you can nail it down.

[Geoff_C8]

Originally Posted by DiapDealer

The exact steps to duplicate the problem would be helpful if you can nail it down.

Sure thing, but I am not optimistic there, especially as basically I no longer have any permanent &nbsp;

I have certainly seen them disappear to text space at least twice, but it was not at all clear how, or even when it happened. It does not seem to happen "frequently" whatever that means. LOL. I will repost if I figure it. I am going to have to revisit a number of older epubs so its possible I might figure it.

VERY SHORTLY THEREAFTER

Lol and behold. Thinking out loud helped a lot. I don't create the TOC frequently. I just recreated it, and it took my example # 160 and made it into a text space. But it did not touch the &nsbp; in that file. So it looks like a two stage process. Edit in Book View gives you the numeric space, and building the TOC trashes those to text space. BUT, there is something else. Because when I then added a couple of test # 160s and redid the TOC (but there were no new headers) nothing changed. I will come back when I have some more headers in my file and complete this.

Geoff

[Geoff_C8]

Yes that is it. Editing in Book View turns &nbsp; into the numeric # 160 equivalent, and creating a TOC with at least one new heading turns those into text space.

Geoff

[DiapDealer]

I'll see what I can see. For what it's worth, the nbsp being changed to #160 when editing in book view is the expected behavior of 0.7.4. The decision to convert non-breaking space characters and named entities to the #160 numeric entity was just about the sole reason for releasing 0.7.4, in fact.

Obviously, the conversion of those #160s to normal spaces when creating a TOC (under certain circumstances) is an unintended side effect. I assume you mean generating the ncx toc rather than an html toc?

[theducks]

Originally Posted by DiapDealer

I'll see what I can see. For what it's worth, the nbsp being changed to #160 when editing in book view is the expected behavior of 0.7.4. The decision to convert non-breaking space characters and named entities to the #160 numeric entity was just about the sole reason for releasing 0.7.4, in fact.

Obviously, the conversion of those #160s to normal spaces when creating a TOC (under certain circumstances) is an unintended side effect. I assume you mean generating the ncx toc rather than an html toc?

Why would a nbsp be needed in a NCX?
It does not justify.
Not all devices support line wrapping of the NCX TOC so a newline/break is not expected

[DiapDealer]

Originally Posted by theducks

Why would a nbsp be needed in a NCX?
It does not justify.
Not all devices support line wrapping of the NCX TOC so a newline/break is not expected

It's NOT needed.

It's my understanding that the conversions from nbsp to #160 to normal spaces is happening in the html files, not the NCX file. The #160 to normal space substitution is purported to be happening when (re)generating the NCX (and only in those html files where there are new headings to be parsed for the ncx).

I haven't had the opportunity to see if I can duplicate the behavior yet.

[Geoff_C8]

Originally Posted by DiapDealer

I assume you mean generating the ncx toc rather than an html toc?

Yes it goes the moment you create the ncx toc and its happening in the html file that holds the new header that gets indexed. I generally do both, the ncx first, simply because I thought one should. I use the html one, in the file obviously. As I am heading to a mobi file as my final result, I am not sure the ncx is relevant? I have only ever created mobi's.

Geoff

[Jellby]

Originally Posted by theducks

Why would a nbsp be needed in a NCX?
It does not justify.
Not all devices support line wrapping of the NCX TOC so a newline/break is not expected

The fact that "not all devices" support NCX linewrapping is not a reason not no add a nbsp to prevent linewraps in devices that do (if any), is it?