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

Publisher v2 - GREP styles


Recommended Posts

There's been a longstanding request in the Publisher v1 forum to add GREP into Text styles. I was excited to see the announcement about v2 but saddened to see this didn't make it in. Since the feature isn't there (yet? :) ) and since those v1 forums are being archived, I'm bringing the request into this new forum to keep it alive.

For a specific kind of technical document I work with, there are dozens of types of replacements that need to happen on the text in new docs, within one text style. Having the GREP expressions in the style definition makes all of these replacements happen in one click of applying a style, rather than a laborious effort to do them individually.

I understand that this isn't a mainstream feature, but it's so, so helpful to those that need it. Since the engine is already in the software, it seems like it shouldn't be a huge deal to be able to attach GREP search/replace expressions into a text style. I could be wrong, of course, as I'm not a developer. But I (and many others) would very much appreciate this coming in a new update.

 

Edited by michaelschutz
grammar
Link to comment
Share on other sites

I couldn't agree more. Finally, we have footnotes, but the lack of style mapping during text import, GREP styles, more robust nested styles, custom variables, and the possibility of saving find/replace searches keeps InDesign way ahead regarding (semi)automatic formatting. I'd love to see more text-oriented features in future updates.

Link to comment
Share on other sites

9 hours ago, Aidymouse said:

Man, really on the fence about diving into the whole v2 suite, but GREP styles are really holding me back. 

Well, if GREP styles are coming, we know for sure that it won't be in v1. So maybe you should still get v2? Especially since it at 40% off.

Half the reason why I got v2 was to encourage Serif against Adobe.

Just for fun, let’s run some numbers. (Prices will be in Canadian dollars.)

I bought Affinity Designer in January 2017 for $70—that’s about 70 months ago. Adobe’s plan for Illustrator is currently 28$/month. Having illustrator would’ve cost me something like $1,960. Corel Draw is a bit cheaper, at $550 (pay once).

I got Designer in January 2017 ($70), Photo in March 2017 ($70), and Publisher in June 2019 ($48), for a total of $188. If I were to want to use their Adobe equivalents (Illustrator, Photoshop, and InDesign), I'd have to get their $72/month plan. From June 2019 to now there’s 41 months. It would’ve cost me a staggering $2,952.

Anyway. I think Serif’s products are by far the best value on the market. I'm dearly missing some features like GREP and vector tracing—and I understand if these things are deal breakers, esp. if you work as a professional designer. But I know I'll stick around for sure until they’re finally implemented.

Link to comment
Share on other sites

  • 3 weeks later...

As V2 finally supports Footnotes I‘m actually able to make the switch from InDesign to Affinity Publisher, but without grep styles it still is quite a lot of work to get the same results as before. I would really be nice if Serif could include this functionality in a future update to V2.

Link to comment
Share on other sites

On 11/10/2022 at 1:27 PM, michaelschutz said:

it seems like it shouldn't be a huge deal to be able to attach GREP search/replace expressions into a text style

You can already do a one-time search/replace with regular expressions (being mislabeled as "grep" expressions in this and various other threads), but as far as dynamically applying styles as text is entered and modified, there are performance ramifications involved as well as a possible concern with ambiguity which can both make this more complex than you seem to think.

Consider an expression such as "begin.*?end " (note the space at the end) which has caused a large block of text, maybe even several pages long, to have a conditional style applied to it.  Now go somewhere in the middle of this large block of text and type the word "ending" just before an existing space character.  

Each character that you type would require Publisher to at least partially  re-evaluate the expression against the modified text in order to determine if it still matches the expression.  Given the general nature of regular expressions, this is a non-trivial check for a typical engine that was designed to do one-off searching as is possible for the Find and Replace panel: there are so many different ways that an expression could evaluate (particularly with optional parts within the expressions) that the amount of work involved could grind Publisher to a halt, so it may be that Serif actually needs to rewrite the entire regular expression engine to be able to do this efficiently and correctly, so that it can dynamically adapt to small changes within long blocks of text (in the absence of which this feature would be less interesting) and not grind to a near-halt.  

Once you hit the "d", with the space character after it, the match changes the style: everything after the space character needs to be restyled and redrawn as no longer being part of the conditional style, which might cause text to re-flow if the size or font changes (for example).

Then when you hit the "i", the word no longer marks the end of the matched block, so the text after the space needs to be restyled again back to what it was in the first place, again possibly triggering a large amount of text to be redrawn, along with a possible re-flow.

