<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <div class="moz-cite-prefix">On 12/30/2017 08:31 AM, DM Smith wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:BD5D13B2-D24D-4A21-9DC0-DEA3A46054EF@crosswire.org">The

      module matches what the filter expects.

      <div>The filter does something.</div>

      <div>Third possibility: front end doesn’t handle the attribute.</div>

    </blockquote>

    <br>

    I just spent an hour stepping through Xiphos' handling of WLC

    Gen.1.1 with and without Morpheme Segmentation set.<br>

    <br>

    First, Xiphos correctly turns the option on and off. That's kind of

    a given, but I had to check on it anyway. There's a single area

    where all options are turned on/off in a uniform way, driven by the

    GTK menu files, and how Xiphos discovers the current setting during

    each chapter redraw. Mostly, I had to check that I had spelled the

    option right in all the relevant places, to be sure the right effect

    was being caused.<br>

    <br>

    Second, the actual text output that results from Morpheme

    Segmentation being on vs. off is identical, as discovered by

    trapping the display routine that accepts the engine's result when

    requesting the verse. This image is the result of copy/pasting gdb's

    textual output from a terminal into gedit and then capturing an

    image of that.<br>

    <br>

    <img src="cid:part1.66460D4F.1B5C5454@kleinpaste.org" alt=""><br>

    <br>

    The filter has no effect on the text. If someone wants to look at

    how osismorphsegmentation.cpp does this, feel free, but objectively

    what comes out from requesting the verse doesn't care whether the

    option is on.<br>

    <br>

    More simply, "diatheke -b WLC -f xhtml -k gen.1.1" with and without

    "-o M" proves they're the same, as shown with both diff and md5sum.<br>

  </body>

</html>