[sword-devel] Chapter-centric browsing (was: iPhone frontend alpha screenshots)

[DM Smith]

On Nov 24, 2008, at 1:51 PM, Manfred Bergmann wrote:

>
> Am 24.11.2008 um 18:50 schrieb Ian Wagner:
>
>> On Nov 24, 2008, at 9:17 AM, Jonathan Morgan wrote:
>>
>>> On Tue, Nov 25, 2008 at 1:04 AM,  <seb.sword at koocotte.org> wrote:
>>>> On Mon, Nov 24, 2008 at 07:05:28AM -0500, Ian Wagner wrote:
>>>>>

<snip>...</snip>

>>
>> Have any of you used the Libronix Digital Library System (previously
>> known as Logos bible software)? They actually load up the ENTIRE book
>> (whether it be a bible or commentary or whatnot) so you have a
>> scrollbar indicator about as thick as a credit card :) Just thought
>> I'd throw that out there. I'll have to think about this idea some
>> more.
>>
>
> Accordance for Mac does this, too.
> And I'm always wondering how they get out the speed.
> If I'm pulling out text for the old testament (or a couple of books)
> it takes ages.

I imagine that Accordance stores the text pre-converted to their  
output format (perhaps without compression). And that it can load the  
entire book in a few reads.

SWORD stores the text in OSIS, ThML, GBF, ... and converts it into  
what the application wants via a chain of filters. The maximum number  
of filters is indicated by the number of features a module has. Each  
filter touches the transformed text of the prior filter. Further,  
SWORD does not store the entire verse but recomposes the missing parts  
(e.g. OSIS and ThML verse tags are *never* part of the module).

Also, SWORD does not store the verses in canonical order, but rather  
has an canonically ordered index of offset and length. If the text is  
in KJV canonical order and the append feature of the module creator   
(e.g. osis2mod) is not used, then it will be stored in canonical  
order. When a module is compressed at BOOK level it is assumed that  
the entire BOOK is presented to the module maker at the same time.  
Likewise for CHAPTER, but it is not assumed that they are ordered  
canonically.

In JSword, we have optimized for compression, in that JSword will  
cache the uncompressed block on the assumption that the next fetch is  
likely to be in the same block. I don't know whether SWORD does that.  
It was a huge performance improvement. This also made compressed  
modules faster than uncompressed, as we had fewer open, closes and  
reads, and of a smaller amount of data.


JSword also has a different filter architecture with only two filters  
per module. One converts to input format to OSIS and the other  
converts OSIS to HTML. The latter is via XSLT. This was a huge  
performance improvement to a filter per module feature.

Right now, JSword grabs a verse at a time until it has the requested  
text, just like SWORD does, and filters that. We plan to optimize that  
by analyzing the index to see if the verses arranged in canonical  
order and to read as many contiguous verses as possible. I have not  
been highly motivated to do this as hardware keeps improving and our  
mantra is features and correctness first, optimization second. We have  
also discussed pre-digesting the module into fully constituted,  
unzipped, properly ordered OSIS, storing and indexing that on disk.


>
> The only thing I could imagine is that they load only parts of the
> text and as the user scrolls they load the next or previous sections.

I have done this for lists and it is a great idea for text as well. I  
tried it for text and could not figure out how to know or even closely  
estimate the number of lines, so that I could control the scroll bar  
properly. Given that the iPhone does not have scroll bars, this is not  
necessary.

One of the earlier ideas that discussed was that when a scroll action  
is done at the periphery of the text, it will fetch the indicated  
text. That is, a scroll down at the end of the text would get the next  
chunk. A scroll up at the start of the text would get the previous  
chunk.

What I think would be really cool would be to show a screen full of  
text and vertical and horizontal flicking would get either the next or  
previous page. (For RtoL texts the horizontal will reverse the meaning  
of next and previous.)

In Him,
	DM