nbsp disappeared

[roger64]

@BobC

Glad it worked.

English language makes use of much less "named entities" than French, so, it's not really inconvenient to use them, at least for the purpose of this thread.

[Arios]

@ meme

I am puzzled because I created many french epub with Sigil 0.7.2 containing a lot of non-breaking spaces (of course...) and I never lost one of them.

So I did some quick tests with Writer2xhtml (Win 7 64b and LMDE 64b) and compared the epubs with those produced by AWP (through wine in LMDE): the immediate difference is that Writer2xhtml uses a "xhtml" file extension (not a scoop, I know!) and AWP a "html" one for sections in the epub.

From these few tests my hypothesis is that the export with xhtml extension trigger the loss of non-breaking spaces, simply because there is no lost when using AWP.

Moreover, even if they are invisible, it seems that non-breaking spaces produced by Writer2xhtml and AOO are still active (test done with the PRS-T1).

@ Roger

Roger (or someone else) is it possible to "force" Writer2xhtml to use the "html" extension instead of xhtml to see if my guess is good enough? Indeed, if the files are renamed after export, breaking spaces remain invisible.

[BobC]

If you create an epub with Sigil and use it to insert a non-breaking space it will use the html entity format (   ) this will be preserved through various edits using Sigil or other simple text editors.

The problem arises when a file is being edited where the non-breaking space is the unicode character U+00A0 aka 160 decimal . In this form the non-breaking space simply shows up as a space when the epub is opened with Sigil but is removed if the file is saved (it is not replaced with a normal <space>). If the Unicode form is still present in the epub when it arrives on the reader it will usually be correctly interpreted and not create a problem.

The real problem occurs if you need to edit a file with this "invisible" character in it as it will almost certainly show up as a simple <space>. Libre Office is capable of displaying the non-breaking space as a highlighted space so making it visible when editing. If Sigil could do the same or similar then it wouldn't be necessary to use the html entity form. Even in code view Sigil displays the U+00A0 as a simple space.

Unfortunately Calibre and Writer2Epub both use the Unicode form - as roger64 points out writer2xhtml has an option to use named entities rather than Unicode but this affects other characters as well.

From a quick read of EPUB and XML specs it should be possible to declare nbsp as an entity in the XHTML document to allow it to be used and not fall foul of the validation.

There may also be other characters such as the soft hyphen ( & shy; ) that exhibit a similar behaviour in that they are not normally visible but affect the text flow.


BobC

[BobC]

Originally Posted by meme

The file is encoded okay as UTF-8, and the nbsp characters are in the file stored as two bytes C2 A0 (or 302 240 decimal) as you can see when you examine the file with a hex editor. When Sigil opens the file it correctly identifies the file as UTF-8 and then asks Qt to convert the file to Unicode. Unfortunately for some reason, although it appears to convert everything else ok, Qt converts the 2 bytes to a standard space (20) instead of the nbsp character (A0). So the nbsp characters are removed before the rest of Sigil can see them and convert them to the &nbsp; entity.

@meme

Are you sure the nbsp is stored as C2 A0 - when I looked at it with a hex editor is showed as A0 00 (presumably swap the bytes for endian and read it as simply 00 A0 or 000 160 decimal). This would be correct -


From http://www.w3.org/TR/html4/sgml/entities.html :

<!ENTITY nbsp   CDATA " & # 160 ;" -- no-break space = non-breaking space, U+00A0 ISOnum -->

BobC

[Arios]

@ BobC

What you say is consistent with my observations and Emacs could probably be added to the list, with Calibre and w2xhtml.

I do not encountered the same problem as roger64 because the "Use named character entities" was activated since a long time in my writer2xhtml setup.

Consequently, it is quite possible that this is not strictly connected to the extension, but the way some softwares export entities. But if w2xhtml can export to "html", it could be fun to see what happen.

[roger64]

Hi

@meme

Could Html Tidy be of some help in the meantime?

Here, I've found the two following Html Tidy options about &nbsp; and entities but I do not know how to change their value.

[PeterT]

@roger64: from looking at the Sigil source it would appear that the configuration options passed into tidy are hard-coded within Sigil.

[roger64]

@PeterT

These are bad news. This explains why Tidy is so rigid. It's a pity because it has been conceived with a lot of configuration parameters.

Maybe a Linux user better than me would know how to use the command-line tool. This one can be customized to tidy the xhtml files.

[BobC]

Originally Posted by roger64

Maybe a Linux user better than me would know how to use the command-line tool. This one can be customized to tidy the xhtml files.

Is there not a GUI front end to Tidy for Linux like there is for Windows ?

BobC

[roger64]

Originally Posted by BobC

Is there not a GUI front end to Tidy for Linux like there is for Windows ?

BobC

Maybe, but I did not see it on their site. Anyway, it's not that complicated to tweak. On the "configuration file":

- you only modify what you do not like (it can be as few as two or three values)
- most of them are boolean type (yes/no), or with a preset limited choice.

[RingEbooks]

You should use #160 not "&nbsp;"", in XML.
"nbsp" isn't a predefined XML entity. This works on all tablets I've tested it on.