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]

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:

 

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

30 minutes ago, walt.farrell said:

I don't see why.

I can see that you cannot see 🙂 My example uses identical spacing settings and forces at least two words on the last line (it does not use forced line breaks). The difference is that InDesign uses paragraph composer to calculate even spaces. There is no such feature in Affinity apps.

Here is a clue: top paragraph uses Adobe Paragraph Composer, the bottom paragraph Adobe Single-line composer. See the difference?

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

8 hours ago, walt.farrell said:

We are not talking about

Is that a royal we? Of course there is point in showing implications of a feature that is wished to be automated. Even if it were available, it would often work poorly within Affinity apps because it would inevitably cause issues with word wrap, unless there is a counter-measure like paragraph composer that alleviates problems caused by forcing at least two words on the last line of a paragraph. That is, automation in one region requires manual adjustments in another (typically with manual hyphenations or prevention of hyphenation of single words, until balanced wrapping is reached). I really cannot see the point of policing around the arena and trying to dictate what exactly belongs and what does not belong in the scope of each topic. 

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

Here is my take, I'll bet it is deemed too straight forward on this forum even if it IS a work around. I suppose it is not off-topic, though:

[lacerto]

50 minutes ago, loukash said:

Walt & me, that makes "we".

So you two are telling what is and what is not relevant in discussion and implying that I am not welcome as a participant in this discussion of yours? As you both are addressing these silly comments to me, there seems to be some ontological problem. Did you know that you can ignore users that constantly annoy you?

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

15 minutes ago, MikeW said:

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

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  

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

8 minutes ago, MikeW said:

4 or more letters are as long or longer than the recommended first line indent.

Yes, we have (mostly in vain) tried to base our non-two word exceptions on these kinds of typographic "excuses"! But first line indent definitely makes the gap worse, and is probably the prime cause for this "rule of thumb", expanded into a categorical rule.

[lacerto]

On 1/21/2023 at 6:17 PM, MikeW said:

And...I almost never use ID's paragraph composer.

It is not that useful in English (as prepositions and articles most often give you balanced wrapping even when not using hyphenation). In languages like Finnish it is a different thing as there are practically no prepositions nor articles, and compound words are written together without a space or a hyphen. In texts where the publisher is likely to comment e.g. English hyphenation, it would be a kind of a professional suicide to use paragraph composer, since correcting one point typically causes immediately multiple points that potentially require correction...

[lacerto]

On 1/21/2023 at 5:37 PM, MikeW said:

your grep can simply be:

.\S+?$

I still played a bit with this. I am pretty poor with regex, but noticed that there is a useful difference between the two versions:

I had picked the first one from the Internet so not my "own work". I am not sure if the syntax is correct even if it works. When I put it in Regex Buddy, it explains it as follows:

• Assert position at the beginning of a word (position followed by but not preceded by a letter, digit, or underscore in the active code page)
• Match the regex below and capture its match into backreference number 1
  • Exactly 2 times
    • You repeated the capturing group itself. The group will capture only the last iteration. Put a capturing group around the repeated group to capture all iterations.
    • Or, if you don’t want to capture anything, replace the capturing group with a non-capturing group to make your regex more efficient.
• Match a single character that is a “whitespace character” (any space in the active code page, tab, line feed, carriage return, vertical tab, form feed)
  • Between zero and one times, as many times as possible, giving back as needed (greedy)
• Match the regex below and capture its match into backreference number 2
  • Match a single character that is NOT a “whitespace character” (any space in the active code page, tab, line feed, carriage return, vertical tab, form feed) (matches no characters outside the system code page)
    • Between one and unlimited times, as many times as possible, giving back as needed (greedy)
• Assert position at the very end of the string

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?

Anyway, both options are useful (both examples allow hyphenation and have identical hyphenation settings).

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

2 hours ago, loukash said:

Whereas personally I would rather prefer replacing

Personal preferences vary of course. I prefer a style toggle, not anything hard coded. The style variance can also control hyphenation, without touching hyphenation settings [besides: alt formats can be handled by alt styles or simply as local overrides if not applied consistently].

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

49 minutes ago, MikeW said:

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

Odd, I just tested with v1 Publisher document and both versions appear to work:

regex.afpub

Both versions also work in ID CS6 as RegEx styles. But as you mention, the long version does not work in RB.

[lacerto]

Beats me (Windows 11 Pro, v.2.0.3):

 

 

[lacerto]

...and here is the short version (that counts a hyphenated word as a word on the next line). It works even if it shows "inadequately" the found instances [not actually since the preceding space is selected and when marked non-breakable is enough to bind the preceding word, but does not prevent hyphenation]:

(As above, Windows 11 Pro, APub 2.0.3; I have tested 1.6.10 version, Win, too, and it works similarly; I have not tested macOS versions so far.)