Quote:
Originally Posted by Jellby
Those thin spaces should actually be "U+202F NARROW NO-BREAK SPACE". The problems will be the same, some fonts won't support them, but in ePub readers and with modern reasonable fonts it works fine in my experience, I guess it will be the same in Kindle format/readers.
|
Indeed, it does look like the Narrow No-Break Space is technically correct for French (France). And from a quick test in Kindle Previewer, it does look like it handles that space (on the surface, no idea how it handles with Dictionary/Text-to-Speech/Highlights/[...]).
Although as you mentioned, I suspect the Narrow No-Break Space is even less widely available than just the normal Thin Space.
I just used BabelMap to see which fonts have it on my computer:
318 Non-Breaking Space
46 Thin Space
34 Narrow No-Break Space
I would be interested in someone with a thousands of fonts (like Hitch) to give a more comprehensive look at ~ how many of these fonts support the rarer spacing characters. Or to do more extensive testing on actual devices.
Side Note: For French (France), there are also other Typographical rules with Thin/Non-Breaking/Normal spaces around either side of certain punctuations. This question/answer also goes into some details:
https://french.stackexchange.com/que...-the-technolog
(Although while doing research, I ran into odd edge cases of: "(?)" + "[?]" still having zero spacing between the three punctuation marks.)
Side Note #2: I actually went looking into this and ran across the "Unicode Line-Breaking Algorithm" specs:
http://www.unicode.org/reports/tr14/
very interesting stuff. I had assumed (wrongly) that the Unicode Thin Space was already Non-Breaking (like Thin Spaces in LaTeX).
I can't seem to think of any cases in English typography where you would use the Thin Space and WANT it to break there (besides Maths)... although maybe I have just been hanging around in the wrong circles.
Side Note #2: According to the above link, it seems like there is a large class of characters that could also have specific overrides in Line-Breaking rules dependent on Language/Locale.
OR there can also be Program-specific overrides. For example:
I plopped this into LibreOffice/Word/InDesign/HTML:
Code:
This is a sample sentence with Unicode « Thin Spaces. »
This is a sample with Mr. Jones in a sentence. (Thin Space between Mr. + Jones).
I kept on adding characters before the sentence until the end broke and moved to the next line.
Test #1: « + THIN SPACE + Thin
Test #2: Spaces. + THIN SPACE + »
Test #3: Mr. + THIN SPACE + Jones
InDesign CC 2015 + Notepad++:
Test #1: stayed attached.
Test #2: stayed attached.
Test #3: stayed attached.
Microsoft Word 2010:
Test #1: stayed attached.
Test #2: stayed attached.
Test #3: DID NOT stay attached.
LibreOffice + Firefox + Chrome + Sigil Previewer:
Test #1: DID NOT stay attached.
Test #2: stayed attached.
Test #3: DID NOT stay attached.
Internet Explorer 11 + Sigil Code View:
Test #1: DID NOT stay attached.
Test #2: DID NOT stay attached.
Test #3: DID NOT stay attached.
I suspect ereaders should implement more intelligent types of Line-Breaking override rules as well... although again, I haven't done any extensive testing. (And maybe they tweak the algorithm when you add lang="fr" or "lang="fr-CA"... although I doubt it). :P
Side Note #3: I flipped LibreOffice to French, and as you type it Auto-Corrects and inserts a Non-Breaking Space between « ». Nothing besides an ordinary space around the outside edges.
Side Note #4: This type of niggling with spacing could also be taken care of at the Font/Kerning/Program/Justification level.
Side Note #5: Have fun explaining
that stuff to your mom, eggheadbooks1.
"You thought there was just one space? There are MILLIONS! One is normal, one is tiny, and one is even tinier. And then there is big, big, and bigger! Oh, and these are only different when you reach the end of line! Oh, and these only stretch when you turn on Justification, but the others MUST STAY THE SAME SIZE!"
Normal Human: "All I see is a BLANK spot."
You:
