Thin space should be non-breaking and fixed width (.157)

[Heikki Ohvo]

Thank you for adding the extra space characters. 

There are a couple of problems with them though.

1. The thin space should be the non-breaking space, but at the moment it is not. The thin space is used as a thousands separators in many languages and it is an error to split the big number to the different lines.

2. The thin space should be 1/6 of an em in width. It seems to me that now the thin space is about 1/6 of the space in the line where it is situated. When the width of the normal space changes, the width of the thin space changes, too. This is visible with the justified text.
 

 

[Dave Harris]

Hmmm. Looks like I've misread the Unicode standard. From  http://www.unicode.org/reports/tr14/,  the wording is:

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.

which suggests that thin space can stretch. However, later it suggests that is only in mathematical notation. Elsewhere I've read that it can be expanded by letter spacing but not by word spacing.

The Unicode document also includes it in the table of breaking spaces, and other references say it should be 1/5th of an em wide, but InDesign does its own thing. I'll review this. Probably we should be more compatible with InDesign here. Thanks for the report.

[Alfred]

5 hours ago, Heikki Ohvo said:

The thin space should be the non-breaking space, but at the moment it is not.

I don’t think the Thin Space (U+2009) is defined as non-breaking, but the Narrow No-Break Space (U+202F) should be the same width (usually 1⁄5 or 1⁄6 of an em).

[Heikki Ohvo]

People who has used to use InDesign are also used to think that the thin space is fixed width and non-breaking.

[fde101]

Wikipedia to the rescue: https://en.wikipedia.org/wiki/Thin_space

 

Short version:

Unicode THIN SPACE character (U+2009) is breaking, but the NARROW NO-BREAK SPACE character (U+202F) is the same width as THIN SPACE and is non-breaking.

 

Best guess is that InDesign is inserting some version of U+202F instead of U+2009.

[MikeW]

8 minutes ago, fde101 said:

Best guess is that InDesign is inserting some version of U+202F instead of U+2009.

Actually, ID uses U+202F only if it is present in a font. If not present, ID uses U+2009 and sets it to be non-breaking automatically. This applies whether one is inserting a "normal" non-break space or one it calls a fixed-width non-break space. The normal non-break space will compress/expand, the latter doesn't.

[Patrick Connor]

I love expertise  

[MikeW]

2 minutes ago, Patrick Connor said:

I love expertise  

And if ya really wanna get wild, there are space characters that ID applies a formula to for expand/contract that is different than the formula it uses in its optical kerning routine (but I think it is included in the op kern) and elsewhere text is affected (incl. character scaling). It's a published formula if I recall. It affects the amount of expansion/contraction space characters can become in a text run whether justification is used or not in order for its two text composers.

Or sumthin' like that. It's been too long since I learned this crud.

[Dave Harris]

On 11/2/2018 at 5:15 PM, MikeW said:

Actually, ID uses U+202F only if it is present in a font. If not present, ID uses U+2009 and sets it to be non-breaking automatically. This applies whether one is inserting a "normal" non-break space or one it calls a fixed-width non-break space. The normal non-break space will compress/expand, the latter doesn't.

Are you sure? I've not found a font that supports U+202F to check, but it seems unlikely. My Indesign has a menu option that inserts U+202F, which works even if the font doesn't define the character, but it calls it Nonbreaking Space (Fixed Width) and it has the same width as a default normal space. It seems to me Indesign has done something contrary to the intent of the Unicode standard here, by making Narrow No-break Space not be narrow. The references I've found variously say it should be 1/3rd em, 70% em, or similar to Thin Space.

I also notice that Indesign gives Thin Space U+2009 a width of 1/8th em with the default composer, and 1/5th em with the World-Ready composer.

I suspect Indesign always treats U+2009 as non-breaking, and so does MS Word, but Pages treats it as breaking.

There isn't a whole lot of consistency. I currently think it best if Publisher treats U+2009 as non-breaking with a width of 1/5 em. I'm still not sure what width to give U+202f. Currently it is fixed at half the width of a default space.

[fde101]

I would vote for following the standard.  Just because other people are doing it wrong doesn't mean you should, and the standard allows for the various conditions being requested by means of appropriate code points.

To ease compatibility, whenever import from IDML and the like are added, or if it is known that the user is pasting from a program that uses these characters incorrectly, they could be replaced with the correct ones.

Based on the description above, if InDesign is really doing that, I would suggest replacing 202F with 00A0, and 2009 with 202F, when importing from InDesign (and that latter one when importing from MS Word?)

[MikeW]

4 hours ago, Dave Harris said:

Are you sure? I've not found a font that supports U+202F to check, but it seems unlikely. My Indesign has a menu option that inserts U+202F, which works even if the font doesn't define the character, but it calls it Nonbreaking Space (Fixed Width) and it has the same width as a default normal space. It seems to me Indesign has done something contrary to the intent of the Unicode standard here, by making Narrow No-break Space not be narrow. The references I've found variously say it should be 1/3rd em, 70% em, or similar to Thin Space.

I also notice that Indesign gives Thin Space U+2009 a width of 1/8th em with the default composer, and 1/5th em with the World-Ready composer.

I suspect Indesign always treats U+2009 as non-breaking, and so does MS Word, but Pages treats it as breaking.

