Non-breaking space doesn't work?

[SamMN]

I've never tried using them before, so maybe I've made a mistake, but shouldn't "review / inspection" be all kept on the same line due to those non-breaking spaces? (Shouldn't it break the line at "digital" and start the next line with "review"?)

[lacerto]

(...)

[bibliomatic]

Same thing happens to me with the em dash — (alt+0151) in between two non-breaking spaces or two narrow non-breaking spaces.

?

[lacerto]

I could not reproduce the behavior with en or em dashes, though (tested on Windows and latest Publisher). 

Related to use of "No break" attribute, I noticed a possible bug where using a discretionary hyphen (Ctrl + Shift + dash) at the start of a word to prevent hyphenation would also prevent "No break" attribute to take effect.

[bibliomatic]

 

The hyphenation language is set to French, I think Publisher consider the em dash as a hard hyphen (same thing happens with the en dash), so, as in french (I think in english too) it is allowed to make the break at the end of the line just using a pre-existing hyphen, it considers"cavité(NarrowNonBreakingSpace)—(NarrowNonBreakingSpace)la" as a compund word.

It could be solved if the first NarrowNonBreakingSpace is replaced by a simple Space, but then you have to check all the pair of em dashes which go along.

In english language this is not a problem as the pair of em dashes has no spaces before and after and are glued to the text itself.

Perhaps there is some trick to parse all the text and use only the NarrowNonBreakingSpace after the first em dash and before the second em dash, but I'm not well versed in Regex so…

I don't see any reason why Publisher should consider an em dash or an en dash as a hard hyphen in a compound word!

 

[lacerto]

Sorry, I probably misunderstood the problem you have been experiencing. I still failed to reproduce the parallel behavior with en or em dash as was experienced by the OP with the slash character (different behavior compared to Word and InDesign, where the slash character is not divided when surrounded by fixed spaces). In case of en-dash and em-dash, Affinity apps do seem to keep fixed width binds undivided, and allow breaking them only when non-fixed spacing is used. I could not have any difference in  behavior when changing the language between French and US English, so even if there might be certain special considerations implemented in Affinity apps as to attend to specialties in conventions of French typography, this difference does not seem to be applied in this context. 

I do not know if there is software that can automatically attend to the kind of finesse needed in these kinds of situations, or if the desired formatting is something that a professional graphic designer is assumed to handle manually. I am pretty sure that all cultures have their specific "rules" to attend to (and not just nationalities, i mean publisher specific house rules which very often are applied as something "objective and absolute"). At least in Finland we poor graphic designers typically need to do these things manually, though some of us might be clever enough to get some (self-made or purchased) assistance from scripts powered by regex. While the latter is (elementarily) supported in Affinity apps, the former is not, so in lack of this technology, I suppose one must settle with compromises. 

[walt.farrell]

On 10/6/2022 at 5:14 AM, lacerto said:

Related to use of "No break" attribute, I noticed a possible bug where using a discretionary hyphen (Ctrl + Shift + dash) at the start of a word to prevent hyphenation would also prevent "No break" attribute to take effect.

I did a test using the / character as reported in the first post of this topic, and found that the non-breaking spaces did not keep the text together if a / was used, just as reported.

However, putting a soft-hyphen (Text > Insert > Dashes and Hyphens > Soft Hyphen) before the first word in the phrase caused the processing to honor the non-breaking spaces and keep the complete phrase together, even when it had a /.

Using the No Break attribute also seemed to work, but I don't think I ever tried them together.

[lacerto]

4 hours ago, walt.farrell said:

However, putting a soft-hyphen (Text > Insert > Dashes and Hyphens > Soft Hyphen) before the first word in the phrase caused the processing to honor the non-breaking spaces and keep the complete phrase together, even when it had a /.

Yes, that seems to be an alternative method, and in some respects perhaps a better one as soft hyphen can be displayed, and entered from the keyboard, so it is often a faster method of doing this. But it requires then having fixed spaces between all words that are wanted to be kept together. No break is easier to apply if variable length spacing does not matter but certain phrases, words or letters are wanted to be kept undivided.

