Re: [sword-devel] Chapter descriptions

2020-05-09 Thread Michael H
Yes, the AKJV chapter indexes use the original KJV chapter index (a 1708
copy specifically,) but I wordsearched the wordlist in the AKJV appendix.

But if I did it again, I'd mark them up with links (\xt ... \xt*). This
tag's use in this context is new to USFM 3, and I didn't catch it until
recently when there was an issue about \xt being allowed outside of \x ...
\x* on the  u2o code... but if I were starting AKJV today, I'd mark them
like the note about attributes on \xt (the one showing Russian Synodal.)
 That won't convert from USFM yet, but it's on the roadmap for u2o.py .

https://ubsicap.github.io/usfm/notes_basic/xrefs.html#xt

On Sat, May 9, 2020 at 1:58 PM DM Smith  wrote:

> In the AKJV link you gave, line 11 is:
>
> \cd 1 Elimelech driven by famine into Moab, dies there. 4 Mahlon and
> Chilion, having married wives of Moab, die also. 6 Naomi returning
> homeward, 8 dissuades her two daughters in law from going with her, 14
> Orpah leaves her, but Ruth with great constancy accompanies her. 19 They
> two come to Bethlehem, where they are gladly received.
>
> Is that what you are calling a chapter index?
>
> David and I have been wondering how we should mark those up in OSIS for
> the KJV 1769.
>
> I think that chapter also has titles.
>
> In Him,
> DM
>
> On May 9, 2020, at 12:43 PM, Michael H  wrote:
>
> Reading the list of provided tags, these chapter descriptions should be
> marked ".index" when they provide reference information, and ".summary"
> where they do not.  That is, the original KJV1611 has chapter indexes.  The
> original Douay Rheims Challoner has Chapter summaries. The recent update to
> the CPDV includes chapter summaries. The AKJV update includes Chapter
> indexes (which is ready, but I haven't heard from Peter on how to proceed.)
>
> CPDV with chapter summaries:
>
> https://gitlab.com/cmahte/cpdv/-/blob/master/usfm/08-RUT-ENG%5BB%5DCPDV2009%5Bpd%5D.p.sfm
>
> AKJV with chapter indexes:
>
> https://github.com/BibleCorps/ENG-B-AKJV2018-pd-PSFM/blob/master/p.sfm/ENG%5BB%5DAKJV2018%5BPD%5D08-RUT.p.sfm
>
>
>
> On Sat, May 9, 2020 at 10:51 AM DM Smith  wrote:
>
>> See the wiki!!!
>> https://wiki.crosswire.org/Osis2mod#Handling_of_Introductions.2C_Titles_and_Inter-Verse_Material
>>
>> DM
>>
>> On May 9, 2020, at 2:14 AM, David Haslam  wrote:
>>
>> Discussion starter
>>
>> OSIS has no dedicated element specifically for a chapter description.
>>
>> These are not section titles per se but they come before verse 1.
>>
>> In printed Bibles, they are typically in italics and are never in bold.
>> Usually centred and often contain verse numbers that could be thought of as
>> references to locate the text described following. They can flow onto more
>> than one line in pages with two columns of text. In some editions these are
>> allowed to be full page width rather than column width. The text size is
>> never larger than verse text.
>>
>> The Blayney 1769 Oxford edition of the KJV has such chapter descriptions.
>>
>> How best to mark these ?
>>
>> Best regards
>>
>> David
>>
>> Sent from ProtonMail Mobile
>> ___
>> 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
>>
>>
>> ___
>> 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
>
> ___
> 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
>
>
> ___
> 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
___
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

Re: [sword-devel] Chapter descriptions

2020-05-09 Thread DM Smith
In the AKJV link you gave, line 11 is:

\cd 1 Elimelech driven by famine into Moab, dies there. 4 Mahlon and Chilion, 
having married wives of Moab, die also. 6 Naomi returning homeward, 8 dissuades 
her two daughters in law from going with her, 14 Orpah leaves her, but Ruth 
with great constancy accompanies her. 19 They two come to Bethlehem, where they 
are gladly received.

Is that what you are calling a chapter index?

David and I have been wondering how we should mark those up in OSIS for the KJV 
1769.

I think that chapter also has titles.

In Him,
DM

> On May 9, 2020, at 12:43 PM, Michael H  wrote:
> 
> Reading the list of provided tags, these chapter descriptions should be 
> marked ".index" when they provide reference information, and ".summary" where 
> they do not.  That is, the original KJV1611 has chapter indexes.  The 
> original Douay Rheims Challoner has Chapter summaries. The recent update to 
> the CPDV includes chapter summaries. The AKJV update includes Chapter indexes 
> (which is ready, but I haven't heard from Peter on how to proceed.)
> 
> CPDV with chapter summaries: 
> https://gitlab.com/cmahte/cpdv/-/blob/master/usfm/08-RUT-ENG%5BB%5DCPDV2009%5Bpd%5D.p.sfm
>  
> 
> 
> AKJV with chapter indexes: 
> https://github.com/BibleCorps/ENG-B-AKJV2018-pd-PSFM/blob/master/p.sfm/ENG%5BB%5DAKJV2018%5BPD%5D08-RUT.p.sfm
>  
> 
> 
> 
> On Sat, May 9, 2020 at 10:51 AM DM Smith  > wrote:
> See the wiki!!! 
> https://wiki.crosswire.org/Osis2mod#Handling_of_Introductions.2C_Titles_and_Inter-Verse_Material
>  
> 
> 
> DM
> 
>> On May 9, 2020, at 2:14 AM, David Haslam > > wrote:
>> 
>> Discussion starter
>> 
>> OSIS has no dedicated element specifically for a chapter description. 
>> 
>> These are not section titles per se but they come before verse 1. 
>> 
>> In printed Bibles, they are typically in italics and are never in bold. 
>> Usually centred and often contain verse numbers that could be thought of as 
>> references to locate the text described following. They can flow onto more 
>> than one line in pages with two columns of text. In some editions these are 
>> allowed to be full page width rather than column width. The text size is 
>> never larger than verse text. 
>> 
>> The Blayney 1769 Oxford edition of the KJV has such chapter descriptions. 
>> 
>> How best to mark these ?
>> 
>> Best regards
>> 
>> David
>> 
>> Sent from ProtonMail Mobile
>> ___
>> 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
> 
> ___
> 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
> ___
> 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

___
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

Re: [sword-devel] NASB Psalm titles

2020-05-09 Thread David Haslam
Troy wrote,

"No. diatheke is certainly not the gold standard for seeing anything. 
Diatheke has bugs of its own.
I personally use word/examples/cmdline/lookup.cpp to check all info 
about what SWORD output from a module entry to a frontend for a particular 
format.
Diatheke is not a bad tool to use, but it is certainly not considered 
any kind of standard.  I have no idea why it is, for example, showing headings 
AFTER verse 1.  This is certainly a bug and has likely been fixed since the 
version you are using."

-

FWIW, The Windows versions of diatheke still output the Psalm title AFTER verse 
1 for the KJV and other modules.

And in this respect, the copy of diatheke.exe installed with Xiphos (x32) 
version 4.2.1 (just released) still behaves the same.

Has this been ever made a tracker issue under MODTOOLs ?

Best regards,

David

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Saturday, 9 May 2020 09:23, Fr Cyrille  wrote:

> Hi Tom,
> It's very easy to create a deb with the xiphos sources. Just see the
> "Generating DEB Packages" in the install.md. Then you'll have the last
> release.
>
> Le 08/05/2020 à 19:59, Tom Sullivan a écrit :
>
> > Y'all:
> > Thank you all for your interactions. I honestly have been trying to
> > help, not just waste everybody's time. But I am not a C++ programmer.
> > I know enough Python to be dangerous. I can do some occasional
> > maintenance on C. All the languages I once knew are obsolete or
> > specific to Microsoft, whom I finally just had to divorce with extreme
> > disgust. I am still learning, but slowly.
> > Thus, I hope I can be extended some charity here as a "weaker brother"
> > with respect to the above and below remarks.
> > Documentation is a weak point in Linux generally, and has been a
> > problem for me and others in spades with Crosswire related stuff. One
> > solution for some of the versions issue would be to:
> >
> > 1.  Document somewhere what are the latest versions and how to find out
> > one's current version.
> >
> > 2.  Programs should have an option to check for a newer version each
> > time they are started and report new versions to the user.
> >
> > 3.  For main distros, even though it may not be possible to get
> > something in the official repository, provide a package somewhere to
> > download. For example, for Debian, a *.deb.
> >
> > 4.  Provide scripts that will work and allow one to compile the latest
> > version without requiring the user to know a lot. Even a list of
> > commands that can be copied and pasted one by one would be better than
> > nothing.
> >
> >
> > The reference to [NASB] ... was for Karl.
> > How do I find out the version of Sword from the command line without
> > using osis2mod?
> > And, I thought Diatheke came with Sword? When Sword was updated awhile
> > back was it not updated also?
> > Re: your using:
> > sword/examples/cmdline/lookup.cpp
> > You can do that. I can't. I do not know C++. You guys are all way
> > above me technically. When something goes wrong, I generally have no
> > idea how to fix it.
> > Sorry for the trouble. Perhaps some of my suggestions above will make
> > things easier for all of us. For example, if my Diatheke is obsolete,
> > I have no way of knowing and still do not know if it is obsolete or not.
> >
> > Tom Sullivan
> > i...@beforgiven.info
> > FAX: 815-301-2835
> >
> > 
> >
> > Great News!
> > God created you, owns you and gave you commands to obey.
> > You have disobeyed God - as your conscience very well attests to you.
> > God's holiness and justice compel Him to punish you in Hell.
> > Jesus Christ became Man, was crucified, buried and rose from the dead
> > as a substitute for all who trust in Him, redeeming them from Hell.
> > If you repent (turn from your sin) and believe (trust) in Jesus Christ,
> > you will go to Heaven. Otherwise you will go to Hell.
> > Warning! Good works are a result, not cause, of saving trust.
> > More info is at www.esig.beforgiven.info
> > Do you believe this? Copy this signature into your email program
> > and use the Internet to spread the Great News every time you email.
> > On 5/8/20 1:19 PM, Troy A. Griffitts wrote:
> >
> > > So, a few things here.
> > > On 5/8/20 9:57 AM, Tom Sullivan wrote:
> > >
> > > > Troy, Karl:
> > > > (Karl:
> > > > [NASB]
> > > > Heading=On)
> > >
> > > I have no idea what you are showing here.  This looks like a .conf
> > > setting.  Xiphos may pay attention to Heading=On, but this doesn't mean
> > > anything to SWORD.
> > >
> > > > I am using Debian Buster (10) (stable). This is the current stable
> > > > version of Debian and is the one generally recommended. It is the
> > > > version those of us who have work to do use, rather than mess with a
> > > > buggy OS. (There is a more recent Debian version generally titled
> > > > testing, but it is not as reliable.)
> > > > I have 

Re: [sword-devel] Chapter descriptions

2020-05-09 Thread Michael H
Reading the list of provided tags, these chapter descriptions should be
marked ".index" when they provide reference information, and ".summary"
where they do not.  That is, the original KJV1611 has chapter indexes.  The
original Douay Rheims Challoner has Chapter summaries. The recent update to
the CPDV includes chapter summaries. The AKJV update includes Chapter
indexes (which is ready, but I haven't heard from Peter on how to proceed.)

CPDV with chapter summaries:
https://gitlab.com/cmahte/cpdv/-/blob/master/usfm/08-RUT-ENG%5BB%5DCPDV2009%5Bpd%5D.p.sfm

AKJV with chapter indexes:
https://github.com/BibleCorps/ENG-B-AKJV2018-pd-PSFM/blob/master/p.sfm/ENG%5BB%5DAKJV2018%5BPD%5D08-RUT.p.sfm



On Sat, May 9, 2020 at 10:51 AM DM Smith  wrote:

> See the wiki!!!
> https://wiki.crosswire.org/Osis2mod#Handling_of_Introductions.2C_Titles_and_Inter-Verse_Material
>
> DM
>
> On May 9, 2020, at 2:14 AM, David Haslam  wrote:
>
> Discussion starter
>
> OSIS has no dedicated element specifically for a chapter description.
>
> These are not section titles per se but they come before verse 1.
>
> In printed Bibles, they are typically in italics and are never in bold.
> Usually centred and often contain verse numbers that could be thought of as
> references to locate the text described following. They can flow onto more
> than one line in pages with two columns of text. In some editions these are
> allowed to be full page width rather than column width. The text size is
> never larger than verse text.
>
> The Blayney 1769 Oxford edition of the KJV has such chapter descriptions.
>
> How best to mark these ?
>
> Best regards
>
> David
>
> Sent from ProtonMail Mobile
> ___
> 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
>
>
> ___
> 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
___
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

Re: [sword-devel] Chapter descriptions

2020-05-09 Thread DM Smith
See the wiki!!! 
https://wiki.crosswire.org/Osis2mod#Handling_of_Introductions.2C_Titles_and_Inter-Verse_Material
 


DM

> On May 9, 2020, at 2:14 AM, David Haslam  wrote:
> 
> Discussion starter
> 
> OSIS has no dedicated element specifically for a chapter description. 
> 
> These are not section titles per se but they come before verse 1. 
> 
> In printed Bibles, they are typically in italics and are never in bold. 
> Usually centred and often contain verse numbers that could be thought of as 
> references to locate the text described following. They can flow onto more 
> than one line in pages with two columns of text. In some editions these are 
> allowed to be full page width rather than column width. The text size is 
> never larger than verse text. 
> 
> The Blayney 1769 Oxford edition of the KJV has such chapter descriptions. 
> 
> How best to mark these ?
> 
> Best regards
> 
> David
> 
> Sent from ProtonMail Mobile
> ___
> 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

___
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

Re: [sword-devel] Chapter descriptions

2020-05-09 Thread Karl Kleinpaste
On 5/9/20 2:14 AM, David Haslam wrote:
> OSIS has no dedicated element specifically for a chapter description.
> These are not section titles per se but they come before verse 1. 

Xiphos since 4.1 renders 0:0 and n:0 material as ".introMaterial",
default italic.
See ESV2011, any book's chapter 1.
It's been suggested that it should be simply ".introduction" and perhaps
that's right.
___
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

Re: [sword-devel] Shared format / persistence concept for tagged verse lists (originated in thread about Versification Mapping)

2020-05-09 Thread ref...@gmx.net
Live-sharing is a matter of BibleSync. .I think a common transfer format for complicated book mark trees which is designed well from bottom up and could be published similarly to BibleSync would be brilliantPeterSent from my mobile. Please forgive shortness, typos and weird autocorrects. Original Message Subject: [sword-devel] Shared format / persistence concept for tagged verse lists (originated in thread about Versification Mapping)From: Tobias Klein To: SWORD Developers' Collaboration Forum CC: 
  
  
On 5/9/20 10:08 AM, Caleb Maclennan
  wrote:


  

  On Sat, May 9, 2020 at 9:45
AM Tobias Klein 
wrote:
  
  
Something more realistic than a shared storage backend
  would be a shared export / import format. This I think may
  be worthwhile to pursue. We could simply agree on a
  certain json or xml format for this.
  @all: Who would be interested in this in general? We could
  start with tags / topical verse lists.
  
  
  
  I would.
  
  
  For my tastes and potential use cases something that
split the difference between a complete live persistence and
a static import/export would be  much more useful.
Specifically I would like to intervene in the middle of the
import/export process and store the dump format in version
control. If the format were carefully considered with this
use case in mind this would allow merging content from
different sources and basically providing a synchronization
mechanism. Not a live persistent connection perse, but with
a little outside setup it could be used as an
eventually-consistent sync mechanism. How much hand holding
would go into fixing merge conflicts would be dependent on
how well thought out the schema was.

  


  "Intervene" in the middle of the import/export process - can you
  eloborate a bit more on this, Caleb?
  
  To me this simply sounds like "Use Git (or whatever other SCM) as
  a storage backend for text-format based tagged verse list files".
  
  Best regards,
  Tobias

  

___
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

[sword-devel] Chapter descriptions

2020-05-09 Thread David Haslam
Discussion starter

OSIS has no dedicated element specifically for a chapter description.

These are not section titles per se but they come before verse 1.

In printed Bibles, they are typically in italics and are never in bold. Usually 
centred and often contain verse numbers that could be thought of as references 
to locate the text described following. They can flow onto more than one line 
in pages with two columns of text. In some editions these are allowed to be 
full page width rather than column width. The text size is never larger than 
verse text.

The Blayney 1769 Oxford edition of the KJV has such chapter descriptions.

How best to mark these ?

Best regards

David

Sent from ProtonMail Mobile___
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

Re: [sword-devel] NASB Psalm titles

2020-05-09 Thread David Haslam
This is also a challenge for using USFM,  let alone OSIS and SWORD front-ends.

In some AV11N, the CT is sometimes only part of verse 1.

There are also at least 2 Psalms where the CT extends into verse 2 and 1 Psalm 
where the CT actually creeps into verse 3 with a single word consisting of a 
verb participle!

I leave the locations as an exercise for the reader. Fluency in French helps. ;)

As for USFM, the following is valid and correct, and would be accepted in 
ParaTExt.

\d \v 1 A Psalm of David
\q O Lord 

It’s not immediately apparent how best to convert this to OSIS 

David

Sent from ProtonMail Mobile

On Sat, May 9, 2020 at 03:35, DM Smith  wrote:

> While the OSIS spec has one definition of canonical, being part of the 
> published text. Regarding Bibles, Troy pointed out, we use it in the 
> theological sense for Bible modules.
>
> There are many versifications that have the canonical titles as verse 1. and 
> what we have as verse 1 to n in verse 2 to n + 1.
>
> I once surveyed all of our modules for verse 3.0 and verse 3.1 to note how 
> they handled the canonical Psalm title. It was very inconsistent. Some had it 
> in verse 0, some had it in verse 1. Many didn’t have it marked as canonical. 
> That’s an entirely issue than what we are talking about here.
>
> In Him,
> DM
>
>> On May 8, 2020, at 10:49 AM, Tom Sullivan  wrote:
>>
>> Y'all:
>>
>> My Biblia Hebraica treats Psalm titles as the first verse, indicating 
>> biblical canonacity and in line with Hebrew versification.
>>
>> Note the following from OSIS doc, OSIS.pdf:
>>
>> Appendix B.2.10 titles
>> The type attribute on the title element is used to allow special rendering 
>> of particular titles, as well as
>> searching for particular types of titles in the text.identify the type of 
>> note that appears in the text. Note that
>> the values for the type attribute must be entered exactly as shown, all 
>> others must use the "x-" extension
>> mechanism.
>> If the user needs to record a type of title in the text that is not covered 
>> by these values, please use the OSIS
>> attribute extension mechanism, "x-" in front of the name of your value for 
>> this attribute.
>> .
>> .
>> psalm Use in the Psalms where what are considered "titles" in the English 
>> text are actually numbered
>> as verses in the Hebrew text.
>>
>> David's point about canonicity is well taken, but we must consider:
>> 1. Are we considering canonicity with respect to the NASB as published,
>> OR
>> 2. Are we considering canonicity with respect to how the NASB publishers saw 
>> it, that is that the Scripture text is cannonical. If we make this decision, 
>> we are simply electronically duplicating the paper publication.
>>
>> IMHO, 2. is the far better choice.
>>
>> Hope this helps, and thanks again to all.
>>
>> Tom Sullivan
>> i...@beforgiven.info
>> FAX: 815-301-2835
>> -
>>
>> On 5/8/20 10:28 AM, David Haslam wrote:
>>> One of the subtleties of OSIS is that the canonical attribute is actually 
>>> not a theological matter.
>>> It’s easy to jump to the wrong conclusion that SWORD treats it as if it was.
>>> It’s actually a technical attribute relating to the published work it 
>>> represents in digital format.
>>> So it can just as well appear in a Commentary module as a Bible module.
>>> Anything with canonical=“false” should in theory at least be only because 
>>> the marked text was not in the original work.
>>> Then the question becomes “What was the original work?”
>>> I will leave you to ponder
>>> David
>>> Sent from ProtonMail Mobile
>>> On Fri, May 8, 2020 at 15:09, Karl Kleinpaste >> > wrote:
 On 5/8/20 10:00 AM, Tom Sullivan wrote:
 > because Psalm titles are canonical, front-ends should put a difference
 > in display between them and human editor supplied titles.

 It's a fine idea, but it requires (in the xhtml case) the engine to wrap
 such titles in a suitable  so that a CSS control can put it
 to use, with appropriate new default render header content for it.

 ___
 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
>>> __
>>> This email has been scanned by the Symantec Email Security.cloud service.
>>> For more information please visit http://www.symanteccloud.com
>>> __
>>> ___
>>> 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
>>
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> 

[sword-devel] Shared format / persistence concept for tagged verse lists (originated in thread about Versification Mapping)

2020-05-09 Thread Tobias Klein

On 5/9/20 10:08 AM, Caleb Maclennan wrote:
On Sat, May 9, 2020 at 9:45 AM Tobias Klein > wrote:


Something more realistic than a shared storage backend would be a
shared export / import format. This I think may be worthwhile to
pursue. We could simply agree on a certain json or xml format for
this.
@all: Who would be interested in this in general? We could start
with tags / topical verse lists.


I would.

For my tastes and potential use cases something that split the 
difference between a complete live persistence and a static 
import/export would be  much more useful. Specifically I would like to 
intervene in the middle of the import/export process and store the 
dump format in version control. If the format were carefully 
considered with this use case in mind this would allow merging content 
from different sources and basically providing a synchronization 
mechanism. Not a live persistent connection perse, but with a little 
outside setup it could be used as an eventually-consistent sync 
mechanism. How much hand holding would go into fixing merge conflicts 
would be dependent on how well thought out the schema was.



"Intervene" in the middle of the import/export process - can you 
eloborate a bit more on this, Caleb?


To me this simply sounds like "Use Git (or whatever other SCM) as a 
storage backend for text-format based tagged verse list files".


Best regards,
Tobias

___
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

Re: [sword-devel] NASB Psalm titles

2020-05-09 Thread Fr Cyrille
Hi Tom,
It's very easy to create a deb with the xiphos sources. Just see the
"Generating DEB Packages" in the install.md. Then you'll have the last
release.

Le 08/05/2020 à 19:59, Tom Sullivan a écrit :
> Y'all:
>
> Thank you all for your interactions. I honestly have been trying to
> help, not just waste everybody's time. But I am not a C++ programmer.
> I know enough Python to be dangerous. I can do some occasional
> maintenance on C. All the languages I once knew are obsolete or
> specific to Microsoft, whom I finally just had to divorce with extreme
> disgust. I am still learning, but slowly.
>
> Thus, I hope I can be extended some charity here as a "weaker brother"
> with respect to the above and below remarks.
>
> Documentation is a weak point in Linux generally, and has been a
> problem for me and others in spades with Crosswire related stuff. One
> solution for some of the versions issue would be to:
> 1. Document somewhere what are the latest versions and how to find out
> one's current version.
> 2. Programs should have an option to check for a newer version each
> time they are started and report new versions to the user.
> 2. For main distros, even though it may not be possible to get
> something in the official repository, provide a package somewhere to
> download. For example, for Debian, a *.deb.
> 3. Provide scripts that will work and allow one to compile the latest
> version without requiring the user to know a lot. Even a list of
> commands that can be copied and pasted one by one would be better than
> nothing.
>
> The reference to [NASB] ... was for Karl.
>
> How do I find out the version of Sword from the command line without
> using osis2mod?
>
> And, I thought Diatheke came with Sword? When Sword was updated awhile
> back was it not updated also?
>
> Re: your using:
> sword/examples/cmdline/lookup.cpp
> You can do that. I can't. I do not know C++. You guys are all way
> above me technically. When something goes wrong, I generally have no
> idea how to fix it.
>
> Sorry for the trouble. Perhaps some of my suggestions above will make
> things easier for all of us. For example, if my Diatheke is obsolete,
> I have no way of knowing and still do not know if it is obsolete or not.
>
> Tom Sullivan
> i...@beforgiven.info
> FAX: 815-301-2835
> -
> Great News!
> God created you, owns you and gave you commands to obey.
> You have disobeyed God - as your conscience very well attests to you.
> God's holiness and justice compel Him to punish you in Hell.
> Jesus Christ became Man, was crucified, buried and rose from the dead
> as a substitute for all who trust in Him, redeeming them from Hell.
> If you repent (turn from your sin) and believe (trust) in Jesus Christ,
> you will go to Heaven. Otherwise you will go to Hell.
> Warning! Good works are a result, not cause, of saving trust.
> More info is at www.esig.beforgiven.info
> Do you believe this? Copy this signature into your email program
> and use the Internet to spread the Great News every time you email.
>
> On 5/8/20 1:19 PM, Troy A. Griffitts wrote:
>> So, a few things here.
>>
>> On 5/8/20 9:57 AM, Tom Sullivan wrote:
>>> Troy, Karl:
>>>
>>> (Karl:
>>> [NASB]
>>> Heading=On)
>>
>> I have no idea what you are showing here.  This looks like a .conf
>> setting.  Xiphos may pay attention to Heading=On, but this doesn't mean
>> anything to SWORD.
>>
>>
>>> I am using Debian Buster (10) (stable). This is the current stable
>>> version of Debian and is the one generally recommended. It is the
>>> version those of us who have work to do use, rather than mess with a
>>> buggy OS. (There is a more recent Debian version generally titled
>>> testing, but it is not as reliable.)
>>>
>>> I have mentioned my versions before. Others can comment on their
>>> current status:
>>>
>>> Diatheke: 4.7
>>> Xiphos: 4.1.0
>>> Sword (from osis2mod): 3431 (This should be current as I compiled for
>>> the new version when it came out earlier.)
>>
>> So, you are not reporting the version of SWORD you are using if you are
>> getting that information from osis2mod.  osis2mod shows the last edited
>> revision of the osis2mod utility.  That tools hasn't been updated since
>> 2016, so it will report that revision.  SWORD is currently at 3725
>>
>>
>>> I understand that there is a new version of Xiphos, but Xiphos is not
>>> the only program not showing Psalm titles. (I hope to see a Debian
>>> package for Xiphos soon, if not when I get a chance, I can try to
>>> compile, but that always has difficulties.)
>>>
>>> I repeat here the results from Diatheke:
>>> (I was given to understand that this is the gold standard for seeing
>>> if the problem is in the module or Sword vs. front-ends.)
>>>
>> No.  diatheke is certainly not the gold standard for seeing anything.
>> Diatheke has bugs of its own.  I personally use
>> sword/examples/cmdline/lookup.cpp to check all info about what SWORD
>> output from a module entry to a frontend for a particular format.

Re: [sword-devel] SWORD search issue / search type multi Word

2020-05-09 Thread Tobias Klein

I have a finding regarding the search results.

Module: NASB

Search term: "faith Jesus"

Search type: multiWord (-2)

Search boundaries: Regular (without strict flag)

Among others I get Ephesians 2:7 and Ephesians 3:11 as search results. 
Both contain the word "Jesus".
However, the respective second verse (Ephesians 2:8 and Ephesians 3:12) 
which does contain the word "faith" is not returned as a search result 
even though I would expect it here.


Best regards,
Tobias

On 5/5/20 8:12 AM, Tobias Klein wrote:


Thank you, Troy! I appreciate it.

I'm using this new search flag now and I'm getting exactly the results 
that I would expect.


I think it's a good idea to make this configurable. I'm now also 
considering to add an option to my user interface to be able to toggle 
this option.


Tobias

On 5/5/20 2:00 AM, Troy A. Griffitts wrote:


Dear Tobias,

I have spent a bit of time documenting this a bit better in trunk and 
have added a new flag (SEARCHFLAG_STRICTBOUNDARIES) to turn off the 
default behavior to use a sliding window to find results.


When performing a multiword (non-indexed) search with the NASB using 
your 2 terms, I now get these hit counts:


no flags: 86

REG_ICASE: 93

REG_ICASE | SEARCHFLAG_STRICTBOUNDARIES: 51


Hope this helps,

Troy



On 5/4/20 1:15 PM, Tobias Klein wrote:


Hi,

I have the impression that the SWORD multi word search is returning 
some results that actually do not seem to match the search term.


For example when searching for the term "faith Jesus" in the NASB 
module I get 86 results.


The first result that seems invalid is Matthew 9:28:

^28 When He entered the house, the blind men came 
up to Him, and Jesus said to them, " “Do you believe that I am able 
to do this?”" They said to Him, “Yes, Lord.”


This verse matches only part of the multi word term, namely "Jesus".

Matthew 9:29 is also returned as a result and this verse 
interestingly only matches the other part of the term ("faith"):


^29 Then He touched their eyes, saying, " “It shall be done to you 
according to your faith.”"


What is happening here? My assumption would be that only verses 
containing both parts of the multi word term should be returned if 
the searchType is multiWord (-2). Is this a bug?


The code can be found here: 
https://github.com/tobias-klein/node-sword-interface/blob/master/src/sword_backend/module_search.cpp#L121


Best regards,
Tobias


___
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


___
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


___
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
___
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

Re: [sword-devel] Versification Mapping

2020-05-09 Thread Caleb Maclennan
On Sat, May 9, 2020 at 9:45 AM Tobias Klein  wrote:

> @all: Who would be interested in this in general? We could start with tags
> / topical verse lists.
>

I would.

For my tastes and potential use cases something that split the difference
between a complete live persistence and a static import/export would be
much more useful. Specifically I would like to intervene in the middle of
the import/export process and store the dump format in version control. If
the format were carefully considered with this use case in mind this would
allow merging content from different sources and basically providing a
synchronization mechanism. Not a live persistent connection perse, but with
a little outside setup it could be used as an eventually-consistent sync
mechanism. How much hand holding would go into fixing merge conflicts would
be dependent on how well thought out the schema was.
___
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

Re: [sword-devel] Versification Mapping

2020-05-09 Thread Tobias Klein

Thanks, Troy!

These numbers below look excellent! I will look into using the 
VerseKey-based mapping approach for Ezra Project. However, it's going to 
be a significant refactoring effort, so I'm probably not going to get 
back with implementation-based feedback any time soon. I just created an 
Issue for Ezra Project 
 and I think 
this will be part of 0.14.0 (The release after the one I'm working on 
currently).


Regarding a shared/common bookmarking and tagging concept the question 
is whether we only talk about a shared "export / import format" or 
whether we talk about a complete persistence backend that could be 
shared. Currently I'm storing my user data in a SQLite database and it 
works well (including automated migrations in case of db schema changes 
that are applied with new versions of the application). I could imagine 
that even the discussion about the storage backend could take a while in 
terms of alignment. I realize that developers have quite different taste 
when it comes to stuff like this. Also the question would be why this 
should be limited to tags. In general it also applies to any other user 
data like notes or user markup for the bible text.


Something more realistic than a shared storage backend would be a shared 
export / import format. This I think may be worthwhile to pursue. We 
could simply agree on a certain json or xml format for this.
@all: Who would be interested in this in general? We could start with 
tags / topical verse lists.


The data model in Ezra Project is currently rather simple. It's just a 
flat list of tags where each tag can be assigned to any verse. In my 
database I currently have three tables to support this. Tags (the actual 
list of topics/keywords), VerseTags (the join/assignment table) and 
VerseReferences (the abstract/module-independent objects tags get 
assigned to).


A tree introduces additional challenges in the user interface. I've been 
thinking about introducing a tree structure for the tags, not anytime 
soon though ... it's a rather big effort from a user interface perspective.


I'm certainly curious about further input to this discussion.

Tobias

On 5/7/20 6:54 PM, Troy A. Griffitts wrote:


Dear Tobias,

I would recommend KJVA, so you can get the Apocrypha.  I believe this 
is the common base Костя uses to convert between systems.  Костя has 
done a great job at optimization.  I've updated the verseconvert.cpp 
example to allow ranges.  Here is a timing for the entire book of Psalms:


[scribe@localhost classes]$ time ./verseconvert Ps Wycliffe 
FreGeneve1669 > /dev/null


real    0m0.195s
user    0m0.162s
sys    0m0.033s

My guess is that most of that time is simply with SWORD engine 
initialization, discovering and opening my library.


Converting all verses in both Old and New Testament:

[scribe@localhost classes]$ time ./verseconvert Gen-Rev Wycliffe 
FreGeneve1669 > /dev/null


real    0m0.645s
user    0m0.601s
sys    0m0.042s

Hope this is helpful.  Looking forward to your work.  We've had 
discussions over the many years of our project about sharing 
bookmarking and similar data between apps, but we all had different 
ideas of what we'd like.  BibleCS (our Windows classic app) 
concentrates on allowing verse groups and trees of groups so users can 
create trees of topic.  Other apps extend this to allow comments and 
notes at each reference, including a specific module name with the 
reference.  We've all had different data formats for our bookmarking 
materials.  Since your app centers on tagging (which I would place in 
the same category as bookmarking), I would love to hear what you come 
up with and if it encompasses everything which all of our frontends 
desire to provide their users.  Maybe we can make another go at a 
shared "bookmarking" or "tagging" concept and push that concept back 
into the engine so all app can share and take advantage of your 
functionality, if you'd be willing.


Troy


On 5/7/20 9:07 AM, Tobias Klein wrote:

Thanks Troy!

Besides comparing verses in different translations my primary use 
case is the following:
Establish „unique verse reference“ objects that I can use to assign 
tags independent of the specific translation.


Currently I’m doing this by determining the „absolute verse number“ 
for the respective verse I’m tagging.
Then at the point when the „verse reference object“ (a database 
entry) is created, the absolute verse number both for English and 
Hebrew versification are determined based on my mapping tables.


Then, when looking up tags for the currently selected verses I can 
map the correct „verse reference object“ to each verse in the 
currently selected translation (based on the respective absolute 
verse number).


If I migrate to the Sword VerseKey approach I would change my concept 
in the following way:


1) Use KJV verse references (chapter + verse) as unique identifiers 
for all „abstract verse reference“