28.02.2014 23:42 пользователь Troy A. Griffitts scr...@crosswire.org
написал:
Костя,
IOn 02/28/2014 08:14 AM, Костя Маслюк wrote:
Ok.
I have got following:
http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html
Amazing! This looks really great! Daniel 3 is a nice test
Hi
I think I mentioned this before, but the files that JSword use are here:
https://github.com/crosswire/jsword/tree/master/src/main/resources/org/crosswire/jsword/versification
It would indeed be nice if we could use the same format specifications.
The documentation lines 80-ff of the
A couple of extra notes. Where there is no mapping in JSword we assume that
a verse maps to its equivalent. In the left=right, if the left is a single
verse, we allow right to be a verse range. If right is single, then we
allow left to be a verse range.
In terms of the apocrypha, I'm not sure I
Ok.
I have got following:
http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html
And have following modifications:
https://gitorious.org/sword-svn-mirrors/kalemas_at_mail_ru-trunk/source/004904cf1d64c3635fbfac17a3aed7c4c0221738:examples/tasks/parallelbibles.cpp
Tell me whether
Костя,
IOn 02/28/2014 08:14 AM, Костя Маслюк wrote:
Ok.
I have got following:
http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html
Amazing! This looks really great! Daniel 3 is a nice test chapter.
Your output looks very nice. I will play around with your updates to the
In terms of the meta v11n, jsword uses the concept but doesn't actually
define one specifically. It's defined by the mappings in use declared in
each mapping file as opposed to being set in stone once. There is no
Central file defining the meta v11n. We've also designed it in such a way
that you
On Feb 28, 2014, at 2:41 PM, Troy A. Griffitts scr...@crosswire.org wrote:
Костя,
IOn 02/28/2014 08:14 AM, Костя Маслюк wrote:
Ok.
I have got following:
http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html
Amazing! This looks really great! Daniel 3 is a nice test
A verse mapping list wouldn't necessarily be a nightmare. You would
probably need about 300-1000 entries depending on how many versions you
needed mapped. The Hebrew text would need around 200, mostly in the psalms.
The Greek text would need a little less than a hundred in the NT. The LXX
would
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
JSword now has a fairly maintainable human-readable set of mapping files. I
personally haven't come across a use case that we have been unable to cater
for yet. We have seen various issues related to performance, but some of
these have been fixed and others are in the process of. They were partly
26.02.2014 23:00 пользователь Troy A. Griffitts scr...@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
Sorry for previous attempt.
2014-02-26 23:00 GMT+04:00 Troy A. Griffitts scr...@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
I would suggest only following at moment:
sword::renderText(std::listSWModule* 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
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
14 matches
Mail list logo