<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-07-15 23:29 GMT+03:00 Troy A. Griffitts <span dir="ltr">&lt;<a href="mailto:scribe@crosswire.org" target="_blank">scribe@crosswire.org</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">:) Hi Konstantin,<br>
<br>
You have to know when I say something like this, &quot;We could build it, but<br>
I&#39;m afraid it might actually get used,&quot; that I&#39;m being mostly facetious<br>
though there is some true concern in what I am writing.  Of course I can<br>
see proper uses if the need arises.  I didn&#39;t think the Danish or French<br>
need was a good case for per-module versification. Our path to support<br>
v11n mapping and optimization is to support major versification systems,<br>
one of which a module must identify itself with.  This optimizes key<br>
loading and allow a reasonable opportunity to map between known system.<br>
 One disadvantage I tried to stress was specifically for your benefit.<br>
If a module does not associate itself with a supported versification,<br>
but instead supplied its own, then none of your v11n mapping code can<br>
currently be used with the module because we don&#39;t know anything about<br>
which v11n system it mostly follows.</blockquote><div>I have a clear vision of implementation for this feature in my head, in that implementation mapping data is provided with module as a part of v11n.<br><br>In Sword&#39;s current av11n mapping solution, data is just a set of rules that are applied during translation procedure and it is possible to store them in binary form. If we need any very special mapping case for particular text there is ability to invent new type of rule that will not be supported/processed on older engine versions. No need to invent format for supplied versification, just memory-map our canon.h files, versification registration will receive pointers on dynamic data read from file from module in contrary to pointers on static memory as for now.<br><br></div><div>I am of course do not know enough about those Bibles, just feel unconvinced about this feature.<br><br></div><div>P/S Sorry, cant add anything funny, its hard to thing in foreign language after long delay.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Again, I am not against adding the<br>
feature, but only trying to avoid adding and using the feature for a use<br>
case which is better addressed with our currently methodology.  This<br>
might take longer to research v11n schemes for these regions, but then<br>
we can say we&#39;ve done the research and when we add a v11n which supports<br>
the majority of Bibles in a region then we&#39;ll know which verses a Bible<br>
deviates at when it uses the system.  These are all good things.<br>
<br>
Anyway, GBS Bible support was never finished-- it was an experiment that<br>
turned out to point to a better solution-- and JSword does not implement<br>
it.  It should not be used-- at least right now.  And if we move forward<br>
with per-module v11n support, I think I mentioned that JSword might<br>
already have a file format they use.  I think an immediate need will<br>
probably push this forward beyond hypothetical talk.  Peter may have<br>
one, but I&#39;d like to do some research before we say that all French<br>
Bibles are too crazy to ever define a (or a couple) standard<br>
versification systems.<br>
<br>
Hope this helps clear up,<br>
Troy<br>
<span><br>
<br>
<br>
On 07/15/2015 09:49 PM, Konstantin Maslyuk wrote:<br>
&gt;&gt; And it shouldn&#39;t be used. :)<br>
&gt;<br>
&gt; It should not be used for one only purpose and we will reject a usefull<br>
&gt; feature? :^S<br>
&gt;<br>
&gt; Today we have years from new v11n appeared in Sword and most of<br>
&gt; frontends be released with that v11n. Same for if error was in v11n. And<br>
&gt; most annoying will be when we will release bug fixes for mapping data,<br>
&gt; some old apps/some old platforms would never get such fixes.<br>
&gt;<br>
&gt; It would be used for some rare texts. I did not meet such, but i count<br>
&gt; if text (version) author intentionally change verse index, we have to<br>
&gt; leave it, but correctly translate to other v11ns.<br>
&gt;<br>
&gt; By the way v11ns for rare texts will be used by ~0,001% of users,  and<br>
&gt; will be delivered to all. Isn&#39;t it better to store v11n in to those<br>
&gt; one/two modules?<br>
&gt;<br>
&gt; One can build own module repository with different v11ns, and it will be<br>
&gt; compatible with all Sword apps.<br>
&gt; It is just freedom that would bring unexpected good use cases , but we<br>
&gt; suppress freedom for the sake of one bad.<br>
&gt;<br>
&gt; Maybe there were another points, can&#39;t remember.<br>
</span>&gt; ------------------------------------------------------------------------<br>
&gt; От: Troy A. Griffitts &lt;mailto:<a href="mailto:scribe@crosswire.org" target="_blank">scribe@crosswire.org</a>&gt;<br>
<span>&gt; Отправлено: ‎15.‎07.‎2015 14:19<br>
&gt; Кому: SWORD Developers&#39; Collaboration Forum<br>
</span>&gt; &lt;mailto:<a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a>&gt;<br>
<div><div>&gt; Тема: Re: [sword-devel] Av11n mark 2<br>
&gt;<br>
&gt; Yeah, that doesn&#39;t help me either.  We abandoned GenBook Bible support<br>
&gt; in favor of the VersificationMgr system.  I am not against adding a<br>
&gt; per-module v11n mechanism, but I fear it will be used. :)  And it<br>
&gt; shouldn&#39;t be used. :)  Using this basically allows people to take<br>
&gt; shortcuts bypassing the analysis of the versification of their module<br>
&gt; and trying to identify it most closely with a common v11n.  This is<br>
&gt; important as it allow us to display the module with v11n mapping across<br>
&gt; different systems.  We discussed ways one could also use the mechanism<br>
&gt; appropriately: selected the closest common v11n and supplying mappings<br>
&gt; for the verses which aren&#39;t covered by that v11n.  But my experience<br>
&gt; would lead me to speculate that if we allow custom v11n, then everyone<br>
&gt; will use it for their module-- even if there are only a couple<br>
&gt; differences in v11n between their module and a common v11n system,<br>
&gt; because they won&#39;t need to spend the time to analyze and learn about<br>
&gt; their text and v11ns which we support well.  Allowing v11n loading per<br>
&gt; module is fairly straightforward to implement and I believe JSword might<br>
&gt; already have a file format they support.<br>
&gt;<br>
&gt; Regarding this thread.  If we need to add 2 new v11ns for French and<br>
&gt; Danish, then we need to spend the time to do the research and add a<br>
&gt; versification and mapping data.<br>
&gt;<br>
&gt; Troy<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 07/15/2015 01:03 PM, DM Smith wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Jul 15, 2015, at 6:59 AM, Karl Kleinpaste &lt;<a href="mailto:karl@kleinpaste.org" target="_blank">karl@kleinpaste.org</a><br>
&gt;&gt;&gt; &lt;mailto:<a href="mailto:karl@kleinpaste.org" target="_blank">karl@kleinpaste.org</a>&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 07/15/2015 06:35 AM, Peter von Kaehne wrote:<br>
&gt;&gt;&gt;&gt; 1) Unlike the other av11n implementation it does not yet show non KJV<br>
&gt;&gt;&gt;&gt; verse range content.<br>
&gt;&gt;&gt; I&#39;m confused. If genbook Bibles are essentially self-contained in<br>
&gt;&gt;&gt; terms of v11n, how can a genbook Bible not display all its own content?<br>
&gt;&gt;<br>
&gt;&gt; I read Peter’s comment that it wouldn’t handle a verse range properly if<br>
&gt;&gt; one or both of the ends was not in the KJV versification.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
&gt;&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt;&gt; Instructions to unsubscribe/change your settings at above page<br>
&gt;&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt; Instructions to unsubscribe/change your settings at above page<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
&gt; Instructions to unsubscribe/change your settings at above page<br>
&gt;<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page</div></div></blockquote></div><br></div></div>