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, <[EMAIL PROTECTED]> 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
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
