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]

Obsolete.

[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]

Obsolete.

[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]

Obsolete.

[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]

Obsolete.

[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]

Obsolete.

[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]

Obsolete.

 

[lacerto]

Obsolete.

 

[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!