<p dir="ltr">Greg<br>
On May 19, 2014 5:12 PM, &quot;Jaak Ristioja&quot; &lt;<a href="mailto:jaak@ristioja.ee">jaak@ristioja.ee</a>&gt; wrote:<br>
&gt;<br>
&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; Hash: SHA1<br>
&gt;<br>
&gt; Hi!<br>
&gt;<br>
&gt; 1) According to <a href="http://www.crosswire.org/wiki/DevTools:conf_Files">http://www.crosswire.org/wiki/DevTools:conf_Files</a> the<br>
&gt; \u control word should be followed by a 16-bit signed integer. The<br>
&gt; wiki page doesn&#39;t mention this, but I assume it is in ASCII in decimal<br>
&gt; form.</p>
<p dir="ltr">It would be either CP1252 or UTF 8 like the rest of the file. <br>
&gt;<br>
&gt; The RTFHTML filter code appears to incorrectly parse the following<br>
&gt; strings:<br>
&gt;<br>
&gt;   &quot;\u-999999&quot; -&gt; getUTF8FromUniChar(48577)<br>
&gt;   &quot;\u-99999&quot; -&gt; getUTF8FromUniChar(31073)<br>
&gt;   &quot;\u-0001&quot; -&gt; getUTF8FromUniChar(65535)<br>
&gt;   &quot;\u-00&quot; -&gt; getUTF8FromUniChar(0)<br>
&gt;   &quot;\u-0&quot; -&gt; getUTF8FromUniChar(0)<br>
&gt;   &quot;\u00&quot; -&gt; getUTF8FromUniChar(0)<br>
&gt;   &quot;\u001&quot; -&gt; getUTF8FromUniChar(1)<br>
&gt;   &quot;\u99999&quot; -&gt; getUTF8FromUniChar(34463)<br>
&gt;   &quot;\u-&quot; -&gt; getUTF8FromUniChar(0)<br>
&gt;   &quot;\u--&quot; -&gt; getUTF8FromUniChar(0)<br>
&gt;   &quot;\u--2&quot; -&gt; getUTF8FromUniChar(0)<br>
&gt;   &quot;\u-a&quot; -&gt; getUTF8FromUniChar(0)<br>
&gt;<br>
&gt; I think all these should instead fail.</p>
<p dir="ltr">The last three should return -, 2, and a respectively if I read the wiki page correctly that allows a final character to use when the conversion otherwise won&#39;t work. </p>
<p dir="ltr">Why you think the signed values that are zero prefixed should fail I don&#39;t understand. Those which fall beyond the range of a sixteen bit integer are the only ones I might agree should fall.  However, since Unicode now exceeds sixteen bits, think it is our limitation that ought to change. </p>

<p dir="ltr">&gt;<br>
&gt; 2) In case an exception is thrown, text might contain a partial result<br>
&gt; or the original value.<br>
&gt;<br>
&gt; 3) For control word \pard (and similarly for \par and \qc) it<br>
&gt; incorrectly parses \pardx as \pard and &quot;x&quot;, where it should instead<br>
&gt; fail due to an invalid control word \pardx.<br>
&gt;<br>
&gt; 4) \par incorrectly appends a newline.</p>
<p dir="ltr">Why is a newline incorrect? Newlines are mostly ignored in HTML.</p>
<p dir="ltr">&gt;<br>
&gt; 5) &quot;a\qc b&quot; is converted to &quot;a&lt;center&gt; b&quot;, but should instead be<br>
&gt; &quot;a&lt;center&gt;b&lt;/center&gt;&quot; (&#39; &#39; RTF delimiter output, missing HTML<br>
&gt; &lt;/center&gt; tag)<br>
&gt;<br>
&gt; 6) &quot;a\par b&quot; is converted to &quot;a&lt;p/&gt; b&quot;, but should probably be<br>
&gt; &quot;&lt;p&gt;a&lt;/p&gt;&lt;p&gt;b&lt;/p&gt;&quot; (&#39; &#39; RTF delimiter output, missing HTML &lt;p&gt; and<br>
&gt; &lt;/p&gt; tags.<br>
&gt;<br>
&gt; 7) Weird combinations of \par, \pard and \qc result in broken HTML<br>
&gt; fragments or HTML fragments with unbalanced start and end tags.</p>
<p dir="ltr">I don&#39;t believe the contract of this filter guarantees valid HTML, and HTML allows unbalanced tags.  In fact it is preferred in some older HTML specs for certain tags,  p a prominent example of such tags. </p>

