@Alexandre_Noite Welcome to the forums.
You have the option of creating custom text styles within Publisher using whichever fonts are installed/available within the OS. However that part of the workflow uses GREP styles which isn't something Publisher has, it's been requested so may be a feature added in the future.
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.
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.
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.