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

[Костя Маслюк]

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
facility.


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