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

Thin space is breakable in 1.8.4 beta


Recommended Posts

The "thin space" is treated as a breaking character in the 1.8.4 betas, whereas it was previously a non-breaking character, such as in the 1.8.3 release.

When I open the attached document in Publisher 1.8.3 release, this is what I see:

1352895336_release1.8.3.png.2101707fa91c849fd2cce7c395a3c443.png

But when I open the same document in beta 1.8.4.687, I see the question mark (last character in the frame) has been separated from the word it precedes:

334234961_beta1.8.4_687.png.b3b1dedbfdefbbc3f15f6b373c698c06.png

I have only noticed it today in beta 687, but I am sure it goes back to one of the earlier betas, because I have a printed document that was printed some weeks ago with an earlier beta.

Edit: I should have noted that I am on an iMac with macOS 10.14.6.

breakable_thinspace.afpub

Link to comment
Share on other sites

Perhaps they've fixed a bug?

If you want a non-breaking thin space shouldn't you be using the Narrow Non-Breaking Space character instead? That's U+202F, and is supoorted in both 1.8.3 and 1.8.4 beta via Text > Insert > Spaces and Tabs. It's noted in a recent (or proposed?) version of the Unicode standard as the space that's intended before punctuation in French, and for other uses.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

I see the same thing but I have to ask if there is a reason you don't use the Narrow Non-Breaking Space, seems to take as much space as the thin space.

617564909_ScreenShot2020-07-22at1_47_04PM.png.f4c43b5bcecd41a58a03bf4abb6a8a29.png

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

8 minutes ago, Gabe said:

Hi all,

U+2009 should have been a non-breaking character, as it was in 1.8.3. We don't think the change was intentional. Issue logged. 

For what little it’s worth, I agree with Walt: I don’t think it should be non-breaking.

13 hours ago, walt.farrell said:

Perhaps they've fixed a bug?

If you want a non-breaking thin space shouldn't you be using the Narrow Non-Breaking Space character instead? That's U+202F, and is supoorted in both 1.8.3 and 1.8.4 beta via Text > Insert > Spaces and Tabs. It's noted in a recent (or proposed?) version of the Unicode standard as the space that's intended before punctuation in French, and for other uses.

If you prefer not to use a Narrow No-Break Space (U+202F) you could use a Thin Space with a Word Joiner character (U+2060) on each side.

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

1 minute ago, Gabe said:

This is because of its use as a separator in numbers, where it really needs to be non-breaking. Both InDesign and MS Word treat it as non-breaking. 

But that can be accomplished by the user (or the program) using a Narrow Non-Breaking Space in that context and others that need it.

If Thin Space is always non-breaking, then how does someone who wants it to be able to break accomplish that? (In other words, there's a broken/missing function if Thin Space is non-breaking.)

It might be more appropriate for Affinity to convert thin spaces to narrow non-breaking spaces when importing DOCX or IDML files, and leaving Thin Spaces working as they're defined (breaking), if you want compatibility with Word and InDesign.

 

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

33 minutes ago, walt.farrell said:

If Thin Space is always non-breaking, then how does someone who wants it to be able to break accomplish that? (In other words, there's a broken/missing function if Thin Space is non-breaking.)

It might be more appropriate for Affinity to convert thin spaces to narrow non-breaking spaces when importing DOCX or IDML files, and leaving Thin Spaces working as they're defined (breaking), if you want compatibility with Word and InDesign.

Yes. I’m also inclined to support that. Otherwise we’ll be perpetuating a practice that doesn’t seem to in accordance with the specification, as I would understand it. Indeed, what Walt said about the use of U+202F in French typesetting is already in the standard.

Unicode-Spaces.pdf

Link to comment
Share on other sites

@Gabe I have tested further, and I found that the following spaces that are non-breaking in 1.8.3 are breaking in the 1.8.4 betas: thin space, hair space, sixth space, quarter space, third space, punctuation space, em space, and en space. As you mentioned InDesign and Microsoft Word, I likewise tested them. Indesign treats all of these as non-breaking the same as Publisher 1.8.3, while MS Word does the same except for em space and en space, which MS allows to break. Additionally, InDesign treats zero-width space as non-breaking, while MS Word along with Publisher in both beta and release treat it as breaking. I am inclined to agree with InDesign's behavior on that point, as otherwise I do not understand why both the zero-width space and the zero-width non-joiner exist if they are both breaking.

To my fellow members for the amusement of general discussion, the history of these spaces has been troubled by the fact that the Unicode Consortium neglected to assign non-breaking quality to these characters, evidently in error. It has therefore put the Unicode standard at odds with the traditional usage of these characters, which surely contributes to the confusion such as the disparities among various software as I partially reported in the paragraph above. There has been recent proposal to fix the problem, but I do not know whether anything will ever come of it:

http://www.unicode.org/L2/L2019/19115-fwsp-usability.pdf

Whether or not Publisher should change to conform to current unicode rather than to tradition may be debated, but I would hope that Serif would not intentionally make a layout breaking decision in a double point update. Even if the user is aware of the change, simply swapping out thin space with U+202F is extra work beyond simple find and replace, because the widths are not equivalent and so reflow will happen. Such changes should be reserved to the bigger updates where layout changes are more often expected.

For the record, I experimented with using U+202F instead of thin space several months ago, but I reverted my decision when I ran into some comparatively significant issue. Sadly I can't remember what it is, but in fonts and in browser space, U+202F has not been supported to the degree where it can be used with confidence. Layout programs have generally been more faithful in this regard, whether thin space or U+202F is used.

Link to comment
Share on other sites

The PDF is a poorly worded proposal/argument.

Personally, I think this issue highlights some of the Unicode Consortium's problems with definitions where usage is defined. It's great they have the various space characters defined. But sometimes they should not attempt to define how they are used when problems like these can (and should in my opinion) be resolved at the text composition engine.

There is nothing stopping an application developer from making any defined space character have a non-breaking property. There is nothing stopping an application developer from calculating missing space characters having their widths calculated from the width of the space character (I believe APub does this anyway in one or two instances in the case of particular missing space glyphs).

Having defined "this space's Unicode value is X wide and doesn't break, but this other space's Unicode value is the same width as the other and does break" has created this problem. Letting the application developers resolve it in their respective text engines would have prevented changing, or adding yet more, rules in this instance (and there are loads more of this type of thing).

Link to comment
Share on other sites

  • Staff

I believe this code was changed in APub 1.8.4.663 beta to fix something else ("Fixed spaces should be line break opportunities" our ref AFB-3767)

Quote

Fixes for line-breaker around Fixed Spaces

 

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

  • 2 weeks later...
  • Staff

We have made fixes/improvements to this area (Thin space U+2009 and many others stopped being a non-breaking character) of the program in the latest release.

The fixes and how to update are described in these forum posts.

We would appreciate you checking that this issue has now been resolved for you,

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

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.