On Jan 23, 2007, at 7:54 PM, Troy A. Griffitts wrote:
> DM,
> To sum up the previous thread:
> *plain filters are primarily for use as strip filters.
> Strip filters prepare text for searching, NOT display.
> A newline would prevent a stristr phrase match in some situations--
> primarily se
DM,
Again, to summarize the previous thread: We are not suggesting
re-encoding the text. We are suggesting the use of end user, readable
ASCII markup characters-- as you have also previously suggested:
[supplied word], LORD, {note:}, etc.
Since STRIP filters (*plain) are for s
DM,
To sum up the previous thread:
*plain filters are primarily for use as strip filters.
Strip filters prepare text for searching, NOT display.
A newline would prevent a stristr phrase match in some situations--
primarily seen in the psalms.
-Troy.
DM Smith wrote:
> On Jan 22,
It has been a long time since we've had an up-to-date CD image for
CrossWire software.
The task is quite challenging, as the latest versions of software for 4+
operating systems, installers which install software and modules from
CD, along with the latest modules, and source code, all have to b
There has been much talk about an "ASCII" filter in this thread. I
think that might run into problems.
The ESV and KJV modules are encoded in UTF-8 and have some UTF-8
characters. Additionally, Sword allows for numeric entities for
unicode characters in OSIS. These would need to be converted
On Jan 22, 2007, at 11:47 PM, Troy A. Griffitts wrote:
> Yes, adding a newline in your patch would break the
> functionality of the primary purpose for the *plain filters.
Troy,
In osisplain.cpp there are a lot of newilnes that are output. I
don't see how adding newlines for missing ele
