<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Костя,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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):<br>
<br>
<a class="moz-txt-link-freetext" href="http://crosswire.org/svn/sword/trunk/examples/tasks/parallelbibles.cpp">http://crosswire.org/svn/sword/trunk/examples/tasks/parallelbibles.cpp</a><br>
<br>
the example can be run and tested with something like:<br>
<br>
./parallelbibles KJV ESV jn.3.16 > paralleltest.html<br>
firefox paralleltest.html<br>
<br>
You can see the output from this test run here:<br>
<a class="moz-txt-link-freetext" href="http://crosswire.org/~scribe/paralleltest.html">http://crosswire.org/~scribe/paralleltest.html</a><br>
<br>
Let's collaborate! :)<br>
<br>
Troy<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 02/26/2014 02:56 PM, Костя Маслюк wrote:<br>
</div>
<blockquote
cite="mid:CAPOzG3kD_3v6m_SYE_Fmdpi2KK-85SjGYkK1hJRTTqmwdP6XoA@mail.gmail.com"
type="cite">
<p dir="ltr">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.</p>
<p dir="ltr">As a bonus it can be used in per translation
versification concept.</p>
<p dir="ltr">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.<br>
</p>
<div class="gmail_quote">26.02.2014 23:00 пользователь "Troy A.
Griffitts" <<a moz-do-not-send="true"
href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>>
написал:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
One positive thing from the previous thread is the reminder of
Kosta's proposed implementation for translation between
modules of varying v11n.<br>
<br>
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.<br>
<br>
To sum up:<br>
<br>
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:<br>
<br>
lxx.setKey(KJV.getKey());<br>
<br>
<br>
The question still on the table is: how useful is this for the
primary use case of displaying in parallel modules with
varying v11ns?<br>
<br>
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.<br>
<br>
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. <br>
<br>
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."<br>
<br>
I know the STEP tools have a parallel display implementation.
I have no idea if its behavior in corner cases is acceptable
to most.<br>
<br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my
brevity.<br>
_______________________________________________<br>
sword-devel mailing list: <a moz-do-not-send="true"
href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a moz-do-not-send="true"
href="http://www.crosswire.org/mailman/listinfo/sword-devel"
target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
</blockquote>
<br>
</body>
</html>