In entering this one word there would have been two consecutive characters which changed the end of the matched region back and forth and caused adjustments to a large block of text.

 

Now consider that a second such style is present in the same document (meaning they BOTH need to be similarly evaluated with each character typed into the text flow).  Let's use "abc.*?xyz" for this one.  If the "xyz" is present in the document at some point after the "end " which ends the large block of text mentioned above, but "abc" was not originally present within that block, then go somewhere in the middle of that block of text and add "abc".  You now have two overlapping conditional styles: when the "c" was typed in "abc", Publisher now needs to apply a second style to the text, covering a region which overlaps the end of the block with the existing conditional style.  If there is a conflict between the two styles (ex. one makes text red and one makes it blue), Publisher also needs to figure out which one "wins" between them for the text within the overlapped region.  This would not be difficult to work out on its own, but when combined with the need to make these changes dynamically while typing where the detection of the changes is already complex can take an already difficult task and make it even harder and even more likely to not work as intended for various cases.

 

In short, it may seem simple on the surface, but when it comes down to actually coding a feature like this - there is a lot more that needs to happen under the hood than you seem to realize.

Link to comment
Share on other sites

Same here, I really need GREP Styles - Thanks 👍

MacBook Pro 16 pouces (3456 × 2234), 2021 / Apple M1 Pro / 16 Go / macOS Ventura Version 13.4.1 (22F82)
+ 31,5 pouces (2560 × 1440) + 27 pouces (1080 × 1920) + iPad (8th generation) / iPadOS 17.2 + Apple Pencil + 

Macmini6,2 Quad-Core Intel Core i7 16 Go / macOS Catalina version 10.15.7 (19H2026)
MacBookAir6,2 Intel Core i5 double cœur 4 Go / macOS Big Sur version 11.7.7 (20G1345)

Licence Universelle Affinity V2 updated to 2.3.0

Link to comment
Share on other sites

  • 3 weeks later...

I couldn't agree more with all the grep-style proponents. The nice thing about a grep style is that it is non-destructive to the text. Using grep on its own forces the text itself to be modified. If I want to change the style of a body of text, I have to start from scratch if I use a replacement function in grep. When using a grep style the text remains unchanged.

I do a lot of text importing from a database that is not in rich text format. For example something in bold looks like "This is in |bold| today." would become " This is in bold today." Back in InDesign, the text would look like "This is in |bold| today." but the grep style would change the looks. Remove the style and you would see the underlying text with the "|"'s in it. However in Affinity Publisher, once you execute a grep find\replace the underlying bold command ("|") is gone forever.

Grep styles would be an answer to my prayers!!!

Link to comment
Share on other sites

  • 3 weeks later...

Very much in favor of a GREP-style feature. This will be a big time-saver.

In the latest Publisher version, you still have to manually style for example a lead-in with say the first 2 words in small caps after a drop caps for e.g. every first chapter page. This is just one example for the many use cases for a GREP style feature.

Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...

Ah darn, this is a major blocker for me. Using inDesign has become prohibitively expensive but my projects all involve data merging blocks of text with mixed fonts (for symbols and such). I was finding Affinity Publisher so much more intuitive and user friendly but, if I cannot mix my fonts on data merging, I cannot continue to use this product. That's a real shame. I think that leaves me up a creek without a paddle

Link to comment
Share on other sites

4 minutes ago, SanguineAngel said:

if I cannot mix my fonts on data merging,

You can use Text styles and have the Merge Fields with the different Text Styles.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

Sadly not - I need to be able to use different styles within the same field.

For example:

"Here is some sample text about a topic. Sometimes I need to change fonts to display symbols like this <symbolfont>a</symbolfont> and then switch back to continue the text. I often need to switch multiple times in a block <symbolfont>x</symbolfont>."

The text is dynamically populated from external sources - so the placement and number of the style changes is not consistent - therefor I cannot pre-determine their placement with separate text fields.

Link to comment
Share on other sites

  • 5 months later...

Keep in mind that adding GREP to the paragraph styles as with InDesign requires another feature be added first. Publisher needs the ability the name and save GREP styles for later use. GREP styles are typically too complicated to be re-entered for each use. I used GREP S&R to clean up Word documents. That saves a lot of time. The lack of that feature is delaying my move from ID to Publisher. It is a must have.

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.