Spaces being altered by Book View in 0.7.4

[HarryT]

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.

Why on Earth would anyone want to change the readable   into the meaningless #160? What's the benefit?

[HarryT]

Originally Posted by Geoff_C8

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'm sure you know this, Geoff, but "<p height="40">" is Mobi markup, not ePub. It's also horribly dependent on the resolution of the device - much better to specify a margin in em units, not pixels.

[DiapDealer]

Originally Posted by HarryT

Why on Earth would anyone want to change the readable &nbsp; into the meaningless #160? What's the benefit?

It wasn't really a case of "want." There's been lots of previous discussion about the reasons, Harry, but the short answer is that: quirks of Qt and the various Sigil libraries/features that require xhtml to remain well-formed at all times actually conspired to create invalid xhtml under certain conditions.

The benefit is that source documents that contain the unicode non-breaking-space character (which won't survive in the Qt editing widget) can be opened/imported without breaking the well-formed "rules" (which is what was happening when non-breaking-space characters were being converted to the nbsp entity in documents with no Document Type Declaration).

I agree it's probably not optimal, but without a major overhaul of Sigil's codebase/structure (which doesn't seem likely at this point), using #160 rather than nbsp was simply the quickest band-aid for a hairy problem.

[HarryT]

Thanks - I must have overlooked those discussions.

[DiapDealer]

The good news is: if you don't deal with the unicode non-breaking-space character at all (and all your html files contain the "standard" XHTML 1.1 DOCTYPE declaration), you can continue to use Sigil 0.7.3 with no issues (it's what I do). The #160 vs nbsp handling is the only real functional difference between 0.7.3 and 0.7.4.

(0.7.4 also represents the first disk-image available for OS X in a while, but that's another issue entirely).

[DiapDealer]

Originally Posted by 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

Sorry, I can't replicate the problem. I've tried every which way I could think of (different clean-source settings, new headers, saved/unsaved), but I can't get the #160 entity to do anything except stubbornly remain a #160 entity--when generating the ToC or any other activity. Nor can I find anything in the code that would cause that to happen (which doesn't rule out a Qt bug of some kind). Tried on Windows and Linux.

I would guess it might be limited to the Mac version of 0.7.4 which was built with an early beta version of Qt5.2 (because previous versions of Qt5's packaging tools had broken user_none's method of creating the OSX packages).

Perhaps someone might be able to build an OSX app package with the latest Qt5.2 release and see if the problem goes away? Sorry I couldn't be more help.

[theducks]

Originally Posted by Jellby

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?

Agreed (at least in theory. A NCX that needs line wrapping is going to be a pretty unfriendly on a small screen).

[Geoff_C8]

Originally Posted by DiapDealer

Perhaps someone might be able to build an OSX app package with the latest Qt5.2 release and see if the problem goes away? Sorry I couldn't be more help.

OK, if I get a newer release at some time, and I see the issue has gone away, I will update this thread. Thanks anyway. My alternative is to get my son to build it, he has the tools to do that.

By the way, in my version there is still an "Insert Special Character" option for &nsbp; which is a bit at odds with your statement that the expected behaviour is to replace this? Has that been changed as well?

Geoff

[Geoff_C8]

Originally Posted by HarryT

I'm sure you know this, Geoff, but "<p height="40">" is Mobi markup, not ePub. It's also horribly dependent on the resolution of the device - much better to specify a margin in em units, not pixels.

Thanks. Actually I am an epub virgin. Only just released some free epubs but I never viewed them. I will need to be more careful.

Geoff.