nbsp disappeared

[Toxaris]

Wait, you say the nsbp are gone, but when you save it and open it again they are there? Then they are there the first time too, but just not visible as nbsp, but as a space. The nsbp has not been converted to the html entity yet.

[roger64]

@Toxaris

I let you check this by yourself. It looks it's a big EPUB, just only because it's coming straight from the converter with a lot of fonts and a complementary style-sheet that I ordinarily use. I did not modify it because it is important not to save it. I'll explain this at the bottom.

In fact, as you will see, it only contains a page of text with twelve (12)  

To reproduce what I saw.

1. Open this EPUB with deprecated Sigil (ex: 0.5.3). Check: there are 12  
Most important, Do not save!!!. Just close the EPUB.

2. Open the same EPUB with Sigil 0.7.2. There are no  
Most important, Do not save!!!. Just close the EPUB.

3. Open this EPUB with deprecated Sigil. Check: there are 12  

Now, if you save the EPUB with Sigil, it seems you will seal the   fate according to the version of Sigil.
- if you save first with a deprecated version : you will keep your  
- if you save first with 0.7.2: your &nbsp are gone for good.

[yekim54]

@roger64:

(1) I opened chapter.xhtml from your nbsp.epub file in Notepad++ and there were zero &nbsp in the file.

(2) I opened your nbsp.epub with Sigil 0.7.2 and there were zero &nbsp in the chapter.xhtml file.

(3) I opened your nbsp.epub with Sigil 0.6.2 and there were 12 &nbsp in the chapter.xhtml file.

(4) I saved (3) as nbsp_new.epub and opened it in Sigil 0.7.2, and there were 12 nbsp in the chapter.xhtml file.

(5) I opened chapter.xhtml from my nbsp_new.epub file in Notepad++ and there were 12 &nbsp in the file.

Conclusion: it appears Sigil 0.6.2 added 12 &nbsp to your original nbsp.epub file.

[Arios]

Post by roger64
To be frank, I did not believe in this solution.

I was not suggesting a solution, just a way to spot the problem.

