[sword-devel] Problem with BibleTime ....

[DM Smith]

On Feb 7, 2014, at 5:38 PM, Barry Drake <bdrake at crosswire.org> wrote:

> On 07/02/14 22:15, DM Smith wrote:
>> Each front-end has it's own group, mailing list, forums, .... which have lots of people who are best able to respond to front-end questions.  Some of the BibleTime people are on this list, but you probably will get better response going direct.  I'm interested in what you find. I think your process of creating a new module, modifying SWORD to work with it and getting it to work in a front-end are instructive to us all.
> 
> Thanks for your encouragement DMS.  I think I am still on the gnomesword list, so I'll re-post there tomorrow.  I'll drop a further message onto this list when I've got a bit further.  Am I right in thinking that BibleTime is currently the only frontend that is able to handle Av11n versification schemes?

As far as I know, BibleTime is the only SWORD front-end that does av11n. Xiphos will be if it is not already.

The JSword front-ends cannot benefit from the definition of a canon.h file as it needs to be converted to a JSword code file. The differences are fairly minor. If you want to use JSword to view the module, you'll need to update JSword as well. I mention this because the nightly build of Bible Desktop is nearly av11n ready. And STEP is fully ready. I'm not sure STEP has a desktop client yet.

Below is what JSword does internally:

Each v11n is defined by 4 arrays: two book arrays and two chapter arrays.

The book arrays are simply ordered lists of either OT or NT books. In SWORD there's a lot of redundant information from one v11n canon.h file. The single book list in a canon.h has number of chapters per book as well as  3 variations of the names of the books. In JSword, the names are put in a different resource and are accessed via a symbolic constant.

In JSword, the array of chapters is split into OT and NT arrays. Rather than a single dimension array, JSword uses and array of arrays, indexed by book index and by chapter number.
So it looks something like this:
    /* protected */ static final int[][] LAST_VERSE_NT =
    {
        // Matthew
        {
        //     x0,    x1,    x2,    x3,    x4,    x5,    x6,    x7,    x8,    x9,
                      25,    23,    17,    25,    48,    34,    29,    34,    38,
               42,    30,    50,    58,    36,    39,    28,    27,    35,    30,
               34,    46,    46,    39,    51,    46,    75,    66,    20,
        },
        // Mark
        {
                      45,    28,    35,    41,    43,    56,    37,    38,    50,
               52,    33,    44,    37,    72,    47,    20,
        },
...

By having { } around each books chapters, we can determine the number of chapters in a book with something like:
chapter_count = LAST_VERSE_NT[book_number].length

By splitting it into 4 arrays, we get maximum reuse. Different av11ns may have the same OT or the same NT book lists as another av11n. This allows sharing of OT and NT book lists. Also, OT and NT chapter lists (LAST_VERSE_OT, and LAST_VERSE_NT) can be shared. And they can mix and match. E.g.: Same book lists but different chapter defs.

Like SWORD, the chapter info is an intermediate form that is loaded when needed into an optimized internal form. It is not consulted other than at load time.

With Java, we need to do optimizations like this for performance and for space. It might not be needed for C++, but I'd recommend the change. It'd be transparent to front-ends.

Also, by having each book list be merely a book list of OSIS Bible book names and not a list with lots of other info, it would be trivial to have loader from a text file. Having separate books lists and having predefined, built-in lists allows for aliasing. Likewise, the chapter lists can be one comma separated list of chapter lengths per book per line.

I would love to add this to JSword. But we deliberately lag SWORD.

In Him,
	DM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140207/970ee7f7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140207/970ee7f7/attachment.p7s>