vopash

Oh god, oh god, oh god, it's here in 1.8 release! THANK YOU SO MUCH! I really thought you decided to leave it be, but I was wrong, and I'm so happy now! 😄

I confirm this actually works and is really better than nothing. However, I think fully functional GREP styling is a must in Publisher, since it doesn't require to search&replace after each text edit.

Yay, thank you!

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. 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).

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.

Yes, you're correct. But line composer should recalculate and break the line before non-breaking segment (because why not?).

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 I've made a “no break” character style. It adds a “no break” option to a text, nothing else; very simple. 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: \<(?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: What should happen instead Text should stay in the column (I had to insert non-breaking spaces and clear styles): Affinity Publisher 1.7.2 release version on latest macOS 10.14 release.

GREP Styles is the feature that would totally allow me to replace sluggish InDesign with Publisher. Would love to see it in the nearest updates!

Yeah, of course. Sorry, I'm not native speaker, and my English is not perfect. Thank you.

tl;dr: Every macOS app “knows” to move cursor by word w/ Alt modifier. Publisher (Actually, any Affinity app) requires Cmd modifier, which is inconsistent. Actually, this problem applies to every of Affinity apps, but I won't spawn multiple topics. :) Long version of the problem: Whenever I edit texts in text areas in Publisher, I get stuck with inconsistent modifiers. Publisher requires me to NOT use system hotkeys which work literally everywhere. Even worse, sometimes system modifiers work, and sometimes they do not. E. g., in every app except Affinity apps including Publisher: Arrows ←→ move cursor by a symbol, Delete removes a symbol, Alt+arrows move cursor by a word, Alt+Delete removes a word, Cmd+arrows move cursor to the line beginning or end, Cmd+Delete removes anything up to line's beginning or end. This pattern is simple, elegant, memorizable and works everywhere. In Publisher and any other Affinity app: Alt+arrows alter a symbol's kerning, Alt+Delete deletes a word, Cmd+arrows move cursor by word, Cmd+Delete deletes a line. This inconsistency matters a lot to me, because I work with text in many different apps, and I can't adapt to Publisher's hotkeys at all. I believe it's the single most annoying issue for me. I understand that you won't change the default behavior because it copies (flawed) Adobe's hotkeys. However, since many hotkeys in Publisher are now customizable, I ask for an option to assign my own hotkeys for kerning and support system-wide text navigation modifiers.