02-13-2018, 11:38 PM | #1 |
Wizard
Posts: 2,608
Karma: 3000161
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
|
Display of narrow no-break space (Linux build)
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. |
02-14-2018, 05:58 AM | #2 |
Grand Sorcerer
Posts: 27,551
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Use an entity and add it to your Preserve Entities list if you need visual confirmation of where your narrow no-break spaces are.
|
Advert | |
|
02-14-2018, 08:40 AM | #3 |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
Or change the Codeview font selected in Preferences to one that provides the glyph you are seeking.
Last edited by KevinH; 02-14-2018 at 01:34 PM. |
02-14-2018, 12:33 PM | #4 |
Grand Sorcerer
Posts: 27,551
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
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).
|
02-14-2018, 08:21 PM | #5 |
Wizard
Posts: 2,608
Karma: 3000161
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
|
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. |
Advert | |
|
02-14-2018, 09:19 PM | #6 |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
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.
Last edited by KevinH; 02-14-2018 at 09:21 PM. |
02-14-2018, 09:28 PM | #7 |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
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.
|
02-14-2018, 10:40 PM | #8 | |
Wizard
Posts: 2,608
Karma: 3000161
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
|
Quote:
Edit: mistake. I'll complete this later. Last edited by roger64; 02-14-2018 at 11:07 PM. Reason: mistake with calibre |
|
02-15-2018, 08:06 AM | #9 |
Wizard
Posts: 2,608
Karma: 3000161
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
|
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. Last edited by roger64; 02-15-2018 at 08:14 AM. |
02-15-2018, 08:10 AM | #10 |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
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.
|
02-15-2018, 09:16 AM | #11 |
Grand Sorcerer
Posts: 27,551
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
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. Last edited by DiapDealer; 02-15-2018 at 09:19 AM. |
02-16-2018, 08:04 PM | #12 | |
Wizard
Posts: 2,608
Karma: 3000161
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
|
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. Quote:
Last edited by roger64; 02-16-2018 at 08:39 PM. Reason: link |
|
02-16-2018, 08:37 PM | #13 | |
Addict
Posts: 281
Karma: 7724454
Join Date: Sep 2017
Location: Bethesda, MD, USA
Device: Kobo Aura H20, Kobo Clara HD
|
Quote:
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. |
|
02-16-2018, 08:48 PM | #14 | |
Grand Sorcerer
Posts: 27,551
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Quote:
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). Last edited by DiapDealer; 02-16-2018 at 09:03 PM. |
|
02-16-2018, 11:04 PM | #15 |
Wizard
Posts: 2,608
Karma: 3000161
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
|
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? Last edited by roger64; 02-16-2018 at 11:30 PM. Reason: proposal |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Representing the no-break space | roger64 | Sigil | 11 | 08-09-2017 02:09 AM |
iPad Displaying properly narrow no-break-space (u202F) | roger64 | Apple Devices | 13 | 05-26-2015 01:16 PM |
ePub->pdf: How to narrow space between header and book text? | EbokJunkie | Conversion | 17 | 01-07-2015 02:17 AM |
Narrow No-Break Space display | roger64 | Sigil | 6 | 12-20-2012 02:43 PM |
Narrow No-Break Space and commercial support. | roger64 | ePub | 8 | 09-04-2012 01:08 PM |