@DiapDealer
Forgive my mistakes about it and thanks for your needed explanations.
Quote:
Originally Posted by KevinH
.../.. there is no visual difference between a normal space and non-breaking space in most applications .../...
If you simply can not live with non-breaking space as an entity (numeric or named), then use an output plugin to convert them on the fly on the way out of Sigil. If you reload that file in Sigil, it will convert all non-breaking spaces to their numeric or named entity equivalent (depending on epub version).
|
Absurdistan
You said the "there is no visual difference between a normal space and non-breaking space in most applications"
It's certainly true for many applications or languages where the nobreak space is a sparsely used character. But this statement cannot apply to French language texts.
In a book containing usually thousands of nobreak spaces, this confusion causes a lot of visual defects. Many punctuation signs need a nobreak space. If this one is replaced by a plain space, you will spot many of them at the beginning of a line which makes really awful reading. Not to speak with the unhappy breaks of compound names like Louis XIV or Airbus 320 (the same for Boeings). In a French book at least, this provokes big visual differences, a real typographical damage.
This situation (rendering one character with another) is all the more absurd than the
narrow nobreak space is rendered quite normally in Sigil (it's not highlighted in code view). I use it and it replaces about 3/4 of the nobreak spaces and -for me- alleviates in this proportion the current situation. But this does not change the nature of the problem.
Finding a way out: plugin or option?
I currently uses a regex to reprocess files coming out of Sigil on this regard. It's manual though and sometimes I forget to use it.
I did not think about the idea of a plugin (see above). It would need to be coupled with the
export or
save as functions, as well as the
open or
import functions just to convert both ways the current &#_160; used by Sigil for its inner processings to something else (unicode or hexadecimal). It just would need to be automatic because forgetting to use it once could wreak havoc to all nobreak characters (as you say "get bitten by the Qt bug").
As you explained it, Kovid Goyal took an impressive approach to circumvent this bug. As this situation may last some more years, could Sigil, if not following the same path, try to do something about it too? Let me remind you that Sigil does use already a
de facto plugin of sort converting automatically nobreak unicode characters in and out of Sigil...
As this plugin would need to be very² tighly linked with Sigil, maybe adding a different import/export option to mainline Sigil (could we name it the "French" option?) would be the best solution. I certainly could send you a bottle of Champagne for the opening ceremony...
² =very very