<p dir="ltr">&gt;<br>
&gt; 8) Unsupported control sequences do not cause the function to fail,<br>
&gt; but are passed to output as plain text (including the backslash).<br>
&gt;<br>
&gt; 8) Unescaped &#39;{&#39;, &#39;}&#39; and &#39;\&#39; characters are not handled properly (to<br>
&gt; pass these from RTF one would need to use the control symbols &quot;\{&quot;,<br>
&gt; &quot;\}&quot; and &quot;\\&quot; respectively).<br>
&gt;</p>
<p dir="ltr">The rest of your objections seem to be based on a different objective than SWORD filter objectives. The prose is not to force compliance to a strict spec but instead to give a &quot;best effort&quot; attempt at conversion. The same way that most browsers will accept invalid input but make a best effort to display (unescaped &amp; characters will usually display as is and invalid nesting such as having a div inside of a p tag still works out somewhat reasonably) the SWORD engine is lax in what it accepts. </p>

<p dir="ltr">It follows the general maxim &quot;be strict in what you produce but lenient in what you accept.&quot; Crosswire produced content should not include such invalid input, but the engine is intentionally written to make a best attempt to handle innocuous invalid input. This is because we want to encourage as many people as possible to use the engine even if they are not strict in what they produce. </p>

<p dir="ltr">If there are existing modules with bad content or in places where the filters are producing invalid output we should fix it, but we don&#39;t need to go and get stringent about the conversion throwing errors or the like because of an invalid control sequence or an unknown Unicode character. </p>

