There's no reason the plain-text replacement can't add EOPs .. just need a code to do that. You can do that with a regular search/replace by searching on "\p" and replacing with "\p\p". The "\n" is a forced return in the non-regex UI. It should at least do the same .. not an "n".


On 7/7/14 6:07 PM, Fred Ridder wrote:
But if there is no practical way for a plain text-oriented tool to insert a *proper* EOP, the only way to make Frame's overall Find/Replace behavior consistent would be to forbid searching for EOPs. And that would be a *real* shortcoming IMO. Kind of like throwing out the baby with the bathwater...


Date: Mon, 7 Jul 2014 16:57:03 -0700
Subject: Re: FM12: Quirks in Find/replace using RegEx (Perl)

I dunno. I just don't like the fact that "\n" will match on a line end (of some type), while it replaces as an "n" .. that's not right.


On 7/7/14 4:52 PM, Syed Zaeem Hosain ( <>) wrote:

    Yeah … I have to admit that I can’t argue with you on this too
    much. JBecause, there isn’t a simple “this is the right way” to do
    the EOP insertions.

    Although … /maybe/ … Word stands a slightly better chance because
    of its “Normal” paragraph that /could/ get applied by default. Of
    course, as you note, this could cause a mess with documents whose
    paragraphs have already been changed to some other paragraph
    format, etc.


    *From:*Fred Ridder []
    *Sent:* Monday, July 07, 2014 10:18 AM
    *To:* Syed Zaeem Hosain (
    *Subject:* RE: FM12: Quirks in Find/replace using RegEx (Perl)

    Don't get me wrong. I'm not saying that it wouldn't be *useful* to
    be able to insert a new EOP. But the reality is that in either
    Word or FrameMaker (and I assume in other word processing
    applications) it is problematic because EOP is not a simple
    character. Regular expressions are designed to work with arbitrary
    strings of simple characters. They were never intended to handle
    characters that have formatting or page layout properties embedded
    in them. If a regular expression *were* able to insert a new EOP,
    what formatting should apply to it? Since regular expressions
    don't know about formatting, the only practical answer is the
    lowest level default formatting. But in any properly designed word
    processor document (i.e., one that uses styles) that default is
    going to be *wrong* in >99% of cases and require further, manual
    attention from the author, which really defeats the benefit of
    being able to use a regular expression replacement. A simple text
    editor is a completely different situation because there really is
    nothing special about an EOP.

    I think the real point is that in Klaus' case the analysis of the
    task was slightly flawed. To fix his punctuation issue, what he
    really wants to do is insert a period (full stop) between the
    current unpunctuated text and the existing EOP, which is exactly
    what his second regular expression does. There really is no reason
    to delete the existing EOP (and all the "magic" embedded in it)
    and replace it with a brand-new, untagged EOP that would require
    his manual attention to tag and/or format. FrameMaker's behavior
    of not allowing this saves the user from having to do a lot of
    after-the-fact cleanup.

    FrameMaker's regular expressions let you find EOPs without issue,
    and lets you reuse them. What they don't let you do is try to
    create a new one where there is insufficient information in the
    found text string(s) to do that operation without making a mess.




You are currently subscribed to framers as

Send list messages to

To unsubscribe send a blank email to
or visit

Send administrative questions to Visit for more resources and info.

Reply via email to