<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">WRT to JSword, we only have one OSIS/TEI filter which transforms to HTML (actually, this is an XSLT script). Our other filters (PlainText, GBF, ThML) transforms to OSIS and then runs through the OSIS -&gt; HTML filter. The same filter is used by all JSword frontends with small variations.<div><br></div><div>The current release of JSword and the next release of JSword differ. Some frontends (STEP, AndBible) are at the next release level. Notably BibleDesktop is not, but should have been. Don't know about Alkitab. This would account for some variation in JSword.<br><div><br></div><div>We currently don't handle intra-document linking except for images as relative urls where the base is the root of the module.</div><div><br></div><div>On another note: osis2mod does not require OSIS (except that which is needed to split the module into verses) or verify OSIS. It assumes that input has been validated externally. It is quite possible for HTML (e.g. &lt;br/&gt;, &lt;span font="red"&gt;...&lt;/span&gt;) to be in the input and it would be stored in the module as such. How different engines and frontends deal with that is highly variable. I think JSword will emit a warning and strip the elements and their attributes, not their content, in the XSL.</div><div><br></div><div>Another place of difference is the handling of vertical whitespace. In HTML nesting of block elements doesn't produce extra whitespace when adjacent opening or closing tags are present. This is not handled properly by the filters, which needs to simulate it. OSIS has the notion of milestone starts and ends of these elements. This does not directly translate into HTML. Also, the preverse div (opening and closing elements) needs to never produce vertical whitespace. There already have been lots of threads on this.</div><div><br></div><div>In Him,</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>DM Smith</div><div><br><div><div>On Sep 22, 2014, at 1:40 AM, <a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="font-family: Arial;">I would guess the main differences in output are all accounted for by checking which combination of rendering engine and filter set is employed. BT e.g. wraps and reimplements the sword engine's filters. BD and And Bible use jsword, but use different exit points afaik, former chases all module content through a XSLT conversion to create HTML, latter does something else. <br><br><br><div id="htc_header" style="">----- Reply message -----<br>From: "Nic Carter" &lt;<a href="mailto:niccarter@mac.com">niccarter@mac.com</a>&gt;<br>To: "SWORD Developers' Collaboration Forum" &lt;<a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>&gt;<br>Subject: [sword-devel] OSIS markup for gen books and devotionals<br>Date: Mon, Sep 22, 2014 03:20<br><br></div></span><br>As a general FYI, when I would test for conformity to how text should display, I used to test PocketSword vs Xiphos vs Eloquent/MacSword vs BPBible. My testing showed that they were a reasonable source of test cases. If something looked right in them but not in PS, I knew I had a bug. :)<div class=""><br class=""></div><div class="">(Karl, I would also be interested in hearing why other front-ends don’t seem to conform. Has a lot of work gone into other front-ends to change how some modules are presented because the back-end code isn’t feature complete yet?)</div><div class=""><br class=""></div><div class="">(PS: I’m on holidays and half-hoping to have a new beta of PS out in the next 2 weeks. Perhaps even have a new release of PS out by Christmas? iPhone 6/6+ compatibility would be good!)<br class="">
<br class=""><div><blockquote type="cite" class=""><div class="">On 22 Sep 2014, at 1:03 am, Karl Kleinpaste &lt;<a href="mailto:karl@kleinpaste.org" class="">karl@kleinpaste.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class="">
    <font face="FreeSerif" class="">I find it odd that this discussion died out
      without any further consideration from other app or </font><font face="FreeSerif" class=""><font face="FreeSerif" class="">engine</font> developers
      as to why the apps' delivery varies.</font><br class="">
  </div>

_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page</div></blockquote></div><br class=""></div></div>
_______________________________________________<br>sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page</blockquote></div><br></div></div></body></html>