<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 31, 2018 at 3:38 PM, John Dudeck <span dir="ltr">&lt;<a href="mailto:john.dudeck@sim.org" target="_blank">john.dudeck@sim.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>





<div>
<div align="left"><font face="Arial" size="2"><span style="font-size:10pt">Being somewhat new to the Sword project, and a module developer, not in Sword development per se, I don&#39;t have any particular 
interest in GenBook bibles. It sound&#39;s like a kludgy way to avoid having to make the base engine powerful enough to handle 
flexible versification.</span></font></div></div></blockquote><div><br></div><div>It&#39;s not a kludge. It&#39;s an alternative implementation to the baked-in version we have now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div align="left"><font face="Arial" size="2"><span style="font-size:10pt"><br>
</span></font></div>
<div align="left"><font face="Arial" size="2"><span style="font-size:10pt">I have been a Logos content developer for several years, and what they call Bible Data Types that are defined in Verse Maps are 
hard-coded into the Logos engine. This has always been a source of consternation for me. At least Logos has been willing to add 
verse maps for new bibles without complaining. But it is a several-month process from the time the map is submitted until it 
becomes active by a new release of Logos and the Logos Book Design Tools. I gather that the Sword project is similar, except 
that it doesn&#39;t really have verse-by-verse maps that show how every given verse in one bible version maps to the equivalent 
verse in every other version. Being limited to the current twenty v11n&#39;s, for which several French bibles do not match any of 
them, is problematic, and requires some kind of work-around to get bibles and commentaries to work in a usable way.</span></font></div></div></blockquote><div><br></div><div>Yes, the SWORD engine currently works the same way. You have to propose a new versification, it needs to get approved by the developers and then added to the system. There is a way to define mappings between versifications, but it&#39;s not an absolute necessity to add it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt"><br>
</span></font></div>
<div align="left"><font face="Arial" size="2"><span style="font-size:10pt">It seems to me that it should be possible to devise a pluggable v11n system where the verse mapping is embedded in the 
module. Or at least where verse mapping is loaded from a file at run time, and does not need to be hard-coded and compiled into 
the engine. I gather that this also the dream of the Sword development team.</span></font></div></div></blockquote><div><br></div><div>This is exactly what GBBs would be. The versification would be encoded into the module and loaded at the time it gets opened. It&#39;s not kludgy, it&#39;s just the most available solution to the current ask. However, it was never completed because the engine chose to go the route of baked-in v11ns for a number of different reasons. The GBB implementation is significantly more complicated than just hard-coding versifications, and it is more process intensive (while baking them in is more memory intensive but faster on manipulation). These, and other reasons, led to the current av11n system being implemented instead.</div><div><br></div><div>--Greg</div></div></div></div>