Display of narrow no-break space (Linux build)

[roger64]

Hi

I installed recently 0.9.9. with Qt 5.10 (Linux install on Arch from 8.01.2018).

I realized that the u202f is displayed in Code view like a normal space and nothing betrays its existence. The same file on the Calibre editor displays this nnbsp with a small coloured rectangle.

[DiapDealer]

Use an entity and add it to your Preserve Entities list if you need visual confirmation of where your narrow no-break spaces are.

[KevinH]

Or change the Codeview font selected in Preferences to one that provides the glyph you are seeking.

[DiapDealer]

The short answer is: we're not altering Code View to make invisible characters visible just because "that's what calibre's editor does" (no offense whatsoever to calibre).

[roger64]

Thanks for your answers.

I must also add that the problem has been signalled to me by a friend using Windows.

I routinely insert thousands of nnbsp in my Epubs and previously did not find any display problem with Sigil. One thing is to mark invisible characters, another is to roundly ignore them...

If I add the nnbsp Entity &#x_202f; to the Preserve entity preference panel, it will indeed change them to this character. This means that now I have to execute this SR to convert them back with the Calibre Editor, which I never had to do.

S &#x_202f;
R \u_202f

Please hold on, I sent a detailed report to Doitsu with examples.

* a _ has been inserted in the name to avoid any display tricks.

[KevinH]

Calibre editor can and will replaced named entities if desired. You should not need to use search and replace to handle that. You can also simply remove that entity from your Preserve entities list and Mend All and they will all be replaced by the unicode character they represent.

[KevinH]

BTW, nothing is ignoring them. The correct font glyph for that character is a narrow space. You simply can not visually see the difference in Codeview without using either a numeric or named entity. Either way, the unicode value for that char is generated.

[roger64]

Originally Posted by KevinH

Calibre editor can and will replaced named entities if desired. You should not need to use search and replace to handle that. You can also simply remove that entity from your Preserve entities list and Mend All and they will all be replaced by the unicode character they represent.

Nevertheless it is a new step I did not have to do before. For me this comes probably from an unintended Qt regression because usual nnbsp (\u_202f) were previously always marked by Sigil in code view..

Edit: mistake. I'll complete this later.

[roger64]

After checking and getting some advice, I propose to close this thread. It's possible I may have been confused and I apologize for it. I had this feeling though...

But at least some good is coming from this evil. Here are two infos which may be useful for every user of no-break spaces.

1. How to force Sigil to display automatically a visible nnbsp character in code view.?
Edition > Preferences > Preserve entities > insert "&#x_202f"

2. How to switch automatically all no-break entities to UTF8 ones when opening an Epub with the Calibre Editor?
(that is to change &#_160; to \u_00a0 and &#x_202f to \u_202f)

Tick "Beautify automatically files..." in the Calibre Editor Preferences and forget about it.

[KevinH]

Nothing was marked by Sigil. All Sigil shows in Codeview is whatever the font glyph for that particular unicode point tells it to show. That is always the case. Because some unicode codepoints represent whitespace and can not be easily seen, we recommend using a named or numeric entity so that you can see and verify your own xhtml.

[DiapDealer]

Also note that Code View uses fixed-width fonts only. That has never changed. So while the narrow no-break space will display properly in Preview, it's very likely that it will display as a normal space (albeit non-breaking) in Code View. But that is how it's always been.

Is there any such thing as a fixed-width font with narrow-space support?

Nothing has changed in years (with Sigil) on this particular front, by the way.

[roger64]

I tend to think that there should be no "invisible characters" in Code view. Code view job is to show the code. Point.

This said, if it's good to display "something" to attest the presence of nnbsp, I understand it does not to need to be of the exact width of a nnbsp. To display an entity name in Code view is better than to leave a confusing and undocumented white space. For this reason I find your suggested "preserve entity" solution a clever workaround for this question.

The question of representing exactly the space size is relevant only for Preview and even more so to Book view. That said I shall look if I can find a fixed-width font with nnbsp suppport which can be used in Code view.

nbsp have, at least theorically, a proportional width. For example, this was true with Word 2013 and has been reverted to fixed width for Word 2016 (reason unknown).

Contrary to nbsp, nnbsp do have a fixed width (with variable interpretations ).

Edit: I remember six years ago, using Jellby's advice, I had added support to nnbsp in a Linux Libertine font using fontforge (in other words inserted the nnbsp glyph in an opensource font). Now this is no more needed at least for this font because nnbsp support has much increased but this technique could provide you with an instant solution.

To add the #8239 character, just open your font in FontForge, select the space character (#32, before the !), copy it (Ctrl+C), go to #8239 (View -> Go to, write 8239), paste (Ctrl+V), double-click the character and drag the vertical line somewhat to the left, to make the space narrower. I believe the non-breaking property is implicit, but maybe something else should be done.

https://www.mobileread.com/forums/sh...45&postcount=5

[sjfan]

Originally Posted by roger64

Contrary to nbsp, nnbsp do have a fixed width (with variable interpretations ).

This is not defined anywhere and is subject to change based on what a browser (or word processor, etc) implementation thinks is most aesthetic. Many browsers used to use an unadjusted width for nbsp, but that's changed in recent years because it looks horrible in many common cases. You also noted that Word has gone back and forth on that question. nnbsp could likewise act differently in different programs.

If I wanted a guaranteed fixed width space that didn't break, I'd use one of the defined fixed width spaces (en space, 3-per-em space, etc) inside a span or other element with a "white-space: nowrap" style attached.

[DiapDealer]

Originally Posted by roger64

I tend to think that there should be no "invisible characters" in Code view. Code view job is to show the code. Point.

A narrow non-breaking space is not "invisible." A zero-width joiner is invisible. A soft hyphen is invisible. A narrow non-breaking space is a visible space.

Code View is there to show code. Code contains spaces. Point.

If you want your special space characters to be more visible in Code View, then don't use characters--use entities. We're not going to make them glow, or underline them, or blink at you, or anything else like that.

Code View is going to show the glyph or an entity. Those are the choices.

The very definition of a monospaced font is that all characters occupy the same amount of horizontal space, by the way. Therefore, a monospaced font with nnbsp support, would not BE a monospaced font (which are the only type of fonts Code View supports).

[roger64]

Well, I did not realize that it was a minefield and that your question was a rhetorical one... You can trust me to walk confidently.

Seriously, as I wrote above (but you jumped overboard before reading it), I agree with your "preserve entity" solution for nnbsp and it's OK for me. This way, the nnbsp is not blinking but displayed and identified in Code view.

I think that representing nnbsp in code view by an undocumented white space like today is wrong because it is misleading. The nnbsp, like the nbsp, has to be identified at a glance. Why?

For nearly "historical" reasons. Sigil has been plagued by the nbsp display question for years. Some weeks ago, I opened a thread showing that even the \xa0 hexadecimal suffered from it: using a regex with \xa0 in the replace field is enough for destroying all nbsp and transforming them in undocumented white spaces. So if one finds the same kind of display for the nnbsp, he will probably think they too have been destroyed.

A proposal

Could you consider extending and enabling by default your satisfactory "preserve entity" solution for the nnbsp as well, thus this character could safely be identified at a glance by all users in code view?