As for using both soft hyphens and "No break" attributes together, I suppose it typically happens inadvertently (certain single words like names are wanted to be protected from hyphenation, or soft hyphen is used to show the optimal hyphenation point), and then it is good to know that having soft hyphens within a selection where "No break" is wanted to be applied causes the attribute to have no effect. I am not sure if it is a bug but the behavior is not logical or expected (and does not happen e.g. in InDesign).

[Old Bruce]

Can we not just use a Character Style that has No Break as its sole change? Just apply that to the characters, no need for inserting No Break Spaces.

[lacerto]

41 minutes ago, Old Bruce said:

Can we not just use a Character Style that has No Break as its sole change?

Yes, sure (that would also make it possible to use shortcut key for formatting). It is much a question of whether the spaces around the non-breaking slash are wanted to be non-variable in width, or if they are allowed to change freely as needed. No break does not freeze spacing to e.g. standard space on applied text area but allows normal spacing. 

[bibliomatic]

Perhaps, as lacerto has said, there is certain "finesses" a graphic designer must still be accustomed to deal with manually, and consider in this particular case of the pair of em dashes to introduce a pair of tags in a previous step of the workflow so as when you have your text in Publisher you can Find and replace it with the No-Break style (as OldBruce has pointed out) at once, with the same regex as e.g. with italic text.

But, still, I don't quite understand why Publisher would allow a "NarrowNonBreakingSpace" to be the first character of a line in a text box! The purpose of such a character is to prevent the break between both of the previous and next words, but, once this command is overridden, as we clearly see it happens, it could just treat the "NarrowNonBreakingSpace" as a simple space and let it just surpass the text frame at the end of the previous line (as the normal behavior).

[lacerto]

27 minutes ago, bibliomatic said:

But, still, I don't quite understand why Publisher would allow a "NarrowNonBreakingSpace" to be the first character of a line in a text box!

