nbsp and nnbsp codes

[roger64]

Hi

I have seen recently that calibre's editor changes named entities - and numbered entities - for their unicode equivalent. On a personal point of view, I must say that I like this better than to see the old nbsp pepped all over my texts..

As far as nbsp and nnbsp (narrow ...) are concerned, I have two questions:

1. - could the nnbsp (narrow no-break space) be added to the "Preferred" ones that we can find in the Insert special character window? Can a user add one character among these preferred ones?

2. - calibre's editor gives a "unicode" character to nbsp and nnbsp. I would like to know which one exactly in order to be able to perform a search and replace. Of course, I can copy and paste these entities, but knowing the exact code used by calibre seems to be the normal way.

[kovidgoyal]

http://manual.calibre-ebook.com/edit...ial-characters

[eschwartz]

Also, if you type in   the editor will replace it for you when you type the ";"

[roger64]

Thanks for you instant reply. I see we are living in neighbouring countries and realize that I type quicker than I think...

The manual says that to code the nbsp, I should use a0 and then type Alt+X
a0 is for me typically difficult to find even if I know:
http://www.fileformat.info/info/unic...00a0/index.htm

That's why I am still looking for the nnbsp code even if I know this:
http://www.fileformat.info/info/unic...202f/index.htm

[roger64]

Originally Posted by eschwartz

Also, if you type in   the editor will replace it for you when you type the ";"

This is easier because I failed to see where to type a0 and how to insert it in a regex.

Using the same trick, I found that if I type (without the two -):

&-#-8239

when I add the final

;

the editor will replace it by a unicode hexadecimal character still unknown for me but identified correctly as a narrow no-break-space. I'll try to insert this elusive animal in my preferred characters.

[faltradl]

Originally Posted by roger64

On a personal point of view, I must say that I like this better than to see the old nbsp pepped all over my texts..

I don't understand why the new way should be better.

The old fashoned named entities work everywhere. But codenumbers need the using of the right codepage. A problem, when the device hasn't the used one. There is no automatic conversion. The named entity uses everytime the actual codepage.

I know, unicode shall solve all problems. The reality is, it does not. There is enought software, which can not use unicode, or only a litle part of ist.

P.S.
Ah, i know why you prefere numbers. They are more crytical then shortnames. It's a better sport to remeber numbers than names.

[roger64]

Originally Posted by faltradl

I don't understand why the new way should be better.

This is only my point of view. But I'll try to comment it graphically and not cryptically.

Reading French language texts, you may find thousands of nbsp in one novel. If we use also nnbsp, the previous figure would then be roughly equally split between these two entities.

Now I let you compare what you see when you peruse a French text in code view with the calibre editor (first screenshot) and with Sigil 0.7.3.(second screenshot) If you use the latest Sigil 0.7.4, you'll just replace the   by the &-#-160;

I am sorry but I like better the calibre display even if I have to learn some new tricks. YMMV of course.

This was for display comparison. For the technical bits (why is this better or not), I just trust Kovid Goyal for implementing a no-nonsense solution...

[mrmikel]

@faltradl
There are difficulties with the underlying QT software with named and numeric entities. That is why Sigil bounced back and forth trying to deal with non-breaking spaces. One can either use QT, or spend one's time writing a cross-platform editor completely from scratch and deal with a whole new set of self created bugs.

[kovidgoyal]

Unicode characters work in every single place that entities work. Both unicode characters and entities require a declaration in the header. The DOCTYPE in the case of named entities and the character encoding in the case of unicode characters.

The DOCTYPE is an absolute requirement in order to use named entities in XHTML, while the character encoding is not, since the default encoding for XHTML is UTF-8 when undeclared, which is the encoding the calibre editor uses.

Therefore, named entities are actually *less* likely to work than unicode characters.

[DiapDealer]

And any ereading devices/apps that might have trouble displaying certain unicode characters do so because of glyphs missing from their supplied system fonts. They'd have the exact same trouble regardless if named or numbered entities were used.

There's really no valid reason NOT to use unicode characters as opposed to entities in ePubs/AZW3 (other than personal preference of course).

[roger64]

Originally Posted by roger64

The manual says that to code the nbsp, I should use a0 and then type Alt+X
a0 is for me typically difficult to find even if I know:
http://www.fileformat.info/info/unic...00a0/index.htm

That's why I am still looking for the nnbsp code even if I know this:
http://www.fileformat.info/info/unic...202f/index.htm

Found.

One can type in the calibre's editor search box:
\u00a0 to look for the no-break space (nbsp)
\u202F to look for for the narrow no-break space (nnbsp)

You also can find the latter in
Insérer un caractère spécial/Ponctuation/Ponctuation générale
and bring it up to your "Preferred" using a right click.

[eschwartz]

You can also use the Character Map in the editor to type in any character, specifically, this will put the character in the search bar (assuming your input is focused in the search bar, obviously.)