[sword-devel] Parallel display of modules with varying v11ns

Troy A. Griffitts scribe at crosswire.org
Thu Feb 27 22:48:46 MST 2014


?????,

Tonight I spent some time adding a new example to the engine's code 
examples tree for displaying Bibles in parallel.  It basically rips off 
the XHTML header, styles, and footer from SWORDWeb and then executes a 
small, isolated function to output the parallel display.  This small 
function can be our playground to test our stuff to see how we've done.  
This will force us to implement the use case for our work at least once 
to see how ugly the code gets.  Right now, it looks good, like we 
expect, but there is no logic yet to handle any case but 1:1 translation.

I've checked the example in because I think this will be a handy example 
for frontends to follow when we get something working nice.

I feel it is important, before we commit to an API mechanism, that we 
consume that mechanism at least once, trying to solve the use case for 
which it was conceived-- at least at a basic level.

Those who are interested to just see the minimum code required to 
display in parallel, but don't wish to check out the latest SVN, can 
have a look here (at the parallelDisplay(...) method):

http://crosswire.org/svn/sword/trunk/examples/tasks/parallelbibles.cpp

the example can be run and tested with something like:

./parallelbibles KJV ESV jn.3.16 > paralleltest.html
firefox paralleltest.html

You can see the output from this test run here:
http://crosswire.org/~scribe/paralleltest.html

Let's collaborate! :)

Troy







On 02/26/2014 02:56 PM, ????? ?????? wrote:
>
> Oh, i just get what you meant about speed and size of translation. 
> What you would like to achieve beyond i have implemented? It is 
> optimized in speed and is very lightweight in size.
>
> As a bonus it can be  used in per translation versification concept.
>
> The only thing i would like to change is to slightly increase size, 
> adding one byte per rule to store rule type, so it can handle 
> difficult cases in future with backward compatibility.
>
> 26.02.2014 23:00 ???????????? "Troy A. Griffitts" 
> <scribe at crosswire.org <mailto:scribe at crosswire.org>> ???????:
>
>     One positive thing from the previous thread is the reminder of
>     Kosta's proposed implementation for translation between modules of
>     varying v11n.
>
>     The accusation of irresponsibility is warranted, not for delaying
>     the patch submission, but for delaying the discussion toward a
>     resolution and buyin by a consensus of frontends.
>
>     To sum up:
>
>     We have refactored and isolated translation to a single point
>     within the engine. Basically, when you set the value of one
>     VerseKey from a VerseKey with differing v11n, translation will
>     happen. This propogates naturally to many places in the engine.
>     For example it will allow one to set the LXX module from a key
>     obtained from the KJV module:
>
>     lxx.setKey(KJV.getKey());
>
>
>     The question still on the table is: how useful is this for the
>     primary use case of displaying in parallel modules with varying v11ns?
>
>     A secondary question is how can we optimize, in both speed and
>     size, the translation. The JSword team is beginning to implement
>     their own mechanism and I would like to hear about their experience.
>
>     There are open threads on this with many of my, and others,
>     thoughts and concerns. I would appreciate it if commenters might
>     consider searching the list history before commenting.
>
>     My theoretical question is, what logic do we want to use to create
>     a parallel display? There are many hard cases we haven't resolved,
>     even if the resolution is "we simply don't handle that, and what
>     you'll see is X."
>
>     I know the STEP tools have a parallel display implementation. I
>     have no idea if its behavior in corner cases is acceptable to most.
>
>     -- 
>     Sent from my Android device with K-9 Mail. Please excuse my brevity.
>     _______________________________________________
>     sword-devel mailing list: sword-devel at crosswire.org
>     <mailto:sword-devel at crosswire.org>
>     http://www.crosswire.org/mailman/listinfo/sword-devel
>     Instructions to unsubscribe/change your settings at above page
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140227/23ae3c72/attachment.html>


More information about the sword-devel mailing list