Yes, if I understood what you mean: a fixed space should basically bind the surrounding characters so that division does not happen, or if division is allowed (as it is in OP's example with a slash character), the non-breaking space should not have effect at the beginning of the line, as now happens. I have not, however, been able to reproduce this with en or em dash but do you mean that this happens with certain specific fixed width spaces (like NarrowNonBreakingSpace)? I only tested this with the regular non-breaking space (which I suppose is variable-length, but just non-breaking.)

[bibliomatic]

2 hours ago, lacerto said:

Yes, if I understood what you mean: a fixed space should basically bind the surrounding characters so that division does not happen, or if division is allowed (as it is in OP's example with a slash character), the non-breaking space should not have effect at the beginning of the line, as now happens. I have not, however, been able to reproduce this with en or em dash but do you mean that this happens with certain specific fixed width spaces (like NarrowNonBreakingSpace)? I only tested this with the regular non-breaking space (which I suppose is variable-length, but just non-breaking.)

I mean a non breaking space, whether it's narrow or regular, not quite sure if these type of non breaking spaces are fixed in length or not.

This also happens with the regular non-breaking space (see attached photo).

I use auto-hyphenation, if you are not able to reproduce this with the en/em dashes it has to be something related with my own settings!

[lacerto]

13 hours ago, bibliomatic said:

I mean a non breaking space, whether it's narrow or regular, not quite sure if these type of non breaking spaces are fixed in length or not.

 

Regular non-breaking space is a variable width space, while narrow non-breaking space is not. As you mentioned, both seem to be behaving similarly, and now I managed to reproduce the same behavior with an en and em dash as the original poster did with a slash character (it is just a matter of testing it with text that has enough variation for the calculation that produces this behavior, so I earlier tried to reproduce with the first occurrence of nb spaces and en dash but could not, but now tried it with the second occurrence, and succeeded):

I think that this behavior is buggy, bad typography, which no one desires as a side effect of applying non-breaking spaces. So if breaking a line at an en or em dash, or slash character (and possibly some other) surrounded by non-breaking spaces is allowed, the next line should never start with a space character that has an effect (as long as the space is part of regular flow and not following forced line or paragraph break).

To avoid these kinds of problems, I personally think that breaking at a slash character or en or em dash should not be allowed it they are surrounded by non-breaking spaces (that is, the behavior that is known from e.g. Microsoft Word or InDesign would, IMO, be desirable). I do not think it should be allowed with any other than a regular space (and in those cases an unneeded space is dropped similarly as it is always ignored at line division). If such bindings are causing poor typography (big gaps, or, with text that is allowed to auto-hyphenate, silly divisions where e.g. words bound by non-breaking spaces and a dash are hyphenated at e.g. et two-character length -- there probably is no way to handle these situations other than doing it manually (or using a script + possibly regex, where available). 

It would of course be "nice" if word wrapping could be as smart as doing what was expected, dropping an unneeded non-breaking space (whether fixed length or variable), similarly as is done with unneeded regular space. It would be interesting to know if this behavior is implemented in any page layout or word processing app.  In case of non-nonbreaking but fixed width spaces this would basically be kind of logical behavior, but non-breaking spaces should probably do what they imply: not allowing breaking at points where applied.

(Btw, I can understand that these kinds of typographical needs are not necessarily just "finesses" in French, where there is additional need for white space binding because of how e.g. colon, question mark and exclamation mark are used in the language.) 

 

[lacerto]

I had another look on this issue and found out that using 100% optical alignment on non-breaking and fixed-width space characters when occurring at left edge, might at least partially resolve the problem of such spaces causing an unwanted indentation at the beginning of a line:

 

It is possible to use optical alignment (a character formatting feature) as part of a paragraph style, as above, and it seems that fixed-length spaces do not cause wrapping of the dividing character (en-dash, em-dash and slash character tested), while a non-breaking space can cause it. I have tested this very little but it might be worth an effort to see if this method could really be used to achieve the kind of "smart" space binding discussed above. It is odd how applying optical character alignment on such spaces sometimes causes the space appearing on the previous line (end of line) and sometimes on the next line (beginning of line), but the formatting feature nevertheless works, preventing the superfluous space to have any effect at the beginning of the line. 

Personally I would prefer that non-breaking spaces really do what they imply and would never allow division at points they are used, but allowing division at characters like en-dash, em-dash and slash character, when (no-non-breaking) fixed-length spaces are used, could be quite useful. It should be noted that using optical alignment this way would apply the feature whenever the defined space characters occur at edge locations that trigger the feature, e.g. at tab positions, so it might have unwanted side effects. 

Here is a Publisher file that has most (but not all) special space characters defined to have 100% Left optical alignment, and this feature added in a paragraph style that is then modified to apply to French, Finnish and US English text. The defined space characters show at the end of the first test paragraph in French.

nb_bol_fix.afpub

 

[bibliomatic]

I thank you very much, Iacerto, for all your research on this issue!

I have tried a few of combinations with optical alignment and this could be the most cost-effective way of solving it as you have pointed out.

Previously I had set the optical alignment to None.

Adding your setting of 100% Left in Manual, with the non-breaking space (not the narrow one) solves it partially, because an em dash at the end of a line when it is a "beginning" em dash is not recommended at all. As we can see, Publisher put the non-breaking space out of the text frame frontier. This is caused I think, because, as you have said before and I ignored, a regular non breaking space is width variable, so Publisher adjust it on its own way to obey to this additionnal optical alignment order we have given to it.

 

 

But the thing is that if you give the order to Optical alignment instead, with the narrow one, so a non width-variable character, there you have the best and most conservative output which is to respect the whole train of so supposed non breaking characters: ",(NarrowNonBreakingSpace)—(NarrowNonBreakingSpace)ce" is mantained in the previous line unbroken. Note also that for this second time I have not erased all the Manual Optical Alignment presets that came already in Publisher.

UPDATE:

In another part of the text it still doing the same thing with the narrow non breaking space, so we can conclude that the optical alignment solves the issue partially, and one has to set it manually, however in case of a missed one which acheives to pass unnoticed, the bad effect is considerably lesser for the reader eyes!