KEPUB and non-breaking space

[Vetchy]

Dear community members.
Does any way to connect with Kobo and request to support non-breaking space for KEPUB?

In Russian language (maybe in other too). Direct speach has a
Now, when exist dialog in book, that looks like this:

—I will not accept it!
—Can I speak to the doctor?

But between dash and letter exist non-breaking space. And dialog must looking as:

— I will not accept it!
— Can I speak to the doctor?

That problem not important, when books creat perfectly. But often, I look case, when one dialog looks below:

—I will not accept it!
— Can I speak to the doctor?
— NO!
—Why?

This jumps break my eyes.

[davidfor]

Sorry, from your examples, I can't tell anything. As far as I can see, some have spaces between the dash and first letter, and some don't. If the renderer added spaces where the book creator didn't, that would be a bug. Can you create a small kepub that demonstrates what you mean? A screenshot would also help show what you mean.

As you mention, as far as I've been able to see, the kepub renderer does support non-breaking space. I have attached a test kepub that demonstrates this. This has a lot of different things in it, but at the end of the chapter titled "Various test items", I have put all the types of spaces that I could think of. Each space is named and then put between quotes to show where it is. I have used both the unicode and HTML entity. The non-breaking space is there in both cases.

I've also attached a screenshot of this taken on my Aura H2O using firmware 4.7.10413.

As to contacting Kobo, there are help link includes a way to report problems.

[jackie_w]

@davidfor,

I think Vetchy may be asking the same question Semwize did in this post.

All Semwize's paragraphs were coded something like the following (without spaces):
<p ...>mdash nbsp some text</p>
but because the paragraphs were full-justified the nbsp was not a consistent width.

[Vetchy]

Originally Posted by jackie_w

@davidfor,

I think Vetchy may be asking the same question Semwize did in this post.

All Semwize's paragraphs were coded something like the following (without spaces):
<p ...>mdash nbsp some text</p>
but because the paragraphs were full-justified the nbsp was not a consistent width.

You right. A have this bug.

[GeoffR]

From what I've seen when using the KePub reader, there are three different issues that affect this:

