non-breaking space

[Frenzie]

I can't find anything in the EPUB spec (although I'm not familiar with it, so that's based just on some skimming and Ctrl+F-ing) that would suggest going against letter and spirit of the HTML5 spec like that.

It sounds like Sigil is merely implementing a workaround against an internal bug (source):

- Update sigil_bs4 to use numeric entities when faced with nbsp so they do not get lost later in Sigil

Calibre says:

HELP = _('Named entities are often only incompletely supported by various book reading software.'
' Therefore, it is best to not use them, replacing them with the actual characters they'
' represent. This can be done automatically.')

That's true, but there's a slight difference between the basic XML named entities (<, >, &, " and ', without which a program can be considered severely defective), HTML basics like   and — which are universally supported, and more exotic ones like, I don't know, bigodot; or something. :P

[cramoisi]

Originally Posted by roger64

Menu de l'éditeur de Calibre: Rechercher/Recherches sauvegardées

Sur la petite fenêtre qui apparait, cliquer sur "Importer" et désigner le fichier insécables.json (préalablement décompressé)

Thanks ! It's working great.

@Frenzie : I was probably taking my experience with xml to xhml... Thanks for the advice with dtd !

[roger64]

Originally Posted by Frenzie

That's true, but there's a slight difference between the basic XML named entities (<, >, &, " and ', without which a program can be considered severely defective), HTML basics like   and — which are universally supported, and more exotic ones like, I don't know, bigodot; or something. :P

Thanks for clarifying this point. Basic XML named entities may be kept. I still see no point to stick to other HTML named entities, including the most famous ones, since we can use universally supported UTF-8 replacements for them, namely for EPUB3 format.

[Frenzie]

In general I would agree. Just because the spec says something doesn't mean I agree with it, but it's still the spec. Why type & mdash ; when you can just type and see —? And what's the point of the aforementioned bigodot anyway? But characters like non-breaking space, thin space, and hair space are slightly different.

Sure, I could set up an easy way to type them. Besides which, Compose, space, space for nbsp is already there, or I could just use a Unicode character table. The problem is that I still couldn't really see them unless I paid extremely close attention — heck, non-breaking space is completely invisible in most circumstances. Is it there? Is it missing? Is it there by accident?

Ah, so just use & # 160 ; Well, I'd suspect anyone who thinks that's better than & nbsp ; of being a computer failing the Turing test.

[roger64]

I never had any problem reading EPUB with Koreader using utf-8 characters in EPUB3 format.

Another reason I dislike using nbsp (as such) as well as & # 160 for French text is because as there are really thousands of them (if you wish to abide by the French typography rules), it makes proofreading even a part of text unpleasant.

Compare it using the Calibre editor with the plain UTF-8. The appearance is cleaner and Turing can't help you on this...

[Frenzie]

Sure, that's understandable. There's a reason I prefer to write Markdown when I can and not XML, LaTeX or HTML. I think it's slightly odd that line-breaking algorithms would all do the wrong thing on "« " and " »". It seems like something that should be easy to automate, even if only in French… But anyway, my point all along has been about HTML5, not personal preferences.

Btw, what do you use to protect against accidental "« " over "«*"? (Assuming those came out correctly.) [Edit: I just noticed that this forum seems to have changed all of my non-breaking spaces into asterisks.)

PS In LibreOffice I just noticed that non-breaking spaces come with a gray background. Not bad. I wonder if I can make Geany do something like that, because obviously nobody would actually prefer an ugly nbsp… it's just that sometimes ugly beats invisible.

[Frenzie]

Alright, this'll be fixed in the next nightly, thanks to poire-z (commit).

[roger64]

A recent comment from one of the the authors of Sigil that maybe of interest:

Originally Posted by KevinH

FWIW, Sigil only uses utf-8 for all text files. If an epub is opened using any other encoding for its xhtml files, those files are converted to utf-8 upon load and from then on always saved in that format.

As regards LibreOffice, I use there only no-break space (utf-8) because the narrow no-break space are supported but stay invisible which make them difficult to check. I convert them only on EPUB where the editor of Calibre gives them a yellow mark.

Congratulations. Koreader is making great progress every single day.