Nonbreaking hyphen no longer visible in text with the new version of Publisher (2.1.0)

[Explorer]

On the Macintosh operating system, I just noticed that in a document created with Publisher, when I opened it under version 2.1 for the first time, the nonbreaking hyphen character (which I use extensively) no longer is displayed in the text: the character is still there, as a value, but it is as though invisible. This is quite a problem; for the moment, in the one document, I have substituted a simple dash (using the find and replace function en masse), but that is not really a satisfactory solution. Please look into this problem and restore the visibility of this rather indispensable character.

[Alfred]

Are you using the Affinity Store version or the Mac App Store version of Publisher 2.1? Which version of macOS do you have?

[Explorer]

My OS is Catalina 10.15.7. (Also, my Macbook Pro is around ten years old.)

I didn't know there was a difference in the software depending on the source from which it was downloaded. I'm fairly certain I have the version directly from Affinity. Is there a simple way to check this, though?

In the meantime, I made a copy of another Publisher file and opened it under 2.1, and the same problem is visible: the nonbreaking hyphens themselves do not display, though they are still there: so it's just a space that I see instead of them. Obviously, this affects the quality of the text substantially.

[walt.farrell]

1 hour ago, Explorer said:

I didn't know there was a difference in the software depending on the source from which it was downloaded. I'm fairly certain I have the version directly from Affinity. Is there a simple way to check this, though?

There are differences, but I would not expect anything significant in this area of the program. But it's good to know, in case it matters  

In the menu, where you see (probably) Affinity Publisher 2 and the other actions, do you have a Check for Updates when you click on Affinity Publisher 2? If so, that should be the version from the Affinity Store.

[Explorer]

Yes, I have the "check for updates" set to daily.

[MikeTO]

I'm seeing the same issue with Arial, Avenir Next, and a large number of the system fonts in 2.0.4 and 2.1.0. But not all of them, Helvetica and Helvetica Neue are fine. Adobe fonts seem fine.

The non-breaking hyphen appears correctly in v1 with Arial.

I really wish the non-breaking hyphen had a special character dot or hat like other special characters because there's no way to differentiate it from a normal hyphen. Having that blue dot or hat would show the missing dash a bit better than this screenshot which has a non-breaking hyphen between the font name and the word Test.

[Explorer]

Thank you for checking, and it is interesting, the issue that's developed with version 2.1 might relate to specific fonts. (The one I'm using where the problem occurs is not a Helvetica, obviously.) Ideally it will soon be corrected for all of them.

I agree: some special indication of the nonbreaking hyphen, to differentiate it from the other sort, would be helpful.

[Explorer]

P.S. Perhaps the problem was already evident in version 2.0, and I simply did not notice it at that time: that's quite possible.

[walt.farrell]

14 minutes ago, MikeTO said:

The non-breaking hyphen appears correctly in v1 with Arial.

On my system, Arial does not contain the glyph for a non-breaking hyphen, as confirmed by Glyph Browser (V1 and V2) and by the font analysis tool in the Windows-only Babelpad application.

But yes, V1 Publisher does display a non-breaking hyphen glyph in the text when using Arial, and 2.1.0 doesn't.

My guess: There was a fall-back font being used in V1, that is no longer being used in 2.1. This could be a sign of a bug being fixed, or of a new bug being introduced, I suppose.

[Explorer]

Quite possibly the font I'm using does not include that glyph and a fall-back was substituted for it -- but no longer, as you suggest. If so, hopefully the substitution feature will be re-instated in the next update, and soon.

[MikeTO]

Sorry, I wrote that the problem was in 2.0.4 but I forgot I'd just updated my retail copy to 2.1.0 so I don't know when the regression started. I agree with Walt's analysis.

I use Avenir Next for my book and I just checked and I use non-breaking hyphens but I hadn't noticed that they weren't visible in 2.1. If I had lots of them and had to print today I'd have to search and replace all non-breaking hyphens and replace them with regular hyphens with the No Break character attribute applied. But I agree, this is a poor substitute and that this is serious bug to have characters not appear.

[walt.farrell]

3 minutes ago, Explorer said:

If so, hopefully the substitution feature will be re-instated in the next update, and soon.

I am not sure it is appropriate to use a fall-back.

In any case, as an alternative, you can use a regular hyphen, and use the No-Break property in the Character panel or a Character Text Style.

[walt.farrell]

4 minutes ago, MikeTO said:

But I agree, this is a poor substitute and that this is serious bug to have characters not appear.

If the characters do not exist in the font, they should not appear (in my opinion).

But I am a bit surprised that they appear as blank, rather than some box character, unless those fonts don't use a box for their "unknown glyph" setting?

Edit: I am also surprised that Preflight does not give an error or warning about using unsupported characters when using non-breaking hyphen in a font that doesn't have it. This is true in both V1 and 2.1.0. Perhaps another sign that there is a bug?

[MikeTO]

Just now, walt.farrell said:

If the characters do not exist in the font, they should not appear (in my opinion).

