patrickfoster Posted January 20, 2023 Share Posted January 20, 2023 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? Quote Link to comment Share on other sites More sharing options...
walt.farrell Posted January 20, 2023 Share Posted January 20, 2023 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. Ben in Texas 1 Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
loukash Posted January 21, 2023 Share Posted January 21, 2023 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. walt.farrell 1 Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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: Quote Link to comment Share on other sites More sharing options...
walt.farrell Posted January 21, 2023 Share Posted January 21, 2023 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. loukash 1 Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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? Quote Link to comment Share on other sites More sharing options...
walt.farrell Posted January 21, 2023 Share Posted January 21, 2023 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. Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. iPad: iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1 Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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. Quote Link to comment Share on other sites More sharing options...
loukash Posted January 21, 2023 Share Posted January 21, 2023 15 minutes ago, lacerto said: Is that a royal we? Walt & me, that makes "we". walt.farrell 1 Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
loukash Posted January 21, 2023 Share Posted January 21, 2023 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. Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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: implications_of_forced_two_words.mp4 loukash 1 Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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? Quote Link to comment Share on other sites More sharing options...
loukash Posted January 21, 2023 Share Posted January 21, 2023 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. lacerto 1 Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
MikeW Posted January 21, 2023 Share Posted January 21, 2023 @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. loukash and lacerto 1 1 Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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 1 Quote Link to comment Share on other sites More sharing options...
MikeW Posted January 21, 2023 Share Posted January 21, 2023 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 1 Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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. Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 21, 2023 Share Posted January 21, 2023 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... MikeW 1 Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 22, 2023 Share Posted January 22, 2023 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). Quote Link to comment Share on other sites More sharing options...
loukash Posted January 22, 2023 Share Posted January 22, 2023 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. Quote MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2 Link to comment Share on other sites More sharing options...
lacerto Posted January 22, 2023 Share Posted January 22, 2023 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]. Quote Link to comment Share on other sites More sharing options...
MikeW Posted January 22, 2023 Share Posted January 22, 2023 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. Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 22, 2023 Share Posted January 22, 2023 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. Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 22, 2023 Share Posted January 22, 2023 Beats me (Windows 11 Pro, v.2.0.3): longversion.mp4 Quote Link to comment Share on other sites More sharing options...
lacerto Posted January 22, 2023 Share Posted January 22, 2023 ...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]: shortversion.mp4 (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.) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.