Try to open your xhtml test file with AOpen Office (choose Unicode (UTF-8) and you'll see all your non-breaking spaces (you must activate the view of non printing caracters = Ctrl + F10).

Why are they invisible, I don't know, but a similar problem occured here with epub files from neufsix (https://www.mobileread.com/forums/sho...d.php?t=210252) see post # 3, 4 and 7. He has used emacs with Linux to create his epubs, not Sigil and they "showed" (if I may say in this case!) the same problem you have.

[DaleDe]

Originally Posted by yekim54

@roger64:

(1) I opened chapter.xhtml from your nbsp.epub file in Notepad++ and there were zero &nbsp in the file.

(2) I opened your nbsp.epub with Sigil 0.7.2 and there were zero &nbsp in the chapter.xhtml file.

(3) I opened your nbsp.epub with Sigil 0.6.2 and there were 12 &nbsp in the chapter.xhtml file.

(4) I saved (3) as nbsp_new.epub and opened it in Sigil 0.7.2, and there were 12 nbsp in the chapter.xhtml file.

(5) I opened chapter.xhtml from my nbsp_new.epub file in Notepad++ and there were 12 &nbsp in the file.

Conclusion: it appears Sigil 0.6.2 added 12 &nbsp to your original nbsp.epub file.

That would seem a reasonable thing for Sigil to do. In 6.2 it would preserve double spaces by making one a nbsp. 7.2 doesn't do that any longer but as you pointed out it does not remove them either. It would seem that 7.2 leaves the double spaces in the file but does not attempt to preserve them in the output.

Dale

[JSWolf]

Originally Posted by theducks

Why use that construct at all?

If you are starting a new scene and you want a larger space from the preceding paragraph, give it its own class with a larger top margin... just like a FirstParagraph has its own treatment.

p.newscene { margin-top: 200%; }

Even better code...

.spacebreak {
margin-top: 2em;
text-indent: 0
}

<p class="spacebreak">This is is the first paragraph of a new scene/section.</p>

That's all there is to it. No need for 200% which could be too large. Also, one thing I really dislike is p.class type classes. There's absolutely no need for them. without the p. the class can be used in anyplace a class is allowed.

[BobC]

I see similar to roger64. I had a look at writer2xthml and it is quite out of date and only in beta anyway so I took your text and re-created it using LibreOffice 4 with the Writer2Epub extension but with a few spaces changed to what LO uses for non-breaking spaces (control-shift-space).

When I looked at the epub file generated all the non-breaking spaces from the odt document had disappeared and there was only one present - a placeholder in a blank line :

<p>&nbsp;</p>

not something I intended but clearly something that the conversion had inserted. At least it proved that if there had been proper html   entities where I had put them they would have been visible.

HOWEVER where I had a non-breaking space in the original it had A000 rather than 2000 as the hex value in the output.

So I then re-examined your test document and found the same - all the non-breaking spaces are coded as A000 rather than as an HTML entity.

It appears the "deprecated" Sigil would convert the A000 to   whereas 7.2 doesn't.

BobC

[Jellby]

Originally Posted by JSWolf

Also, one thing I really dislike is p.class type classes. There's absolutely no need for them. without the p. the class can be used in anyplace a class is allowed.

There's no need, but no harm either. You already know the advantages of ".scenebreak", so I'd just mention a couple of advantages of "p.scenebreak":

- You can use the same class name for different elements, like "p.title" and "span.title" (which can do different things depending on the particular formatting one is aiming at).

- You know exactly which element the class is intended for, which is useful with long stylesheets or when editing code written by someone else (or by yourself a long time ago).

[roger64]

@yekim

I agree with your observations (which concur with mine) but certainly not with your conclusion.

Originally Posted by yekim54

Conclusion: it appears Sigil 0.6.2 added 12 &nbsp to your original nbsp.epub file.

There is no spontaneous generation...

I can assure you that Sigil 0.5.3 did not add anything. What happened is this: I did insert one by one these nbsp using LibreOffice in an odt file, I converted this odt file using writer2xhtml into an EPUB file.

When I opened this file with Sigil 0.5.3. , I found again -well, no surprise - the 12 nbsp I had created myself in their right place. This has been working this way for the last two years.

It works no longer this way with Sigil 0.7.2

[roger64]

Originally Posted by BobC

I see similar to roger64.

HOWEVER where I had a non-breaking space in the original it had A000 rather than 2000 as the hex value in the output.

So I then re-examined your test document and found the same - all the non-breaking spaces are coded as A000 rather than as an HTML entity.

It appears the "deprecated" Sigil would convert the A000 to   whereas 7.2 doesn't.

BobC

Thanks for this explanation.

[roger64]

@Dalede

Originally Posted by DaleDe

That would seem a reasonable thing for Sigil to do. In 6.2 it would preserve double spaces by making one a nbsp. 7.2 doesn't do that any longer but as you pointed out it does not remove them either. It would seem that 7.2 leaves the double spaces in the file but does not attempt to preserve them in the output.

Dale

I did not create any "double space" and there was no double space. In the odt file, I suppressed the white space and replaced it by a non breaking space (using Shift-Control-Space).

Here you can find the original odt file.

[roger64]

I try to be a little clearer because I believe this is a just a plain Sigil 0.7.2 bug

Bug report regarding Sigil 0.7.2

How to reproduce it.

Take: an odt file (attached nbsp.odt) containing 12 nbsp has just been converted to EPUB (attached nbsp.epub) but not saved, you find it here as it just appeared on the desktop.

Now, open this EPUB and :

- save it with Sigil 0.7.2, all the &nbsp disappear from the EPUB and cannot be found again.
This is the BUG.

- save it with Sigil 0.5.3 (or other deprecated versions); all the &nbsp are maintained and appear for further use, with any Sigil version. This is the normal behaviour and it has been so for years.

NB: 12 &nbsp is not a big deal. True, But a French book, can contain thousands of them and then it can be a serious problem.

[Toxaris]

If what BobC has found out is true, it does not seem to be a bug in itself. If the hex code is different, they are not real nbsp's. The fact that older Sigil version did interpret them like they were seems the bug to me. I think you got the idea reversed.
If I create a html file myself with real nbsp's in them (both coded as entity and real ones), the behaviour is as I expected. They are maintained in any Sigil version I tried.

It seems that the export function you are using is not creating correct nbsp's.

[roger64]

@Toxaris

I make a bug report because this change for the worst is clearly a new behaviour of Sigil 0.7.2 . I do hope that it is something that has just been overlooked and that hopefully it is not intended.

This is the case for "stillborn" &nbsp, I mean &nbsp that have not yet been saved but have been always clearly and easily recognized by older Sigils (and displayed as   ). Forgive me for giving no more technical details of which I am unsure but you can check the test epub with old Sigil... The displayed code is true  

I'd like to get a reply from one Sigil dev on this, because it could well be that other entities are concerned.

The alternative for me would be, once I produce an EPUB file, to save it first with an old Sigil, and to use it later with the new one. Hardly a progress... you guess.

EDIT

I can duplicate this exact same behaviour with Calibre produced EPUB of the same odt file. So you should also add this software to the ones with a faulty export function which is not creating correct   ... I'll attach the files. If you need more examples, just tell me.

[BobC]

Originally Posted by roger64

I can duplicate this exact same behaviour with Calibre produced EPUB of the same odt file. So you should also add this software to the ones with a faulty export function which is not creating correct   ... I'll attach the files. If you need more examples, just tell me.

@roger64 - I also did a conversion yesterday using Calibre and it too renders odt non breaking spaces as hex A000.

Despite this some rendering engines (such as the Calibre viewer) treat the character functionally as a non breaking space and will not break a line there.

The underlying problem seems to be with the odt conversion process. I'm guessing that they all (writer2xhtml, writer2epub and calibre) use the same library. What is needed is a filter that will convert all A000s and similar to the equivalent HTML entities.

It appears that the earlier versions of Sigil carried out this translation on opening the epub.

By the way I have also noted that it's possible in LO to create what appear to be italic characters that don't get converted - I think it is to do with the use of CharPosture=1 which produces a visually slanting character rather than CharPosture=2 which gives a true italic. There may be other characters such as the soft hyphen that don't get properly converted.

BobC