Thread: KEPUB and non-breaking space
View Single Post
Old 01-18-2018, 02:03 AM   #26
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by cramoisi View Post
@davidfor : it does for the one kepub i bought on the store. The result is explicit.
First link : the kobo epub displayed from the kobo desktop :

https://www.dropbox.com/s/2t5orhocyr...38.59.png?dl=0

Second link : the same official kepub displayed in nickel :

https://www.dropbox.com/s/2vslmvwpk5...43.59.png?dl=0
Sorry, I have at no point made any claim that the kepub renderer is not doing something wrong. It is clear from several screen shots that have been displayed of the effect. What I am questioning is what is happening under the covers.

The OP stated that no-breaking spaces were not supported. That is wrong. They are supported and do at least two of the expect functions (act as a space, prevent line breaks).

Semwize is stating that no-breaking spaces are treated the same as a normal space and will be expanded or compressed as needed to justify the text. From the evidence I see, that is not the case. As I have stated several times, I suspect it is the handling of the other characters near the no-breaking space that is contributing the extra spacing and making it look like the no-breaking space is actually the culprit.

If someone wants another way to test this, then create an epub with the following in it:

Code:
<p>m&nbsp;m m&nbsp;m m&nbsp;m m&nbsp;m m&nbsp;m m&nbsp;m m&nbsp;m</p>
But, repeat that enough to flow over more than one line. The change the margins on the device and see what happens to the spacing. If all are always equal, then the no-breaking space is being stretched like the normal space. If there are differences, then they are not being stretched.

But, I'll also state that based on my research, stretching the non-breaking space is the correct behaviour. The fact that no renderer has gotten this correct doesn't keep it form being correct. That means that for languages like those under discussion, it should be done by some other method. Possible a narrow-non-breaking space. Or two. From the discussion a while ago about French, I thought that was the character that should be used.
davidfor is offline   Reply With Quote