GREP Substitute in Publisher?

[patrickfoster]

I use GREP a LOT in InDesign when doing book layout; I'm especially fond of a search+replace command/script (I'm not a power creator of GREP stuff, so I don't know the exact term) that finds and adjusts paragraphs so that the last line of the paragraph has a minimum of two words. Does anyone have any idea how to replicate that in any way in Publisher?

[walt.farrell]

Find & Replace supports regular expressions, but they are not available via Text Styles, only via command.

And within Text Styles you have Flow options that can prevent widowed last lines, but I don't think there's a control to prevent one-word last lines.

[loukash]

50 minutes ago, walt.farrell said:

I don't think there's a control to prevent one-word last lines.

You can add a non-breaking space via Find & Replace regular expressions.

[lacerto]

Obsolete.

[walt.farrell]

2 hours ago, lacerto said:

Even if GREP-controlled wrapping were possible, I think it would require that words are wrapped as per paragraph (rather than per line) to get even spacing:

I don't see why. We're not talking about how much space exists between words (which is controlled by justification and text-spacing options), but whether you end up with 1 word on the last line, or at least two.

With @loukash's suggestion, you join together the last two words in each paragraph with a fixed-width non-breaking space, and then you know that however that paragraph is wrapped, its last line must have at least two words because of that joining.

[lacerto]

Obsolete.

 

[walt.farrell]

I see there is a difference. I am saying it's not relevant to this discussion. We are not talking about how well the justification occurs across the entire paragraph. Only about ensuring the last line has at least two words.

[lacerto]

Obsolete.

[loukash]

15 minutes ago, lacerto said:

Is that a royal we?

Walt & me, that makes "we".  

[loukash]

Here a "quick'n'dirty" example with a regex pattern just off the top of my head – as I'd have to look up any more "kosher" syntax first:

Some manual corrections might be necessary, depending on text.
When looking at the whole text, any problematic justification parts should be easily recognizable by a skilled typographer's eye, even without paragraph composer. 

Also, there's a bug in APu v2 where the special <NBSP> character isn't displayed as a symbol the the Replace field; but it should.

[lacerto]

Obsolete.

[lacerto]

Obsolete.

[loukash]

5 minutes ago, lacerto said:

So you two are telling what is and what is not relevant in discussion

No.

5 minutes ago, lacerto said:

implying that I am not welcome as a participant in this discussion of yours?

No.

5 minutes ago, lacerto said:

Did you know that you can ignore users that constantly annoy you?

Oh yes. My list is getting longer and longer.  
But don't worry, you're no candidate. I sincerely enjoy and welcome your contributions, even though some are tl;dr (I don't mean the ones in this thread).

Take it easy.  

[MikeW]

@lacerto,

your grep can simply be:

.\S+?$

The Chicago Manual of Style says that single words of 4 or more characters including spaces (but not including punctuation) are acceptable. One can use:

([[:alnum:]][^[:alnum:]]*){4}$

in APub to meet that style manual--or adjust it further.

[lacerto]

Obsolete.

[MikeW]

20 minutes ago, lacerto said:

I must quote this next time I am asked to do something like in my first example (trying to show my "case" with long words, abundantly available in my mother tongue), that is, categorically including two words no matter how long  

Hah hah--even with publishers here in the US, I often cannot "get away" with that.

I believe, if I recall correctly, the issue for that style manual is that 4 or more letters are as long or longer than the recommended first line indent.

Even in ID, I only use the above grep solutions in novel reprints that are destined for paperbacks. Never for first runs or hardcover reprints where there are text changes. And...I almost never use ID's paragraph composer.

[lacerto]

Obsolete.

[lacerto]

Obsolete.

[lacerto]

Obsolete.

[loukash]

I'm not a regex jedi either, but what I've noticed is that while both aforementioned examples will find the culprit, they can only add a No Break character format or character style.
Whereas personally I would rather prefer replacing the whitespace with a "hardcoded" <nbsp> in there, in case I'd need character formats or styles for something else.

[lacerto]

Obsolete.

[MikeW]

4 hours ago, lacerto said:

...

The parts in red are marked with red [i] warning tokens in RegEx Buddy -- I used syntax boost::regex (1.66-1.77) -- I have no clue if that is the version that is the most appropriate in context of InDesign and Affinity apps (I have noticed that the two are not fully compatiblem though). Any ideas?

...

I cannot get \<(\s?(S+)){2}$ to work in RB nor APub. 

Adobe recently changed the boost library from 1.65 to 1.72. And evidently didn't provide backward compatibility and so have broken some plugins. I don't know what Serif uses.

For regular expressions, I pretty much stick to Perl 5.30-5.32 in RB. If the expression works in RB, it works in ID and, so far in my testing, in APub.

[lacerto]

Obsolete.

[lacerto]

Obsolete.

[lacerto]

Obsolete.