1. As noted above, the KePub reader treats no-break spaces as stretchable (the ePub reader doesn't).

2. Even without a no-break space after the dash, the KePub reader adds a zero-width stretchable space around certain characters, including em-dash and ellipsis(*). This wouldn't be a problem, except that ... (Edit: It is still a problem, it seems the KePub reader now adds this space around quotation-dash too.)

3. ... The correct dash character to use for quoting text is the quotation-dash (U+2015), but most publishers use the em-dash (U+2014) instead.


(*) There is another KePub bug: the space is only added to the right of the characters, instead of both sides, and this in turn can cause the whole line to be incorrectly justified if it contains one of there characters. But this bug doesn't really affect the OP's problem. This bug can be avoided by enabling the text-rendering:optimizeSpeed; or text-rendering:optimizeLegibility CSS options, but doing so has other side-effects.

(It's the accumulation of all these little typographical bugs in the KePub reader that leads me to prefer ePub over KePub.)

[Semwize]

Originally Posted by GeoffR

3. ... The correct dash character to use for quoting text is the quotation-dash (U+2015)

horbar; (U+2015)
Same thing, it's not working right.

[GeoffR]

Originally Posted by Semwize

horbar; (U+2015)
Same thing, it's not working right.

I think that is because you have a space between the dash and the quoted text, which is issue 1.

If you remove the space, then em-dash suffers issue 2. while quotation-dash works correctly.

(You'd suffer the same issues if you has a space between the quote and the quoted text with other quotation styles. "", '', etc.)

[Semwize]

GeoffR,
removed space between the horbar (U+2015) and the quoted text. It got worse. Space between adds, but also stretches

[GeoffR]

Originally Posted by Semwize

GeoffR,
removed space between the horbar (U+2015) and the quoted text. It got worse. Space between adds, but also stretches

Okay sorry, I didn't test it recently, I guess that is another bug to add to the KePub bug list then. (i'll edit my original post to note this.)

The ePub reader recognises the difference between the quotation-dash and em-dash, and although the ePub reader doesn't suffer the stretchy space problems, using the quotation-dash prevents a line break after the em-dash.

[Semwize]

I myself was wondering how to fix it, you said that I haven't tried)

epub yes, everything works perfectly.

[davidfor]

OK, I had a suspicion that Vetchy was referring to this problem, but I couldn't quickly find the other posts.

And the problem isn't that the kepub renderer doesn't support non-breaking spaces, but that it doesn't handle them in the same way as other renderers.

Originally Posted by GeoffR

1. As noted above, the KePub reader treats no-break spaces as stretchable (the ePub reader doesn't).

From my minimal typographical knowledge, I would have said that the way the kepub renderer was treating a non-breaking space was the correct way. To me, the difference between it and a normal space should just be that it prevents a line-break happening at that point. Otherwise, I would have expected it to be stretched in the same way as the normal space when justifying the text. And a quick search doesn't find anything that suggests the non-breaking space should be treated as anything other than a normal space except with respect to line-breaks and whether HTML renders will merge them when there are multiples.

Or is the problem here not how the non-breaking space is working, but how the other characters are? The kepub renderer is putting spacing between the emdash and words when justifying the line. That is apparently wrong. In the screenshot from Semwize, can anyone tell if this is because of the non-breaking space or because of the bad handling of the emdash?

[Semwize]

Originally Posted by davidfor

And a quick search doesn't find anything that suggests the non-breaking space should be treated as anything other than a normal space except with respect to line-breaks and whether HTML renders will merge them when there are multiples.

NARROW NO-BREAK SPACE (U+202F) for example

in kepub also stretches, it's wrong

[cramoisi]

@davidfor : on the principle, you're probably right but i've yet to see an example in a paperbook (and i'm working as a librarian) : in french, it would ruin all the layout when justification and dialog are involved. The narrow non-breaking space should be use (but it's never used) and as @Semwize said, nnbsp are also streched in kepub...


https://bugs.documentfoundation.org/...g.cgi?id=41652
https://bz.apache.org/ooo/show_bug.cgi?id=23333

[davidfor]

Originally Posted by Semwize

NARROW NO-BREAK SPACE (U+202F) for example

in kepub also stretches, it's wrong

I'll repeat what I said about non-breaking space, where does it state that NARROW NO-BREAK SPACE should not be stretched? Again, my search doesn't find anything that makes a statement either way.

And, again, are your sure it isn't what is happening around the character? These seem to be used next to punctuation such as emdashes. The kepub render is putting spacing around these, so that might be where the extra spacing is coming from.

[davidfor]

Originally Posted by cramoisi

@davidfor : on the principle, you're probably right but i've yet to see an example in a paperbook

You mean in a book that didn't rely on on-the-fly rendering to do this? And very likely had someone check things before it went to the printer?

(and i'm working as a librarian) : in french, it would ruin all the layout when justification and dialog are involved. The narrow non-breaking space should be use (but it's never used) and as @Semwize said, nnbsp are also streched in kepub...


https://bugs.documentfoundation.org/...g.cgi?id=41652
https://bz.apache.org/ooo/show_bug.cgi?id=23333

Are you sure you meant to point to those? The report in the first one starts with:

The character “NO-BREAK SPACE” (U+00A0) is incorrectly interpretated like
“fixed width no-break space”.

And most of the rest agrees.

And right down the bottom of this is a link to Unicode Line Breaking Algorithm. And that has the following:

When compression or expansion is allowed, a locally optimal line break seeks to balance the relative merits of the resulting amounts of compression and expansion for different line break candidates. When expanding or compressing interword space according to common typographical practice, only the spaces marked by U+0020 SPACE and U+00A0 NO-BREAK SPACE are subject to compression, and only spaces marked by U+0020 SPACE, U+00A0 NO-BREAK SPACE, and occasionally spaces marked by U+2009 THIN SPACE are subject to expansion. All other space characters normally have fixed width. When expanding or compressing intercharacter space, the presence of U+200B ZERO WIDTH SPACE or U+2060 WORD JOINER is always ignored.

That says NO-BREAK SPACE should be treated the same as a normal space with respect to its width.