<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 30/12/14 08:47, Peter Von Kaehne wrote:<br>
<blockquote
cite="mid:trinity-7133c668-984a-40c6-bd06-0d700a45751d-1419882421826@3capp-gmx-bs55"
type="cite">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>
<div>As it stands - and I guess apart from David and Chris I
am probably one of the most prolific users of this and the
last, Perl based script, the occasions where I ended up in a
crash are few and far in between. Much more often bad USFM
produces bad OSIS, non validating OSIS, rather than crashes.
<br>
</div>
</div>
</div>
</blockquote>
Yes, correct, that was my point exactly, except to note (as shown in
other recent threads), there's plenty of "bad" OSIS that actually
validates and gets through into modules. usfm2osis.py doesn't crash
because it doesn't even detect many issues. The only error message
in the entire program is to list unhandled USFM markers. Unlike
Greg, it seems, my philosophy would definitely be to try to discover
"issues" and advise the module builder, rather than have the issues
carry through further to the next stage (which is the actual
modules). What USFM verification tool does the module maker run
before using usfm2osis.py?<br>
<blockquote
cite="mid:trinity-7133c668-984a-40c6-bd06-0d700a45751d-1419882421826@3capp-gmx-bs55"
type="cite">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>
<div> </div>
<div>BTW - Robert, you did make a bug report re a crash and I
would like to process this - could you please add to the
comments of ModTools 46 a test case?</div>
<div> </div>
<div><a class="moz-txt-link-freetext" href="http://www.crosswire.org/tracker/browse/MODTOOLS-46">http://www.crosswire.org/tracker/browse/MODTOOLS-46</a></div>
</div>
</div>
</blockquote>
Right, although to be clear, I wasn't talking at all about crashes
in my email below. And sorry, it's too long ago now so might as well
just close the bug report. I was unable to easily discover the bad
line in the USFM (because of my point #2 below) and wasn't able to
pursue tracking it down at the time. I think I submitted the bug
report before understanding that it was the philosophy of
usfm2osis.py to not attempt to detect issues in the USFM. I know
better now. :)<br>
<br>
Robert.<br>
<blockquote
cite="mid:trinity-7133c668-984a-40c6-bd06-0d700a45751d-1419882421826@3capp-gmx-bs55"
type="cite">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding:
10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap:
break-word; -webkit-nbsp-mode: space; -webkit-line-break:
after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Montag, 29.
Dezember 2014 um 19:35 Uhr<br>
<b>Von:</b> "Greg Hellings"
<a class="moz-txt-link-rfc2396E" href="mailto:greg.hellings@gmail.com"><greg.hellings@gmail.com></a><br>
</div>
<div name="quoted-content">
<p>If you provide undefined/invalid input then the
behavior of a convenience script being undefined should
be no surprise. It is not the place of this script to be
a USFM verification tool.</p>
<div class="gmail_quote">On Dec 29, 2014 2:28 PM, "Robert
Hunt" <<a moz-do-not-send="true"
href="hunt.robertj@gmail.com" target="_parent">hunt.robertj@gmail.com</a>>
wrote:
<blockquote class="gmail_quote" style="margin: 0 0 0
0.8ex;border-left: 1.0px rgb(204,204,204)
solid;padding-left: 1.0ex;">
<div>On 30/12/14 06:29, Peter von Kaehne wrote:
<blockquote>
<pre>It is very well written and neatly done and does its job with near
perfection. I would welcome contributions to it, as long as they are
equally well done. </pre>
</blockquote>
Just for your info: usfm2osis.py basically treats
each USFM book as a huge hunk of text to which it
does a large number of global text substitutions.
Although this, in fact, does make it a very neat and
tidy program, I don't think it's nearly perfect. The
main disadvantage of using this method can be
expressed as two results to the user (and I think
these are quite serious defects in terms of reliable
module making as other threads attest):
<ol>
<li>Certain errors or non-conformities in the USFM
are not even detected (e.g., when \d is used as
a paragraph type marker with verses logically
"inside" the \d marker which is not actually
documented [nor banned] in the USFM
specification)<br>
</li>
<li>If there is an error, the program is
completely unable to give the user any
indication of where (e.g., line number or
chapter/verse) the error occurs because it has
absolutely no concept of "position within the
file".</li>
</ol>
<p>Perhaps this is accounted for by running some
other program first to thoroughly check that the
formation of the USFM is within the
expected/programmed range???</p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>