Jump to content
garrettm30

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

Share this post


Link to post
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

Windows 10 Home, version 2004 (19041.388),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop:  8GB memory, Intel Core i7-3625QM @ 2.30GHz, Intel HD Graphics 4000 or NVIDIA GeForce GT 630M
Affinity Photo 1.8.4.693 and 1.8.4.693 Beta   / Affinity Designer 1.8.4.693 and 1.8.4.693 Beta  / Affinity Publisher 1.8.4.693 and 1.8.4.687 Beta.

Share this post


Link to post
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


MacBook Pro (13-inch, Mid 2012) Mac OS 10.12.6 || Mac Pro (Late 2013) Mac OS 10.14.6

Affinity Designer 1.8.4 | Affinity Photo 1.8.4 | Affinity Publisher 1.8.4 | Affinity Designer Beta 1.8.x | Affinity Photo Beta 1.8.x | Affinity Publisher Beta 1.8.x

Share this post


Link to post
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 online2long.gif
Affinity Designer/Photo/Publisher for Windows • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.8.4.186 • Designer for iPad 1.8.4.4 • iPadOS 13.6 (iPad Air 2)

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
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

Windows 10 Home, version 2004 (19041.388),
   Desktop: 16GB memory, Intel Core i7-6700K @ 4.00GHz, GeForce GTX 970
   Laptop:  8GB memory, Intel Core i7-3625QM @ 2.30GHz, Intel HD Graphics 4000 or NVIDIA GeForce GT 630M
Affinity Photo 1.8.4.693 and 1.8.4.693 Beta   / Affinity Designer 1.8.4.693 and 1.8.4.693 Beta  / Affinity Publisher 1.8.4.693 and 1.8.4.687 Beta.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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).

Share this post


Link to post
Share on other sites

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

Latest releases on each platform 

 

Share this post


Link to post
Share on other sites

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

Latest releases on each platform 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.