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

Костя Маслюк kostyamaslyuk at gmail.com
Wed Feb 26 14:11:32 MST 2014

I would suggest only following at moment:

sword::renderText(std::list<SWModule*> modules, ListKey &passages,
const int renderFlags);

But it require another years to be implemented in Sword and then
implemented in frontends. BibleTime will need to rewrite whole render

2014-02-27 0:45 GMT+04:00 Костя Маслюк <kostyamaslyuk �� gmail.com>:
> Sorry for previous attempt.
> 2014-02-26 23:00 GMT+04:00 Troy A. Griffitts <scribe �� 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.
> Please do not feel accused. I only would like to return to the course
> of constructive dialogue.
>> 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?
> I do not see another way but to leave it as is, and remake it after we
> got any feedback. Few things changed in frontends since your first
> attempt and i doubt anyone thought about it seriously.
>> 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.
> It is not clear to me, what is speed and size of translation (i just
> ask to be crystal clear, because beyond some point i can not
> understand sense of sentence).
> As Chris mentioned performance issues, i would like to remind that i
> have suggested following pipeline (that is implemented yet):
> 1. Create table of mapped verses, at moment there are xml's with
> something like ccel.org use
> I would suggest to move to anything like OSIS if possible, so someone
> can export mapping data from OSIS xml with original text. In other
> words if we could add to osis xml-s with Biblical text some data that
> would tell how particular verse maps to KJV, we will be able to export
> everything from that xml: text, mapping data, canon. At moment there
> is need to make additional file that have canon definition and mapping
> data.
> 2. run python script that convert that xml to c++ compliant data that
> would be inserted to corresponding canon.h file and compile library
> with that data.
> Data that is exposed to engine is optimized and whole system works fast.
> I would like to have common mapping data among both Sword and JSword.
>> 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."
> Again, few people thought about convenience of implementing parallel
> display in own frontend. No one post own ideas on this list about it.
> So i think we are not ready to discuss it at moment.
> My patch only introduce way to find corresponding content among
> different versifications.
> Two points.
> If some one feels strong enough to implement parallel display let him
> have a try and wait his suggestions.
> Second one, parallel display facilities you would like to implement in
> Sword, before my work would be included, will take another long time,
> possibly longer then if we include my work first.
> Release smaller, release often.
> P.S. i agree with general spirit flying on this list, we want changes
> and some movement.
> Blessings
>> 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 �� crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page

More information about the sword-devel mailing list