There isn't a whole lot of consistency. I currently think it best if Publisher treats U+2009 as non-breaking with a width of 1/5 em. I'm still not sure what width to give U+202f. Currently it is fixed at half the width of a default space.

In the screen shot below, I have compared U+202f in both APub and ID. Id will use the font's metrics for the character when present.

Their "invisibles" are all a bit wider and lower set than APub. The current version of the font of mine you have has U+202F a bit wider than it should have been. Basically it was 3/4 of the space glyph, it is now back to a hair less than 50%. (The publications I used it on wanted it wider.)

If I change the font in ID to a font that doesn't have it, the spacing grows to almost as wide of a space character using in the font, but not quite. It can be measured but one really needs to set a short string so ID doesn't adjust the width at all for the space character.

[Dave Harris]

15 hours ago, MikeW said:

In the screen shot below, I have compared U+202f in both APub and ID. Id will use the font's metrics for the character when present.

Their "invisibles" are all a bit wider and lower set than APub. The current version of the font of mine you have has U+202F a bit wider than it should have been. Basically it was 3/4 of the space glyph, it is now back to a hair less than 50%. (The publications I used it on wanted it wider.)

If I change the font in ID to a font that doesn't have it, the spacing grows to almost as wide of a space character using in the font, but not quite. It can be measured but one really needs to set a short string so ID doesn't adjust the width at all for the space character.

Earlier you seemed to be saying that Indesign treats U+2009 as breaking if the font supports U+202F and non-breaking if it doesn't. That's the part I was querying. If I misunderstood and you merely meant that Indesign uses the font's widths for spaces if the font has them, then I agree. Earlier versions of Affinity apps don't do that, but I think the latest Publisher beta does. In your screen shot, the character widths for the first line are the same.

The blue graphics we use when we render invisibles don't need to match Indesign. In fact, some of them are completely different (eg digit space). We also give graphics to characters Indesign doesn't. It's not our intention to make an Indesign clone.

[fde101]

 

On 11/2/2018 at 1:15 PM, MikeW said:

uses U+202F only if it is present in a font. If not present, ID uses U+2009 and sets it to be non-breaking automatically

 

2 hours ago, Dave Harris said:

seemed to be saying that Indesign treats U+2009 as breaking if the font supports U+202F and non-breaking if it doesn't.

If you want to read it that way, it would be the other way around.

However, I was reading that as there being a "non-breaking" attribute that was in effect set independently of the character, as one would set bold or italic on it.

[MikeW]

6 hours ago, Dave Harris said:

Earlier you seemed to be saying that Indesign treats U+2009 as breaking if the font supports U+202F and non-breaking if it doesn't. That's the part I was querying...

That was my understanding. Somewhere I have an Adobe document explaining what ID does in these cases and was working from my (perhaps faulty) memory. (Though what is fun is what ID does when there are no other spaces than the space character, then ID seems to adjust the width of the space character to about 4/5 of the space character for this purpose.)

Some of my first post had a casualty of editing. Such as it is, my point was ID will swap out a missing 202F for another Unicode space slot if those are present and make them non-breaking. This happens internally. ID will encode that non-existent, non-202F space as a 202F space. 

It appears as if you are also determining what to do when a font does not have a 202F character when it is non-existent in a font. Because if I bring in some text from ID via the clipboard and paste as Unicode text where the text font does not have a 202F character, ID sends the encoding that way, there are line length differences. The font used below has few other spaces than the <space> character and does not have a 202F nor 2009. 

Note that ID is using some metric in the event of a missing 202F (etc.) but it is not as wide as a space character. APub is more correctly substituting something but the font has no 202F. So if you can say, what exactly is APub doing here?

6 hours ago, Dave Harris said:

The blue graphics we use when we render invisibles don't need to match Indesign. In fact, some of them are completely different (eg digit space). We also give graphics to characters Indesign doesn't. It's not our intention to make an Indesign clone.

My apologies, I meant nothing of the kind with my statement when I was noting differences in how invisible characters display.

[fde101]

Just a guess, but I would assume that InDesign is actually using the 202F character in the text regardless of the font, and thus has the non-breaking behavior, but if that character is not provided in the font, it is substituting the glyph from the 2009 character when rendering.

[Dave Harris]

Publisher supports most kinds of spaces even if the font doesn't. U+202F is a typical example: if the font defines it, we use the font's glyph and width, and if it doesn't, we use blank space and a hard-coded width.

Indesign invents features, such as flush space, and then assigns them to Unicode code points which it thinks nobody will miss, such as EM QUAD U+2000. I believe that's what it does with U+202F. It figures nobody needs a narrow non-breaking space because their thin space is already non-breaking, so it reuses the code point for a non-breaking fixed-width space. When the text is pasted into Publisher, we do treat it as a narrow non-breaking space so our line length is different to Indesigns.

[Philippe Roy]

Anyway, we need a non-breaking, fixed with thin space. The thin has no utility otherwise, and it's mandatory in many languages.

[Dave Harris]

On 11/20/2018 at 2:18 AM, Philippe Roy said:

Anyway, we need a non-breaking, fixed with thin space. The thin has no utility otherwise, and it's mandatory in many languages.

That is how Thin Space U+2009 behaves in the current beta. And U+202F also behaves like that but with a different width.