non-breaking space

[cramoisi]

Hello,

Is it normal that Koreader doesn't respect non breakable space before some signs ? (in french, we have NBSP before ? ! « and »). I love KR but really, i can't stand a ? or a ? alone at the beginning of the line.

I checked the epub, the nbsp sign was present in utf-8, I change it in html entities with no success (  and  ). Is it a known bug ? I didn't find anything about it...

Regards,
S

[Ken Maltby]

It's been discussed at the project on Github, I don't know if it was fixed or if anyone is working on the issue.

Luck;
Ken

[cramoisi]

One "temporary solution" could be to remove them and glue ? ! etc to the words like in english. But I'm so accustomed to the french typography when i read french... Anyway, thanks for your answer, i will wait and not try any further.
Regards,
s

[Frenzie]

The only reference to non-breaking spaces I've been able to find is here: https://github.com/koreader/koreader...ment-273549019

[cramoisi]

Dealing nbsp plagues my ereading since the first day haha

[roger64]

Hi

  (named entities) are considered to be a thing of the past. I have been using for some years without any problem their utf-8 equivalent, which is \u00a0 or (this is Sigil's choice) & # 1 6 0 ; without the spaces
I also use "fines insécables" (nnbsp) with their utf-8 value without problem, provided the embedded font recognizes this utf-8 character.

You can find one EPUB3 here which displays fine on Koreader and makes use of both.
https://www.mobileread.com/forums/sh...86&postcount=3

I can provide you regex to perform this change if need be.

[cramoisi]

@roger64 : I said nbsp as a shortcut to non-breaking spaces (not for the html entity). I meant \u00a0 or & # 160 ; of course. All my tests with these and french ebooks show that koreader doesn't display them correctly.

I'll will try the epub you linked. I already check it with calibre and it says narrow-non-breaking space which is 8239 that could be the answer


Edit : i checked with different size and i've yet to see an error. Is koreader manage the narrow non-breaking space - 8239 - differently than the classic - 160 - one ? (all my previous tests were based on the classic one) which is the default one when ebooks are publish (it seems to me).


"I can provide you regex to perform this change if need be." => i would be sooo grateful !

[roger64]

Usually, I use nnbsp (fines insécables) because I use embedded fonts and later convert to six-inch PDF. I find them smarter. So I tend to convert most of nbsp to fines.

Of course, some nbsp equivalents are left, namely after "tirets de dialogue".

You'll find lower down the group of regex in .json format that I use with the Calibre editor. You can import all of them and execute them as a group. If you have any question, let me know.

The construction of each regex is very basic.

[cramoisi]

Originally Posted by roger64

If you have any question, let me know.

I got the dummi-est question of all : how do I import the json in the calibre editor ?

[roger64]

Originally Posted by cramoisi

I got the dummi-est question of all : how do I import the json in the calibre editor ?

Menu de l'éditeur de Calibre: Rechercher/Recherches sauvegardées

Sur la petite fenêtre qui apparait, cliquer sur "Importer" et désigner le fichier insécables.json (préalablement décompressé)

[Frenzie]

Originally Posted by roger64

  (named entities) are considered to be a thing of the past.

By whom? There's a whole big list of named character references in the specification (which includes nbsp): https://www.w3.org/TR/html5/syntax.h...ter-references

[cramoisi]

Originally Posted by Frenzie

By whom? There's a whole big list of named character references in the specification (which includes nbsp): https://www.w3.org/TR/html5/syntax.h...ter-references

yes. like & nbsp; the & shy is present ! (I hated these two ) in any way a reader should deal with & nbsp ; \u 00a0 and & # 160 in the same way, nope ? I tested with the three with no success.

Also, the reason people use less & nbsp is because it doesn't validate xhtml or XML in html5 for the only html entities you can have in a xml are & amp lt gt, quot and apos (but it's like my opinion )

[roger64]

Originally Posted by Frenzie

By whom? There's a whole big list of named character references in the specification (which includes nbsp): https://www.w3.org/TR/html5/syntax.h...ter-references

EPUB3 does not make any use of named entities. I can't provide you with the official reference but I trust somebody will.

EPUB3 is supposed to be the replacement of EPUB2... The technical rationale comes from cramoisi.

[Frenzie]

Originally Posted by cramoisi

Also, the reason people use less & nbsp is because it doesn't validate xhtml or XML in html5 for the only html entities you can have in a xml are & amp lt gt, quot and apos (but it's like my opinion )

It most definitely validates as XHTML since it's part of the DTD (see here). In XHTML5 they would be undefined by default due to the lack of a DTD (see here), but as far as valid XML goes you could just copy the old definitions if you wanted to use them. Something along these lines should to the trick.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html [
<!ENTITY nbsp   "*"> <!-- no-break space = non-breaking space,
                                  U+00A0 ISOnum -->
]>
<html xmlns="http://www.w3.org/1999/xhtml">

NB I'm not saying a thing about EPUB.

[roger64]

My sentence was probably too short. I was referring about ebooks use (what else here?).

- Sigil gave up the use of nbsp as a named entity and replaces them systematically by & # 160 for EPUB3 books.
- The calibre editor disapproves the use of named entities and offers systematically to replace them by their utf-8 equivs for all EPUBs.