garrettm30 Posted July 22, 2020 Share Posted July 22, 2020 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: 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: 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 More sharing options...
walt.farrell Posted July 22, 2020 Share Posted July 22, 2020 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. Seneca, A_B_C and Alfred 3 -- 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 More sharing options...
Old Bruce Posted July 22, 2020 Share Posted July 22, 2020 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. Mac Pro (Late 2013) Mac OS 12.7.4 Affinity Designer 2.4.1 | Affinity Photo 2.4.1 | Affinity Publisher 2.4.1 | 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 More sharing options...
Staff Gabe Posted July 23, 2020 Staff Share Posted July 23, 2020 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. Link to comment Share on other sites More sharing options...
Alfred Posted July 23, 2020 Share Posted July 23, 2020 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. A_B_C 1 Alfred 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 More sharing options...
Staff Gabe Posted July 23, 2020 Staff Share Posted July 23, 2020 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. Link to comment Share on other sites More sharing options...
walt.farrell Posted July 23, 2020 Share Posted July 23, 2020 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. fde101 and A_B_C 2 -- 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 More sharing options...
A_B_C Posted July 23, 2020 Share Posted July 23, 2020 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 Alfred and fde101 2 Link to comment Share on other sites More sharing options...
garrettm30 Posted July 23, 2020 Author Share Posted July 23, 2020 @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. A_B_C 1 Link to comment Share on other sites More sharing options...
MikeW Posted July 23, 2020 Share Posted July 23, 2020 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). Patrick Connor 1 Link to comment Share on other sites More sharing options...
Staff Patrick Connor Posted July 23, 2020 Staff Share Posted July 23, 2020 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 Alfred and walt.farrell 2 Patrick Connor Serif Europe Ltd Latest V2 releases on each platform Help make our apps better by joining our beta program! "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 More sharing options...
Staff Patrick Connor Posted August 6, 2020 Staff Share Posted August 6, 2020 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. Affinity Publisher 1.8.4 for Windows ( Microsoft Store and Affinity Store ) Affinity Publisher 1.8.4 for macOS ( Mac App Store and Affinity Store ) We would appreciate you checking that this issue has now been resolved for you, Patrick Connor Serif Europe Ltd Latest V2 releases on each platform Help make our apps better by joining our beta program! "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 More sharing options...
garrettm30 Posted August 6, 2020 Author Share Posted August 6, 2020 1 hour ago, Patrick Connor said: We would appreciate you checking that this issue has now been resolved for you Yes, this issue is resolved. Thank you. Patrick Connor 1 Link to comment Share on other sites More sharing options...
Recommended Posts