But I am a bit surprised that they appear as blank, rather than some box character, unless those fonts don't use a box for their "unknown glyph" setting?

I disagree in this specific case, a non-breaking hyphen should always appear if the font includes a regular hyphen glyph. Apps have been substituting regular hyphen glyphs for non-breaking ones since before unicode. And since it's a regression...

[walt.farrell]

Just now, MikeTO said:

I disagree in this specific case, a non-breaking hyphen should always appear if the font includes a regular hyphen glyph. Apps have been substituting regular hyphen glyphs for non-breaking ones since before unicode. And since it's a regression...

But how do you substitute the glyph appearance, without also affecting the "non-break" aspect of the character? What happens if you select some text that includes it, copy, and paste into some other application? Which type of hyphen do you get?

[Explorer]

8 minutes ago, MikeTO said:

I use Avenir Next for my book and I just checked and I use non-breaking hyphens but I hadn't noticed that they weren't visible in 2.1. If I had lots of them and had to print today I'd have to search and replace all non-breaking hyphens and replace them with regular hyphens with the No Break character attribute applied. But I agree, this is a poor substitute and that this is serious bug to have characters not appear.

I do have quite a number of them in my text and so this new bug does present quite a problem. All the more as the publication is one to which further sections are being added, and hence a "search and replace" operation (with or without the formatting option set to the Helvetica font, for example) would be very cumbersome. -- The automatic fallback as in the early version of the software really should be re-instated.

[Explorer]

24 minutes ago, walt.farrell said:

I am not sure it is appropriate to use a fall-back.

In any case, as an alternative, you can use a regular hyphen, and use the No-Break property in the Character panel or a Character Text Style.

The fall-back is helpful especially in the document I mentioned, as in it I'm using both standard hyphens and nonbreaking ones, and so it would be cumbersome to use the "search and replace" function globally to substitute a hyphen styled with the no-break property. -- In another document I use only nonbreaking hyphens, so there using that global function would be more feasible. Still, I should like to see the older functionality prior to version 2.1 restored.

[walt.farrell]

49 minutes ago, Explorer said:

and so it would be cumbersome to use the "search and replace" function globally to substitute a hyphen styled with the no-break property.

Just in case you need it, Find and Replace should be able to handle living non-breaking hyphens and setting the no-break property. I'm away from my machines, so I can't test whether you'd need to include the characters on either side of the hyphen, too, but either way F&R can do it with regular expressions.

[garrettm30]

7 hours ago, Explorer said:

P.S. Perhaps the problem was already evident in version 2.0, and I simply did not notice it at that time: that's quite possible.

I found this problem as well and prepared some files to start a thread, but having searched and found this thread, there is no need to start a separate thread. But one element I can add to the discussion is that this problem is new with Publisher 2.1. I restored a copy of 2.0.4 via Time Machine to test. Here is a sample file non-breaking_hyphen.afpub when viewed in 2.0.4:

The same file when viewed in 2.1.0:

7 hours ago, walt.farrell said:

But how do you substitute the glyph appearance, without also affecting the "non-break" aspect of the character?

This is not the typical missing glyph substitution where a fallback font is used, but rather this happens at the Unicode level within the same font. The decomposition mapping for U+2011 is defined as:

Quote

<noBreak> 2010 [ ‌‐ ]

I don’t want to pretend expertise in fonts and Unicode here, so someone else who does know these things can confirm or correct, but my understanding is that it means that unless U+2011 is explicitly defined with its own character form, it should use the form defined in U+2010 with the noBreak value applied.

 

7 hours ago, walt.farrell said:

What happens if you select some text that includes it, copy, and paste into some other application? Which type of hyphen do you get?

I tried it with Apple Pages and Microsoft Word. In both cases, the non-breaking hyphen using the same font (here Arial) does show a hyphen and does retain its non-breaking quality. As far as I am able to determine, this is standard behavior for Unicode.

[walt.farrell]

Thanks for the detail on the intended Unicode processing, @garrettm30. That makes sense, and lends additional weight to it being a bug.

[Dan C]

Hi @Explorer,

Thanks for your report and many thanks to @garrettm30 & all others for your further investigations here!

I can confirm that I have been able to replicate this issue on both Windows and macOS and therefore I have logged this with our developers to be resolved.

I hope this helps

[Explorer]

8 hours ago, Dan C said:

can confirm that I have been able to replicate this issue on both Windows and macOS and therefore I have logged this with our developers to be resolved.

Thank you -- presumably then in the next update of the software it will be fixed?

[Pedrober]

Non-breaking hyphen is an absolute must in Portuguese. Please fix this bug as soon as possible. As stated, no problem with Apub V1.

[Dan C]

I can't provide an exact guarantee for when this issue will be fixed, but it will be marked as a higher priority with our developers due to the number of reports - so hopefully this will be resolved in an upcoming beta 

[Affinity Info Bot]

The issue "Non-breaking hyphens no longer render compared to 2.0.4, though does not affect ALL fonts" (REF: AFB-7739) has been fixed by the developers in build "2.1.1.1847".

This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions. 

If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us