Jump to content
You must now use your email address to sign in [click for more info] ×

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


Recommended Posts

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.
 

 

ThinSpaceProblem.gif

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...
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.

Link to comment
Share on other sites

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?)

Link to comment
Share on other sites

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.

capture-002326.png.b2d953cb622e912e092d4fb1235a3b57.png

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.

Link to comment
Share on other sites

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.

capture-002326.png.b2d953cb622e912e092d4fb1235a3b57.png

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.

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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. 

capture-002330.png.d2412899a0ea321190e6ae4e9d912bb2.png

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.