Jump to content
You must now use your email address to sign in [click for more info] ×

No break word prevents line breaks before such word


vopash

Recommended Posts

In my former InDesign work, I used a “no break” character GREP-style on most texts so I don't have hanging words.Publisher doesn't have such features, however, it does have a regular search&replace allowing to apply a style to matched texts. “That's almost GREP-styling,” — I thought.

So, here's the bug.

Reproduction

  1. I've made a “no break” character style. It adds a “no break” option to a text, nothing else; very simple.
  2. Then, I do a regex search equivalent to this (actually with a longer word list and in Russian) and apply this “no break” style to all matches:
  3. \<(?i:(a |the ))

The rule finds whole words with the following (regular) space symbol. With short words like articles/prepositions/pronouns, it's a perfectly valid rule for finding spaces that shouldn't be broken.

What happens

When selected text has “no break” style, text goes outside the column:

2122115994_2019-09-0118_16_16.png.0767e059ba5be6c124281d22b7cfb1bd.png

What should happen instead

Text should stay in the column (I had to insert non-breaking spaces and clear styles):

381691538_2019-09-0118_18_08.png.480cb73dab8500870cf6a34fe358fd0d.png

Affinity Publisher 1.7.2 release version on latest macOS 10.14 release.

Edited by vopash
clarified software versions, added tags, wording for “what should happen instead”, explained regex rule
Link to comment
Share on other sites

That's because "N Ha ynNUe" can't stay on the upper line (it's strange in the first frame that the "e" is out of the column), and I suppose "ynNUe" is too short for hyphenation?

I thinks it depen of the line composer, if it calculate again or not the line. I can't have text overflowing like you, but if I add "pink_no-break" style, "des" comme to the upper line (even when it seems there's no place for it!).

2019-09-01_202459.png.2ff19cbdee8f84a8b614305f2e7fe433.png2019-09-01_202501.png.6db4f93ab3c8cbb1e00424a0a0009070.png

Link to comment
Share on other sites

32 minutes ago, Wosven said:

"N Ha ynNUe" can't stay on the upper line

Methinks you need a Russian keyboard! ;)

Alternatively, if you type phonetically into Google Translate it will provide the appropriate Cyrillic characters for you; e.g. when you type i na ulitse it will work out that you mean и на улице and it will display it in that form (but this does require you to know roughly how to pronounce the letters).

Alfred spacer.png
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

16 hours ago, Wosven said:

Why before?

It will add hyphenation before or after depending of... perhaps when we modify a line, it's recalculating this line, and if there's too much text or enough space for the next word it'll modify accordingly?

I can't even understand why you're asking. 

I believe it's self-evident that text should be constrained within its bounding box. Because if I needed the text to flow further to the right, I'd extend that bounding box in the first place. 

If there are non-breaking rules, the line should be broken either before or after, provided that the constraints are respected as the first priority. It's quite evident that this line can't be broken after non-breaking words (see the first screenshot), therefore it must be broken before (the second screenshot). When text flows outside of bounds,— when it is clearly possible to respect the bounds,— it is definitely a bug.

Link to comment
Share on other sites

11 hours ago, vopash said:

it's self-evident that text should be constrained within its bounding box.

For sure, but the line composer won't process again all the text, only this modified line and depending of result, try to find a solution. If the new no-break-styled text is longer than the line: it's pushed to the next line (we agree on this).

Lines should be reprocessed from the start point of modifications, to the last line that's been modified because of this modification, or the ones following. I didn't check precisely, but I don't think that APub is able yet to reprocess left/right aligned text to try the best combinations to have even lenght lines.

 

This look like APub is applying justification's letter spacing on the text to fit more than the line width. What are your parameters for those?

Or perhaps it's a problem with this font, does it happen with other fonts? My "s" is half out too, but I had to apply a lot of "no_break" style here and there to get this result.

 

Link to comment
Share on other sites

15 hours ago, Wosven said:

This look like APub is applying justification's letter spacing on the text to fit more than the line width. What are your parameters for those?

Or perhaps it's a problem with this font, does it happen with other fonts? My "s" is half out too, but I had to apply a lot of "no_break" style here and there to get this result.

Default parameters, didn't change anything, save for font and vertical spacing params.

The font is PT Serif. I'll check other ones, but I believe it should be ok, since Paratype usually knows its job.

15 hours ago, Wosven said:

If the new no-break-styled text is longer than the line: it's pushed to the next line (we agree on this).

If that was the case, I wouldn't call it a bug. Surely the composer can't break the line I've made non-breaking one.

However, that isn't the case: on my screenshot, only 1-2-letter words with the following spaces have no-break style, and hyphenation is enabled, so plenty of space to break lines. 

Also, look at the second screenshot: I've cleared the styles on selection and added two non-breaking spaces, and voila, line composer now can break the line, despite I've set the same non-breaking rules (not with the style, but with NBSPs, but still).

Link to comment
Share on other sites

I agree there's a bug here. The bug is triggered by putting No break on the space after the words as well as the words themselves. With that attribute, it can't break before the next word. It does scan back to the start of the No break range, but stops one character too early so doesn't find the break after the previous space. I'll log this to be fixed in a future release.

 

Link to comment
Share on other sites

  • 1 month later...
  • Staff

We believe the issue "Text with "No break" does not always break before the no break" has been fixed in 1.8.0 [Publisher beta is currently available if you care to check]. 

Patrick Connor
Serif Europe Ltd

"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

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

Terms of Use | 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.