<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#336666">
    <div class="moz-cite-prefix"><font face="Verdana">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.<br>
        <br>
        ...scott<br>
        <br>
      </font>
      <pre class="moz-signature" cols="72">
</pre>
      On 7/7/14 4:52 PM, Syed Zaeem Hosain (<a class="moz-txt-link-abbreviated" href="mailto:Syed.Hosain@aeris.net">Syed.Hosain@aeris.net</a>)
      wrote:<br>
    </div>
    <blockquote
cite="mid:B4C122ABC82F8744A7E552CA009BA22A1A7A370E20@EX-BE-019-SFO.shared.themessagecenter.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.ecxmsonormal, li.ecxmsonormal, div.ecxmsonormal
        {mso-style-name:ecxmsonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.ecxmsochpdefault, li.ecxmsochpdefault, div.ecxmsochpdefault
        {mso-style-name:ecxmsochpdefault;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.ecxmsohyperlink
        {mso-style-name:ecxmsohyperlink;}
span.ecxmsohyperlinkfollowed
        {mso-style-name:ecxmsohyperlinkfollowed;}
span.ecxemailstyle18
        {mso-style-name:ecxemailstyle18;}
p.ecxmsonormal1, li.ecxmsonormal1, div.ecxmsonormal1
        {mso-style-name:ecxmsonormal1;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.ecxmsohyperlink1
        {mso-style-name:ecxmsohyperlink1;
        color:#0563C1;
        text-decoration:underline;}
span.ecxmsohyperlinkfollowed1
        {mso-style-name:ecxmsohyperlinkfollowed1;
        color:#954F72;
        text-decoration:underline;}
span.ecxemailstyle181
        {mso-style-name:ecxemailstyle181;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
p.ecxmsochpdefault1, li.ecxmsochpdefault1, div.ecxmsochpdefault1
        {mso-style-name:ecxmsochpdefault1;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:10.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle28
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Yeah
            … I have to admit that I can’t argue with you on this too
            much. </span><span
            style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
            Because, there isn’t a simple “this is the right way” to do
            the EOP insertions.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Although
            … <i>maybe</i> … Word stands a slightly better chance
            because of its “Normal” paragraph that <i>could</i> 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.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Z<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
                Fred Ridder [<a class="moz-txt-link-freetext" href="mailto:docudoc@hotmail.com">mailto:docudoc@hotmail.com</a>] <br>
                <b>Sent:</b> Monday, July 07, 2014 10:18 AM<br>
                <b>To:</b> Syed Zaeem Hosain (<a class="moz-txt-link-abbreviated" href="mailto:Syed.Hosain@aeris.net">Syed.Hosain@aeris.net</a>);
                <a class="moz-txt-link-abbreviated" href="mailto:frame@daube.ch">frame@daube.ch</a>; <a class="moz-txt-link-abbreviated" href="mailto:framers@lists.frameusers.com">framers@lists.frameusers.com</a><br>
                <b>Subject:</b> RE: FM12: Quirks in Find/replace using
                RegEx (Perl)<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal" style="margin-bottom:12.0pt"><span
              style="font-family:"Calibri","sans-serif"">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. <br>
              <br>
              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. <br>
              <br>
              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.<br>
              <br>
              -Fred<o:p></o:p></span></p>
          <div>
            <div class="MsoNormal" style="text-align:center"
              align="center"><span
                style="font-family:"Calibri","sans-serif"">
                <hr id="stopSpelling" align="center" size="3"
                  width="100%"></span></div>
            <p class="MsoNormal" style="margin-bottom:12.0pt"><span
                style="font-family:"Calibri","sans-serif"">From:
                <a moz-do-not-send="true"
                  href="mailto:Syed.Hosain@aeris.net">Syed.Hosain@aeris.net</a><br>
                To: <a moz-do-not-send="true"
                  href="mailto:docudoc@hotmail.com">docudoc@hotmail.com</a>;
                <a moz-do-not-send="true" href="mailto:frame@daube.ch">frame@daube.ch</a>;
                <a moz-do-not-send="true"
                  href="mailto:framers@lists.frameusers.com">framers@lists.frameusers.com</a><br>
                Date: Mon, 7 Jul 2014 09:10:33 -0700<br>
                Subject: RE: FM12: Quirks in Find/replace using RegEx
                (Perl)<o:p></o:p></span></p>
            <div>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi,
                  Fred.</span><span
                  style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hmmm
                  … I understand your point, but am not sure I would <i>entirely</i>
                  agree with the reasoning. </span><span
                  style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Yes,
                  FrameMaker (and other programs like Word) do put in
                  additional information besides the EOP glyph itself.</span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
                  But, this is a relatively commonly used/desired
                  function – certainly in simple text editors – to
                  replace an EOP with other characters (perhaps
                  including an EOP). For example, to “join” multiple
                  lines together, or to do what Klaus mentions.</span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Yes,
                  FM is <i>not</i> just a simple text editor, which is
                  why I see your reasoning to not call it a bug.</span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">But
                  I think it would be good to define exactly what
                  regular expression matching is supposed to do with EOP
                  markers then (or have a special mechanism to identify
                  <i>and</i> use an EOP more effectively perhaps?)</span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Z</span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span
style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
              <div>
                <div style="border:none;border-top:solid #E1E1E1
                  1.0pt;padding:3.0pt 0in 0in 0in">
                  <p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
                      <a moz-do-not-send="true"
                        href="mailto:framers-bounces@lists.frameusers.com">framers-bounces@lists.frameusers.com</a>
                      [<a moz-do-not-send="true"
                        href="mailto:framers-bounces@lists.frameusers.com">mailto:framers-bounces@lists.frameusers.com</a>]
                      <b>On Behalf Of </b>Fred Ridder<br>
                      <b>Sent:</b> Monday, July 07, 2014 8:02 AM<br>
                      <b>To:</b> <a moz-do-not-send="true"
                        href="mailto:frame@daube.ch">frame@daube.ch</a>;
                      <a moz-do-not-send="true"
                        href="mailto:framers@lists.frameusers.com">framers@lists.frameusers.com</a><br>
                      <b>Subject:</b> RE: FM12: Quirks in Find/replace
                      using RegEx (Perl)</span><span
                      style="font-family:"Calibri","sans-serif""><o:p></o:p></span></p>
                </div>
              </div>
              <p class="MsoNormal"><span
                  style="font-family:"Calibri","sans-serif""> <o:p></o:p></span></p>
              <div>
                <p class="MsoNormal"><span
                    style="font-family:"Calibri","sans-serif"">No,
                    I don't think it is a bug. <br>
                    And end-of-paragraph mark is not a simple glyph; it
                    has properties and attributes associated with it
                    (e.g. a paragraph tag, the formatting associated
                    with that paragraph tag, and any overrides to the
                    standard formatting for the tag). <br>
                    You can find an EOP as if it were a simple glyph
                    because they do have a common fundamental property
                    (i.e. denoting the end of a paragraph). <br>
                    But you cannot effectively insert a new EOP in a
                    replace string because there is no way to associate
                    any of the other properties with the new mark. <br>
                    Finding an EOP and replacing it with itself, on the
                    other hand, is a valid operation because the found
                    mark has a full complement of paragraph properties.<br>
                    <br>
                    -Fred Ridder<o:p></o:p></span></p>
                <div>
                  <p class="MsoNormal"><span
                      style="font-family:"Calibri","sans-serif"">>
                      From: <a moz-do-not-send="true"
                        href="mailto:frame@daube.ch">frame@daube.ch</a><br>
                      > To: <a moz-do-not-send="true"
                        href="mailto:framers@lists.frameusers.com">framers@lists.frameusers.com</a><br>
                      > Date: Mon, 7 Jul 2014 15:48:17 +0200<br>
                      > Subject: FM12: Quirks in Find/replace using
                      RegEx (Perl)<br>
                      > <br>
                      > Friends of FramMaker, please judge.<br>
                      > <br>
                      > I want to find incorrectly ended paragraphs
                      (missing punctuation).<br>
                      > For example the following 4 lines are
                      paragraphs, the first 2 correct,<br>
                      > the next two incorrect:<br>
                      > <br>
                      > This is the first paragraph!<br>
                      > And this is the second one.<br>
                      > And here a third<br>
                      > And a fourth one:<br>
                      > <br>
                      > RegEx Find/Replace with these settings:<br>
                      > Find: ([^\.!?])\n<br>
                      > Repl: $1.\n<br>
                      > Result: find is correct, replacement is n
                      instead of paragraph end<br>
                      > With repl = $1.\r replacement is a forced
                      newline; correct, but not wanted.<br>
                      > <br>
                      > Find: ([^\.!?])(\n)<br>
                      > Repl: $1.$2<br>
                      > This creates a correct replacement!<br>
                      > <br>
                      > IMHO the behaviour of not honoring \n as an
                      'end of paragraph' for the replacement is <br>
                      > a bug. Do You agree?<br>
                      > <br>
                      > Klaus Daube<o:p></o:p></span></p>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________


You are currently subscribed to framers as <a class="moz-txt-link-abbreviated" href="mailto:sp10@leximation.com">sp10@leximation.com</a>.

Send list messages to <a class="moz-txt-link-abbreviated" href="mailto:framers@lists.frameusers.com">framers@lists.frameusers.com</a>.

To unsubscribe send a blank email to
<a class="moz-txt-link-abbreviated" href="mailto:framers-unsubscribe@lists.frameusers.com">framers-unsubscribe@lists.frameusers.com</a>
or visit <a class="moz-txt-link-freetext" href="http://lists.frameusers.com/mailman/options/framers/sp10%40leximation.com">http://lists.frameusers.com/mailman/options/framers/sp10%40leximation.com</a>

Send administrative questions to <a class="moz-txt-link-abbreviated" href="mailto:listadmin@frameusers.com">listadmin@frameusers.com</a>. Visit
<a class="moz-txt-link-freetext" href="http://www.frameusers.com/">http://www.frameusers.com/</a> for more resources and info.
</pre>
    </blockquote>
    <br>
  </body>
</html>