<p dir="ltr">--Greg</p>
<p dir="ltr">&gt; Maybe I&#39;ll get around to fix this someday during daytime. To save me<br>
&gt; extra work, I&#39;d appreciate any comments on this before I start any<br>
&gt; coding, especially if the Sword library needs to deviate from the RTF<br>
&gt; specifications.<br>
&gt;<br>
&gt;<br>
&gt; Blessings,<br>
&gt; Jaak<br>
&gt;<br>
&gt; PS: I&#39;m glad there are no memory errors in this function. :)<br>
&gt; PPS: Please forgive me for having studied formal languages.<br>
&gt; -----BEGIN PGP SIGNATURE-----<br>
&gt; Version: GnuPG v2.0.22 (GNU/Linux)<br>
&gt;<br>
&gt; iQgcBAEBAgAGBQJTeoEUAAoJELozJlbjIn798A1AALYn7ogi0Q3QvLPq998aj5R8<br>
&gt; dMW/iAPIRPgmvrqpccTaaYxbP60E5Pm6Yf3XEFR6KkP01QQtM/v6S7Bxmmo28ewr<br>
&gt; En3ZMzhldHDQUXKuaP5+Rp8ndw81SjlyeVYZlQlpcm/gWBzJpjZ4CFJuePH5/iwp<br>
&gt; 1kn3WwRJM5mp2nejOC+JIRgL8RDvEMwowSHWFKESI//YoJzS6tWKQskGI65dWngb<br>
&gt; PYFzMpllpJpQhMKspDXh6sbJT43UlX/Kvh9G/JDrp5PUeJbBLO4xcs9kd+lbK9fP<br>
&gt; XKCxeN6Ih63p4AR/PkwJQqYW1m/i/xSdMcozfOF5nkGyVGqW9XcLS9NEVLT4JzYg<br>
&gt; PaU1ZiuhjxNIsF28x6ewSDadPExkOyXMDMRqHC23udPtQt4P9QMYwwsDTBn77mzt<br>
&gt; sCK/WL486Rewl2wWJGwTaYG8HieFQF0/ZsrKFGlB7u3zzJx608SdiXxvt/w29keo<br>
&gt; 0UPzl0se0imAhSLEbwHe4keS7SGofncoCU4u1bacfRMnngCf2irpyGElFfYrlH32<br>
&gt; bPhIQBG4pZp3noHM8O6cv/w5xCtE0nZ9ROV4pI1xzPFB4yDiCDV/LXLYV0RCHW92<br>
&gt; /fteZAYYLqC/BQvyRi/eZ0XAM+a0L2rdm+ggFI/Vcq+VfT/gjv7UfzcwsfS/J1eA<br>
&gt; NawubrlcvuH430K4pNIPPbwfybwV6eNkt6YbffE4cgOhFGUtMWuph6cVEn/Ic0cY<br>
&gt; MlDR+t7p0PNQGZ0KeqpEkydhLEiQGbUPfmtTYRY64ZrwiSRT3ouHsgO88/G/Ehvt<br>
&gt; jTce6S4XY43Bp6sAu5mjdD4+ObSWbAMBwMN92tlQ0yZ5ctvx4qVLEV/ld/QBjayG<br>
&gt; ryzjZ0zP3uclEvDAuP/aUsX1ocS1tW7heMeyqC0tb8oUslTf9kwjx/VAZLQZyvqy<br>
&gt; a1uYDgrHqVslKYc2BffFns33tfkia4+8Y6NkoVOmuB0wdOnCSm+QbEJT11bJVh7+<br>
&gt; UwL/g5ih2c0/xQgvBF5sGvOANy2hJGFulehZ4qcjcsFw3YQFHnUIobnjoxuXkta1<br>
&gt; uB690Wol18v0Xkf9+19tYx65+3h6iss/2Qw9FhiJyVFS++a3Z70NSlbC2MJz+TH2<br>
&gt; HCp0Z+qiikP/FohZbz5hru9luTPx7uM44AGI1MFRjj1275CMWeEAZCEx4pZUkL/G<br>
&gt; 5xWDDCxN0FJorkuI3yUw7CKcN6c7hcAM5iOMO91SgpS5vIco0/H2BTVl8XDO1tt6<br>
&gt; ngbYuGEhZhHNExn6RRk1KIOx08USJ9i+iPqB8dVT8tDGK+VAF/9M95uEhZy5d9g0<br>
&gt; NhbpMx1EPgVk/E3+VNKBB1zgxsnkvjzCnR+F65h8A+aeDj4jvrHowIkqcdL45IVX<br>
&gt; cWjuYmVe3uOlDMLF/q2X3Rh4tOTtGQA1ApJdfXBDzj//hFudDNgb0OJjLTuyg2tG<br>
&gt; xgn6qPfcNcO9WKbiqBhU20FQnTUiMyEMF1pW/4OckJ3fIe86V3JhIkP5w1l6F5K4<br>
&gt; 7npniPO9gXTfDAFDbNEwwiCb2ejVPqMjRUdI/PJwvpXXRNJIiAc3+jRhhJ8xdipY<br>
&gt; 2SFnWugLkR0bC8i/Lbf9djpUSTwuxgb+GcXUCpA1S1pfWECPwL+jzQAIAGwIV3ly<br>
&gt; dk6XlyNrmFkpC9s+/dbKfStXbGmy6tSbSACBJHyXq2OaERsbQsbXkp1DyljuIbG/<br>
&gt; raOoq1ewuoc0Ie/6C8RA/QUcY+uvszsw/HVs3W4eUtc+YDUX+p3+ptZBE+wL4lHX<br>
&gt; f67P5++gsI/IajT/a+cOm6tzkVPpJjdJW0yN1tAoCeAdEsP8fs7JnmOX0MddkGAK<br>
&gt; bZyPnRYqC8tNjyvp656cYf3250W2dlkjWQQ122WjjLYRdiPIimEs2rm8IlpvIT5G<br>
&gt; u4ejUnsfq+js1GBUyv7O3WZilDOZMFU26W6rCOvhCdwMu95Hwvqmqm7ofCJ+vbSZ<br>
&gt; O7QkkApB54koKX3H8FjiBdeqSbk9/Ej2WVUvhEI6MwrFX4vDQR9RkRtW8tH/iQey<br>
&gt; elV5ABcN+sLSgclgrVFXle03SkZrjWZzbKZ84k6W6g5Od9vKj9gTiKaPzddd3EK+<br>
&gt; KbN/RtQmZcT77ceABHzdOQ0HKe6L7GI56Q3Y1eV66v6xL4QwBgroYA4Tg4dy7Ddk<br>
&gt; TcKvUInyEXZRM1A3vkUQk5mZvatHmnOwVyi0PTVyO3isuFLoNwIp9xDhEZJsDd5B<br>
&gt; qHHnjmlVtpE0SzD8EVrKAJAO4/fllZKd/hzv14rUSZ7ORl7PRdSzO5933dw+v6Bb<br>
&gt; Nut2uIfzAAW1xeadYtWufE50qDVraWS+oy9Iyeat0RRdxEx7+luz7iuvTDcaUa00<br>
&gt; +Wygu4bWGCLvO3EpEq0JK/1H3Twa2xc6FR9T1Bg8CJVsVGCizfxD0WXQuoLzOzpb<br>
&gt; uYlaEX18UoomDHFo+8JrCZwGKBgSlUqwehhUA75Yh/S/DqfZnYzK6RUekvms0We6<br>
&gt; dNcP8H5OY+f3rCcKF2FY1Gz6QE03GmrguRxVS2TIRPUo90XuMBMxQSihC7LLHA3d<br>
&gt; cjQC6biOUZPq1RoeRs6xx+aLgmS0BZgYwqUl7H5RCauDx8N51On39ZWAkDXZTd1O<br>
&gt; p0L+a526J2AjK19PKjB/OcdJcFyQBQgO6abCcBZ2ooWhFsxL4JgBX75w+WAsSBmE<br>
&gt; kol3waKHsVC23TvPG2NoNHeh48RZfDrGy0hYIk2tymfW0KhAwpu6Ou03BlojHR4j<br>
&gt; zl1NPiRW9SjvMEvpZtZF<br>
&gt; =Mrt1<br>
&gt; -----END PGP SIGNATURE-----<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt; Instructions to unsubscribe/change your settings at above page<br>
</p>