Re: [sword-devel] Bishop for Android and iOS / JavaScript bindings

[Troy A. Griffitts]

Dear Michael,

Thanks for the feedback and encouragement.

On 03/22/2018 05:54 AM, Michael Johnson wrote:
> For what its worth, I tested on 4 platforms:
>
>   * Acer tablet with Android 4.4.2
>   * Motorola phone with Android 7.1.1
>   * Apple iPad Pro with iOS 11.2.6
>   * Apple iPhone 7 plus with iOS 11.2.6
I am happy to hear the app works well on the range of devices you've
reported.

Regarding anything left before promoting general usage...

I still think one flaw to fix before promoting the app for general use
is the warning when a module necessary for a function isn't installed.

It's a pretty simple change.  When someone selects "Verse Study" / "Word
Study" and no Strongs lexicon is installed or no Bible module with
Strongs is installed, then a popup suggesting to add the KJV +
StrongsGreek + StrongsHebrew can be shown.

Along with this though, I'd like to let the user choose which Greek and
which Hebrew lexicon they would like to use.  I know the Xiphos repo has
something like StrongsRealGreek and StrongsRealHebrew and we also
reference the Liddell-Scott from SWORDWeb, which could be a choice for
online users... Probably others.  And with those selection options under
Settings, maybe we could add a Word Study Bible choice which let's a
user pick, say the KJV as their Strongs Bible for word studies, but
maybe they like to normally read a different Bible as their primary text.

Anway, the warning is a small change and I think will go a long way to
avoid support questions on "Why doesn't the Word Study tool work?!" and
adding the new Settings options kindof go along with that so I'd like to
get it all done in one release.

> Observations:
>
>   * Search works consistently with eBible.org modules (unlike PocketSword).
Regarding search, I had an Apple user say that search wasn't working for
him.  I haven't had a chance to look into it.  Have you been able to
search on Apple?

Bishop doesn't use CLucene, but instead just uses the internal search
features of the SWORD engine.  Most phones are fast enough to search the
entire text a Bible in an acceptable time without an indexed search. 
Strongs searches take a little longer and you can see by looking at a
Word Study and then clicking any word entry in the Word Study list for
the verse.  You should be offered the ability to search other
occurrences of that exactly Greek word and without an index, it takes a
little time to parse out the lemma information while searching the
entire text.  It's still not too bad, I think.

>   * Poetry 2nd lines are not indented, but it would be nice if they were.
Curious.  I'll try to spend time to look.  Does the same module look OK
in any other SWORD frontend?

>   * The app icon for Android is much nicer than the app icon for iOS. (The 
> latter looks more like a Minecraft monster head.)
:) I was so happy to finally build a working binary for iOS that I
haven't even though about how to choose the icon. :)  That's the default
Cordova icon.

>   * I like the way columns without a current chapter to display disappear, 
> making a nice seamless way to display the Hebrew OT and Greek NT next to 
> another Bible translation.
Yes, that's exactly how I use it for my morning readings.  I try to make
myself read Greek, but I'm not good enough for that to not be a
distraction from my devotions so having the English side by side with
the original language (Old or New Testament) was my primary goal for
reading mode-- for me personally.  My Hebrew is so worthless these days
that I've though about putting an LXX module as the 3rd selected Bible
so I always get an English / Greek diglot when reading. :)  I think this
should be nice for seminary students.

>   * Support for display of Strong's numbers and visible linkage of parallel 
> translations and/or lexicons where the word stem matches would be nice.
Yeah, that was hard to do word selects on the small screen, like we do
on SWORDWeb.  On SWORDWeb we show 3 levels of association: bold = all
words from the same stem, bold/italic = all words with the same stem and
exact morphology, bold/italic/underline = the exact same word between
two Bibles.  I am surprised how often, when I click a word, I see that
same word nearby in the chapter, but translated by a different English
word that I had no idea the author used the same word.  It has been
enlightening to discover running themes which had been previously masked
to me by translation.

Anyway, Word Study was my mobile attempt to show Strongs information,
but we do lose this 'other occurrences nearby' feature.  For Word Study
to work, you'll need a Strongs Bible as your primary (KJV is best right
now. ESV2011 kindof works but I'm curious about the markup there as
results sometimes seem odd) and you'll need to be sure to have
StrongsGreek and StrongsHebrew modules also installed.

The app is pure JavaScript.  I'd love for you to hack up a prototype of
anything you envision.  I know you have dev skills ;)

Troy


>
>
> On 03/22/2018 01:32 

Re: [sword-devel] Normalize the search string (comparing front-end apps)

[DM Smith]

Re case sensitivity, it was just a very simple example of the principle.

If it doesn’t find all then the search request and the index were not 
normalized the same. NFC and NFD are different normalizations.

Note, stripping diacritics may be an appropriate normalization.

JSword doesn’t properly handle Unicode either. 

— DM Smith
From my phone. Brief. Weird autocorrections. 

> On Mar 22, 2018, at 9:30 AM, David Haslam  wrote:
> 
> Thanks, DM.
> 
> My question was not about case-sensitivity, but about Unicode normalization.
> The main issue is composition vs decomposition and the canonical ordering of 
> diacritics in each glyph.
> 
> e.g. Suppose the module contains 181 instances of the name "Efraím" which has 
> 6 characters.
> Suppose a user enters in the search box instead "E f r a i ́ m" - (NB, remove 
> the spaces!)
> That's 7 characters when normalized to NFD, the acute accent now being a 
> separate character (U+0301 COMBINING ACUTE ACCENT).
> 
> In each front-end, will the search function find all the 181 instances (as 
> Eloquent does) ?
> Or (as with Xiphos) will it find none?
> 
> DM, what does BibleDesktop do here?
> 
> Best regards,
> 
> David
> 
> PS. ProtonMail converts automatically to NFC even though the text was keyed 
> in as NFD, hence the above kludge with spaces.
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
>> On 22 March 2018 1:14 PM, DM Smith  wrote:
>> 
>> It doesn’t matter that a search doesn’t use Lucene. The principle is the 
>> same. The search request has to be normalized to the same form as the 
>> searched text. For example a case insensitive search normalizes both to a 
>> single case. If it isn’t done, even on the fly, then search will fail at 
>> times. As they say, “even a blind squirrel gets a nut sometimes."
>> 
>> Regarding Lucene there are mulitple different analyzers (that’s what does 
>> the normalization in Lucene). Each normalizes differently. Each has it’s own 
>> documentation. The analyzer that SWORD uses is suited and was developed for 
>> English texts. It is not appropriate for non-Latin texts. There is a 
>> multi-language analyzer that is much better, ICUAnalyzer, which follows UAX 
>> #29 for tokenization. For details see: 
>> https://issues.apache.org/jira/browse/LUCENE-1488 You’ll note that I 
>> participate in its development.
>> 
>> The osis2mod proclivity for NFC is for display.
>> 
>> DM
>> 
>>> On Mar 22, 2018, at 8:19 AM, David Haslam  wrote:
>>> 
>>> Thanks DM,
>>> 
>>> Not all searches make use of the Lucene index !
>>> 
>>> e.g. In Xiphos, the advanced search panel gives the user a choice of which 
>>> type of search.
>>> Lucene is only one of these mutually exclusive options.
>>> 
>>> btw. Where is it documented that the creation of a Lucene search index 
>>> normalizes the Unicode for the index?
>>> Do we know for certain that this would occur irrespective of whether 
>>> normalization was suppressed during module build?
>>> i.e. With osis2mod option   -N do not convert UTF-8 or normalize UTF-8 to 
>>> NFC
>>> 
>>> 
>>> Best regards,
>>> 
>>> David
>>> 
>>> Sent with ProtonMail Secure Email.
>>> 
>>> ‐‐‐ Original Message ‐‐‐
 On 22 March 2018 10:20 AM, DM Smith  wrote:
 
 The requirement is not that the search is normalized to nfc but rather 
 that it is normalized the same as the index. This should not be a front 
 end issue.
 
 Btw it doesn’t matter how Hebrew is stored in the module. Indexing should 
 normalize it to a form that is internal to the engine. 
 
 — DM Smith
 From my phone. Brief. Weird autocorrections. 
 
> On Mar 22, 2018, at 5:22 AM, David Haslam  wrote:
> Dear all,
> 
> Not all front-ends automatically normalize the search string to Unicode 
> NFC.
> e.g.
> Eloquent does
> Xiphos does not
> The data is incomplete for this feature in the table in our wiki page.
> https://wiki.crosswire.org/Choosing_a_SWORD_program#Search_and_Dictionary
> 
> Please would other front-end app developers supply the missing 
> information. Thanks.
> 
> Further thought:
> For front-ends that also have an Advanced search feature, would it not be 
> a useful enhancement to have a tick box option for Search string 
> normalization?
> Then if we do make any Biblical Hebrew modules with custom normalization, 
> search could at least still work for the "corner cases" in Hebrew, 
> providing the user gave the proper input in the search box.
> 
> cf. The source text for the WLC at tanach.us is not normalized to NFC, 
> but our module is.
> I'll refrain from going into a lot more detail here. There's an issue in 
> our tracker that covers this.
> 
> Best regards,
> 
> David
> 
> Sent with ProtonMail Secure Email.
> 
> 

[sword-devel] WebAssembly ?

[David Haslam]

Has anyone any ideas whether SWORD might make good use of WebAssembly ?

e.g. In The Bible Tool (aka swordweb)...

Best regards,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
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] Diatheke ?

[David Haslam]

No - that makes no difference, neither did using osis2mod version $3431



Salmo de David, cuando huía de 
delante de Absalom su hijo.
Jehová, ¡cuánto se han multiplicado 
mis enemigos! muchos se levantan contra mí.
Muchos dicen de mi alma: No hay 
para él salud en Dios. Selah.

However, examining the mod2imp output, it becomes evident that there really is 
a space between the title element and the div eID element.
https://www.dropbox.com/s/ezauqjw68dv36fi/Screenshot%202018-03-22%2014.29.07.png?dl=0

Is this perhaps a quirk of how osis2mod was enhanced a few years ago to handle 
all preverse content as a milestoned div element?

Best regards,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.  This always seems 
to "top-post" when I hit reply.

‐‐‐ Original Message ‐‐‐
On 22 March 2018 1:57 PM, Greg Hellings  wrote:

> On Thu, Mar 22, 2018 at 8:51 AM, David Haslam  wrote:
>
>> Greg,
>>
>> Thanks for the comparison between KJV and SpaRV1909.
>>
>> It seems therefore that I assumed incorrectly that the "extra space" problem 
>> was more general, and that any module with Psalm titles could be used 
>> illustrate it.
>>
>> FYI. Test module SpaRV1865 only exists so far in the text development 
>> collaboration between myself and Vince LaRue.
>> btw. We're now in our third week of activity and have made very good 
>> progress.
>>
>> I suppose it might even depend on which version of osis2mod was used to 
>> build the module?
>> i.e. If there's nothing obvious in the OSIS source text that would result in 
>> the space.
>> FIO. Here's Psalm 3 in the OSIS file - there are no trailing spaces at all.
>>
>> 
>> 
>> 
>> Salmo de David, cuando huía 
>> de delante de Absalom su hijo.
>> Jehová, ¡cuánto se han 
>> multiplicado mis enemigos! muchos se levantan contra mí.
>> 
>
> I wonder if this newline before the eID verse element plus the empty element 
> itself is being converted into a newline and space character by the 
> OSIS->Plain filter? It would be worth comparing that ending to verse endings 
> in e.g. the KJV to see if they are similar. And also possibly worthwhile to 
> compare the results of osis2mod for your SpaRV1865 to what the compiled KJV 
> module is to see if that newline is preserved.
>
> --Greg
>
>> Muchos dicen de mi alma: No hay 
>> para él salud en Dios. Selah.
>> 
>> ...
>> 
>>
>> Nothing shouts "extra space" does it?
>>
>> I will therefore try the more recent version of osis2mod next time I rebuild 
>> the module.
>>
>> Maybe Peter can shed light on how diatheke works here?
>> - given that it was he who added the LaTeX format option - a major 
>> contribution which we owe him thanks for.
>> - to do that, he must have got deeply involved in the code.
>> Best regards,
>>
>> David
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On 22 March 2018 1:20 PM, Greg Hellings  wrote:
>>
>>> On Thu, Mar 22, 2018 at 4:01 AM, David Haslam  wrote:
>>>
 Hi Greg,

 With Plain output format, there's a minor side effect in the way the Psalm 
 title was output in the wrong place.
 Verse 2 of the same Psalm was output with a leading space before the 
 Reference.

 https://www.dropbox.com/s/uz1amnrp7ez0b4y/Screenshot%202018-03-22%2008.37.42.png?dl=0

 This might be less obvious in a terminal, but it's quite evident when the 
 output is piped to a file.

 Please ensure that the patch also removes this spurious space, if perhaps 
 it ddidn't do so already.
>>>
>>> As someone who isn't the maintainer of either Diatheke or the filters, I'm 
>>> not about to dig through the source to find one errant space in the output. 
>>> Doubly so in that I do not have nor can I easily locate the SpaRV1865 
>>> module that you have screenshot there. I don't see the same artifact in KJV 
>>> so I am going to conclude, for now, that this is either a bug that was 
>>> already fixed between the older version of Diatheke that you are using and 
>>> now or that it is an artifact of the module itself. Compare the KJV and the 
>>> Spa1909 that's on CrossWire's server:
>>>
>>> $ diatheke -b KJV -o h -f Plain -k Ps.3
>>> Psalms 3:1: LORD, how are they increased that trouble me! many are they 
>>> that rise up against me.
>>> A Psalm of David, when he fled from Absalom his son.
>>> Psalms 3:2: Many there be which say of my soul, There is no help for him in 
>>> God. Selah.
>>>
>>> $ diatheke -b SpaRV1909 -o h -f Plain -k Ps.3
>>> Psalms 3:1:
>>> Salmo de David, cuando huía de delante de Absalom su hijo.
>>>  ¡OH Jehová, cuánto se han multiplicado mis enemigos! muchos se levantan 
>>> contra mí.
>>> Psalms 3:2: Muchos dicen de mi vida: No hay para él salud en Dios. (Selah.)
>>>
>>> The SpaRV1909 module definitely has spurious spaces around many different 
>>> places. I suspect that your SpaRV1865 module is in a 

Re: [sword-devel] Diatheke ?

[Greg Hellings]

On Thu, Mar 22, 2018 at 8:51 AM, David Haslam  wrote:

> Greg,
>
> Thanks for the comparison between *KJV* and *SpaRV1909*.
>
> It seems therefore that I assumed *incorrectly* that the "extra space"
> problem was more general, and that *any* module with Psalm titles could
> be used illustrate it.
>
> FYI. Test module *SpaRV1865* only exists so far in the *text development*
> collaboration between myself and Vince LaRue.
> btw. *We're now in our third week of activity and have made very good
> progress.*
>
> I suppose it might even depend on which version of *osis2mod* was used to
> build the module?
> i.e. If there's nothing obvious in the OSIS source text that would result
> in the space.
> FIO. Here's *Psalm 3* in the OSIS file - there are no trailing spaces at
> all.
>
> 
> 
> 
> Salmo de David, cuando huía
> de delante de Absalom su hijo.
> Jehová, ¡cuánto se han
> multiplicado mis enemigos! muchos se levantan contra mí.
> 
>

I wonder if this newline before the eID verse element plus the empty
element itself is being converted into a newline and space character by the
OSIS->Plain filter? It would be worth comparing that ending to verse
endings in e.g. the KJV to see if they are similar. And also possibly
worthwhile to compare the results of osis2mod for your SpaRV1865 to what
the compiled KJV module is to see if that newline is preserved.

--Greg


> Muchos dicen de mi alma: No
> hay para él salud en Dios. Selah.
> 
> ...
> 
>
> Nothing shouts "extra space" does it?
>
> I will therefore try the more recent version of *osis2mod* next time I
> rebuild the module.
>
> Maybe Peter can shed light on how diatheke works here?
> - given that it was he who added the LaTeX format option - a major
> contribution which we owe him thanks for.
> - to do that, he must have got deeply involved in the code.
>
> Best regards,
>
> David
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On 22 March 2018 1:20 PM, Greg Hellings  wrote:
>
>
>
> On Thu, Mar 22, 2018 at 4:01 AM, David Haslam 
> wrote:
>
>> Hi Greg,
>>
>> With *Plain* output format, there's a minor side effect in the way the
>> Psalm title was output in the wrong place.
>> Verse 2 of the same Psalm was output with a *leading space* before the
>> Reference.
>>
>> https://www.dropbox.com/s/uz1amnrp7ez0b4y/Screenshot%202018-
>> 03-22%2008.37.42.png?dl=0
>>
>> This might be less obvious in a terminal, but it's quite evident when the
>> output is piped to a file.
>>
>> Please ensure that the patch also *removes* this spurious space, if
>> perhaps it ddidn't do so already.
>>
>
> As someone who isn't the maintainer of either Diatheke or the filters, I'm
> not about to dig through the source to find one errant space in the output.
> Doubly so in that I do not have nor can I easily locate the SpaRV1865
> module that you have screenshot there. I don't see the same artifact in KJV
> so I am going to conclude, for now, that this is either a bug that was
> already fixed between the older version of Diatheke that you are using and
> now or that it is an artifact of the module itself. Compare the KJV and the
> Spa1909 that's on CrossWire's server:
>
> $ diatheke -b KJV -o h -f Plain -k Ps.3
> Psalms 3:1: LORD, how are they increased that trouble me! many are they
> that rise up against me.
> A Psalm of David, when he fled from Absalom his son.
> Psalms 3:2: Many there be which say of my soul, There is no help for him
> in God. Selah.
>
> $ diatheke -b SpaRV1909 -o h -f Plain -k Ps.3
> Psalms 3:1:
> Salmo de David, cuando huía de delante de Absalom su hijo.
>  ¡OH Jehová, cuánto se han multiplicado mis enemigos! muchos se levantan
> contra mí.
> Psalms 3:2: Muchos dicen de mi vida: No hay para él salud en Dios. (Selah.)
>
> The SpaRV1909 module definitely has spurious spaces around many different
> places. I suspect that your SpaRV1865 module is in a similar place.
>
> --Greg
>
>
>>
>> While I'm on a roll, I noticed also that there's a subtle change in how
>> diatheke treats the start and end of a *hi* element.
>> There's now a *space* after the leading asterisk and *another space*
>> before the trailing asterisk.
>> https://www.dropbox.com/s/2h2u1768rgx9p95/Screenshot%202018-
>> 03-22%2008.38.21.png?dl=0
>>
>> If this change was unintended, it ought to be reverted for consistency
>> with earlier versions.
>>
>
> Sounds like a filter thing.
>
> --Greg
>
>
>>
>>
>> Best regards,
>>
>> David
>>
>> Sent with ProtonMail  Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On 21 March 2018 3:33 AM, Greg Hellings  wrote:
>>
>>
>>
>> On Tue, Mar 20, 2018 at 10:21 PM, Troy A. Griffitts > > wrote:
>>
>>> If I had to guess, I suspect diatheke is not calling renderText before
>>> asking for the header. The renderText method triggers all entryAttributes
>>> to be filled. The header is an 

Re: [sword-devel] Diatheke ?

[David Haslam]

Greg,

Thanks for the comparison between KJV and SpaRV1909.

It seems therefore that I assumed incorrectly that the "extra space" problem 
was more general, and that any module with Psalm titles could be used 
illustrate it.

FYI. Test module SpaRV1865 only exists so far in the text development 
collaboration between myself and Vince LaRue.
btw. We're now in our third week of activity and have made very good progress.

I suppose it might even depend on which version of osis2mod was used to build 
the module?
i.e. If there's nothing obvious in the OSIS source text that would result in 
the space.
FIO. Here's Psalm 3 in the OSIS file - there are no trailing spaces at all.




Salmo de David, cuando huía de 
delante de Absalom su hijo.
Jehová, ¡cuánto se han multiplicado 
mis enemigos! muchos se levantan contra mí.

Muchos dicen de mi alma: No hay 
para él salud en Dios. Selah.

...


Nothing shouts "extra space" does it?

I will therefore try the more recent version of osis2mod next time I rebuild 
the module.

Maybe Peter can shed light on how diatheke works here?
- given that it was he who added the LaTeX format option - a major contribution 
which we owe him thanks for.
- to do that, he must have got deeply involved in the code.

Best regards,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On 22 March 2018 1:20 PM, Greg Hellings  wrote:

> On Thu, Mar 22, 2018 at 4:01 AM, David Haslam  wrote:
>
>> Hi Greg,
>>
>> With Plain output format, there's a minor side effect in the way the Psalm 
>> title was output in the wrong place.
>> Verse 2 of the same Psalm was output with a leading space before the 
>> Reference.
>>
>> https://www.dropbox.com/s/uz1amnrp7ez0b4y/Screenshot%202018-03-22%2008.37.42.png?dl=0
>>
>> This might be less obvious in a terminal, but it's quite evident when the 
>> output is piped to a file.
>>
>> Please ensure that the patch also removes this spurious space, if perhaps it 
>> ddidn't do so already.
>
> As someone who isn't the maintainer of either Diatheke or the filters, I'm 
> not about to dig through the source to find one errant space in the output. 
> Doubly so in that I do not have nor can I easily locate the SpaRV1865 module 
> that you have screenshot there. I don't see the same artifact in KJV so I am 
> going to conclude, for now, that this is either a bug that was already fixed 
> between the older version of Diatheke that you are using and now or that it 
> is an artifact of the module itself. Compare the KJV and the Spa1909 that's 
> on CrossWire's server:
>
> $ diatheke -b KJV -o h -f Plain -k Ps.3
> Psalms 3:1: LORD, how are they increased that trouble me! many are they that 
> rise up against me.
> A Psalm of David, when he fled from Absalom his son.
> Psalms 3:2: Many there be which say of my soul, There is no help for him in 
> God. Selah.
>
> $ diatheke -b SpaRV1909 -o h -f Plain -k Ps.3
> Psalms 3:1:
> Salmo de David, cuando huía de delante de Absalom su hijo.
>  ¡OH Jehová, cuánto se han multiplicado mis enemigos! muchos se levantan 
> contra mí.
> Psalms 3:2: Muchos dicen de mi vida: No hay para él salud en Dios. (Selah.)
>
> The SpaRV1909 module definitely has spurious spaces around many different 
> places. I suspect that your SpaRV1865 module is in a similar place.
>
> --Greg
>
>> While I'm on a roll, I noticed also that there's a subtle change in how 
>> diatheke treats the start and end of a hi element.
>> There's now a space after the leading asterisk and another space before the 
>> trailing asterisk.
>> https://www.dropbox.com/s/2h2u1768rgx9p95/Screenshot%202018-03-22%2008.38.21.png?dl=0
>>
>> If this change was unintended, it ought to be reverted for consistency with 
>> earlier versions.
>
> Sounds like a filter thing.
>
> --Greg
>
>> Best regards,
>>
>> David
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On 21 March 2018 3:33 AM, Greg Hellings  wrote:
>>
>>> On Tue, Mar 20, 2018 at 10:21 PM, Troy A. Griffitts  
>>> wrote:
>>>
 If I had to guess, I suspect diatheke is not calling renderText before 
 asking for the header. The renderText method triggers all entryAttributes 
 to be filled. The header is an entryAttribute.
>>>
>>> Spot on. If I were offering commentary, I would call that a bug in the UX 
>>> of the API. But I do get why it is that way. Attaching a patch that solves 
>>> the problem.
>>>
>>> --Greg
>>>
 On March 20, 2018 8:13:41 PM MST, Greg Hellings  
 wrote:

> To be quite specific: diatheke does not encounter that header in the 
> preverse content until it reaches Psalm 3:2 for some reason that is 
> beyond my ken. Therefore, it is properly rendering that content as 
> preverse, but it has attached it to the wrong verse. Output from my 
> slightly modified 

Re: [sword-devel] Normalize the search string (comparing front-end apps)

[David Haslam]

Thanks, DM.

My question was not about case-sensitivity, but about Unicode normalization.
The main issue is composition vs decomposition and the canonical ordering of 
diacritics in each glyph.

e.g. Suppose the module contains 181 instances of the name "Efraím" which has 6 
characters.
Suppose a user enters in the search box instead "E f r a i ́ m" - (NB, remove 
the spaces!)
That's 7 characters when normalized to NFD, the acute accent now being a 
separate character (U+0301 COMBINING ACUTE ACCENT).

In each front-end, will the search function find all the 181 instances (as 
Eloquent does) ?
Or (as with Xiphos) will it find none?

DM, what does BibleDesktop do here?

Best regards,

David

PS. ProtonMail converts automatically to NFC even though the text was keyed in 
as NFD, hence the above kludge with spaces.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On 22 March 2018 1:14 PM, DM Smith  wrote:

> It doesn’t matter that a search doesn’t use Lucene. The principle is the 
> same. The search request has to be normalized to the same form as the 
> searched text. For example a case insensitive search normalizes both to a 
> single case. If it isn’t done, even on the fly, then search will fail at 
> times. As they say, “even a blind squirrel gets a nut sometimes."
>
> Regarding Lucene there are mulitple different analyzers (that’s what does the 
> normalization in Lucene). Each normalizes differently. Each has it’s own 
> documentation. The analyzer that SWORD uses is suited and was developed for 
> English texts. It is not appropriate for non-Latin texts. There is a 
> multi-language analyzer that is much better, ICUAnalyzer, which follows UAX 
> #29 for tokenization. For details see: 
> https://issues.apache.org/jira/browse/LUCENE-1488 You’ll note that I 
> participate in its development.
>
> The osis2mod proclivity for NFC is for display.
>
> DM
>
>> On Mar 22, 2018, at 8:19 AM, David Haslam  wrote:
>>
>> Thanks DM,
>>
>> Not all searches make use of the Lucene index !
>>
>> e.g. In Xiphos, the advanced search panel gives the user a choice of which 
>> type of search.
>> Lucene is only one of these mutually exclusive options.
>>
>> btw. Where is it documented that the creation of a Lucene search index 
>> normalizes the Unicode for the index?
>> Do we know for certain that this would occur irrespective of whether 
>> normalization was suppressed during module build?
>> i.e. With osis2mod option   -N do not convert UTF-8 or normalize UTF-8 to NFC
>>
>> Best regards,
>>
>> David
>>
>> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On 22 March 2018 10:20 AM, DM Smith  wrote:
>>
>>> The requirement is not that the search is normalized to nfc but rather that 
>>> it is normalized the same as the index. This should not be a front end 
>>> issue.
>>>
>>> Btw it doesn’t matter how Hebrew is stored in the module. Indexing should 
>>> normalize it to a form that is internal to the engine.
>>>
>>> — DM Smith
>>> From my phone. Brief. Weird autocorrections.
>>>
>>> On Mar 22, 2018, at 5:22 AM, David Haslam  wrote:
>>>
 Dear all,

 Not all front-ends automatically normalize the search string to Unicode 
 NFC.
 e.g.

 - Eloquent does
 - Xiphos does not

 The data is incomplete for this feature in the table in our wiki page.
 https://wiki.crosswire.org/Choosing_a_SWORD_program#Search_and_Dictionary

 Please would other front-end app developers supply the missing 
 information. Thanks.

 Further thought:
 For front-ends that also have an Advanced search feature, would it not be 
 a useful enhancement to have a tick box option for Search string 
 normalization?
 Then if we do make any Biblical Hebrew modules with custom normalization, 
 search could at least still work for the "corner cases" in Hebrew, 
 providing the user gave the proper input in the search box.

 cf. The source text for the WLC at [tanach.us](http://tanach.us/) is not 
 normalized to NFC, but our module is.
 I'll refrain from going into a lot more detail here. There's an issue in 
 our tracker that covers this.

 Best regards,

 David

 Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>>>
 ___
 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] Diatheke ?

[Greg Hellings]

On Thu, Mar 22, 2018 at 4:01 AM, David Haslam  wrote:

> Hi Greg,
>
> With *Plain* output format, there's a minor side effect in the way the
> Psalm title was output in the wrong place.
> Verse 2 of the same Psalm was output with a *leading space* before the
> Reference.
>
> https://www.dropbox.com/s/uz1amnrp7ez0b4y/Screenshot%
> 202018-03-22%2008.37.42.png?dl=0
>
> This might be less obvious in a terminal, but it's quite evident when the
> output is piped to a file.
>
> Please ensure that the patch also *removes* this spurious space, if
> perhaps it ddidn't do so already.
>

As someone who isn't the maintainer of either Diatheke or the filters, I'm
not about to dig through the source to find one errant space in the output.
Doubly so in that I do not have nor can I easily locate the SpaRV1865
module that you have screenshot there. I don't see the same artifact in KJV
so I am going to conclude, for now, that this is either a bug that was
already fixed between the older version of Diatheke that you are using and
now or that it is an artifact of the module itself. Compare the KJV and the
Spa1909 that's on CrossWire's server:

$ diatheke -b KJV -o h -f Plain -k Ps.3
Psalms 3:1: LORD, how are they increased that trouble me! many are they
that rise up against me.
A Psalm of David, when he fled from Absalom his son.
Psalms 3:2: Many there be which say of my soul, There is no help for him in
God. Selah.

$ diatheke -b SpaRV1909 -o h -f Plain -k Ps.3
Psalms 3:1:
Salmo de David, cuando huía de delante de Absalom su hijo.
 ¡OH Jehová, cuánto se han multiplicado mis enemigos! muchos se levantan
contra mí.
Psalms 3:2: Muchos dicen de mi vida: No hay para él salud en Dios. (Selah.)

The SpaRV1909 module definitely has spurious spaces around many different
places. I suspect that your SpaRV1865 module is in a similar place.

--Greg


> While I'm on a roll, I noticed also that there's a subtle change in how
> diatheke treats the start and end of a *hi* element.
> There's now a *space* after the leading asterisk and *another space*
> before the trailing asterisk.
> https://www.dropbox.com/s/2h2u1768rgx9p95/Screenshot%
> 202018-03-22%2008.38.21.png?dl=0
>
> If this change was unintended, it ought to be reverted for consistency
> with earlier versions.
>

Sounds like a filter thing.

--Greg


>
> Best regards,
>
> David
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On 21 March 2018 3:33 AM, Greg Hellings  wrote:
>
>
>
> On Tue, Mar 20, 2018 at 10:21 PM, Troy A. Griffitts 
> wrote:
>
>> If I had to guess, I suspect diatheke is not calling renderText before
>> asking for the header. The renderText method triggers all entryAttributes
>> to be filled. The header is an entryAttribute.
>>
>
> Spot on. If I were offering commentary, I would call that a bug in the UX
> of the API. But I do get why it is that way. Attaching a patch that solves
> the problem.
>
> --Greg
>
>
>>
>>
>> On March 20, 2018 8:13:41 PM MST, Greg Hellings 
>> wrote:
>>
>>> To be quite specific: diatheke does not encounter that header in the
>>> preverse content until it reaches Psalm 3:2 for some reason that is beyond
>>> my ken. Therefore, it is properly rendering that content as preverse, but
>>> it has attached it to the wrong verse. Output from my slightly modified
>>> diatheke confirms this:
>>>
>>> $ ./inst/bin/diatheke -b KJV -o h -f Plain -k Ps 3
>>> key: Psalms 3:1
>>> header:
>>> Psalms 3:1: LORD, how are they increased that trouble me! many are they
>>> that rise up against me.
>>> key: Psalms 3:2
>>> header: >> savlm="strong:H04210">A Psalm of David, >> savlm="strong:H01272">when he fled from >> savlm="strong:H053">Absalom his
>>> son.
>>> A Psalm of David, when he fled from Absalom his son.
>>> Psalms 3:2: Many there be which say of my soul, There is no help for him
>>> in God. Selah.
>>>
>>> --Greg
>>>
>>> On Tue, Mar 20, 2018 at 9:53 PM, Greg Hellings 
>>> wrote:
>>>
 It's easier to see the problem when using plain formatting:

 $ diatheke -b KJV -o h -f Plain -k Ps 3
 Psalms 3:1: LORD, how are they increased that trouble me! many are they
 that rise up against me.
 A Psalm of David, when he fled from Absalom his son.
 Psalms 3:2: Many there be which say of my soul, There is no help for
 him in God. Selah.
 Psalms 3:3: But thou, O LORD, art a shield for me; my glory, and the
 lifter up of mine head.
 Psalms 3:4:
 I cried unto the LORD with my voice, and he heard me out of his holy
 hill. Selah.
 Psalms 3:5: I laid me down and slept; I awaked; for the LORD sustained
 me.
 Psalms 3:6: I will not be afraid of ten thousands of people, that have
 set themselves against me round about.
 Psalms 3:7: Arise, O LORD; save me, O my God: for thou hast smitten all
 mine enemies upon the cheek bone; thou hast 

Re: [sword-devel] Normalize the search string (comparing front-end apps)

[DM Smith]

It doesn’t matter that a search doesn’t use Lucene. The principle is the same. 
The search request has to be normalized to the same form as the searched text. 
For example a case insensitive search normalizes both to a single case. If it 
isn’t done, even on the fly, then search will fail at times. As they say, “even 
a blind squirrel gets a nut sometimes."

Regarding Lucene there are mulitple different analyzers (that’s what does the 
normalization in Lucene). Each normalizes differently. Each has it’s own 
documentation. The analyzer that SWORD uses is suited and was developed for 
English texts. It is not appropriate for non-Latin texts. There is a 
multi-language analyzer that is much better, ICUAnalyzer, which follows UAX #29 
for tokenization. For details see: 
https://issues.apache.org/jira/browse/LUCENE-1488 
 You’ll note that I 
participate in its development.

The osis2mod proclivity for NFC is for display.

DM

> On Mar 22, 2018, at 8:19 AM, David Haslam  wrote:
> 
> Thanks DM,
> 
> Not all searches make use of the Lucene index !
> 
> e.g. In Xiphos, the advanced search panel gives the user a choice of which 
> type of search.
> Lucene is only one of these mutually exclusive options.
> 
> btw. Where is it documented that the creation of a Lucene search index 
> normalizes the Unicode for the index?
> Do we know for certain that this would occur irrespective of whether 
> normalization was suppressed during module build?
> i.e. With osis2mod option   -Ndo not convert UTF-8 or normalize UTF-8 
> to NFC
> 
> 
> Best regards,
> 
> David
> 
> Sent with ProtonMail  Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On 22 March 2018 10:20 AM, DM Smith  wrote:
> 
>> The requirement is not that the search is normalized to nfc but rather that 
>> it is normalized the same as the index. This should not be a front end issue.
>> 
>> Btw it doesn’t matter how Hebrew is stored in the module. Indexing should 
>> normalize it to a form that is internal to the engine. 
>> 
>> — DM Smith
>> From my phone. Brief. Weird autocorrections. 
>> 
>> On Mar 22, 2018, at 5:22 AM, David Haslam > > wrote:
>>> Dear all,
>>> 
>>> Not all front-ends automatically normalize the search string to Unicode NFC.
>>> e.g.
>>> Eloquent does
>>> Xiphos does not
>>> The data is incomplete for this feature in the table in our wiki page.
>>> https://wiki.crosswire.org/Choosing_a_SWORD_program#Search_and_Dictionary 
>>> 
>>> 
>>> Please would other front-end app developers supply the missing information. 
>>> Thanks.
>>> 
>>> Further thought:
>>> For front-ends that also have an Advanced search feature, would it not be a 
>>> useful enhancement to have a tick box option for Search string 
>>> normalization?
>>> Then if we do make any Biblical Hebrew modules with custom normalization, 
>>> search could at least still work for the "corner cases" in Hebrew, 
>>> providing the user gave the proper input in the search box.
>>> 
>>> cf. The source text for the WLC at tanach.us  is not 
>>> normalized to NFC, but our module is.
>>> I'll refrain from going into a lot more detail here. There's an issue in 
>>> our tracker that covers this.
>>> 
>>> Best regards,
>>> 
>>> David
>>> 
>>> Sent with ProtonMail  Secure Email.
>>> 
>>> ___
>>> 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] Bishop for Android and iOS / JavaScript bindings

[Michael Johnson]

For what its worth, I tested on 4 platforms:

  * Acer tablet with Android 4.4.2
  * Motorola phone with Android 7.1.1
  * Apple iPad Pro with iOS 11.2.6
  * Apple iPhone 7 plus with iOS 11.2.6

Observations:

  * Search works consistently with eBible.org modules (unlike PocketSword).
  * Poetry 2nd lines are not indented, but it would be nice if they were.
  * The app icon for Android is much nicer than the app icon for iOS. (The 
latter looks more like a Minecraft monster head.)
  * I like the way columns without a current chapter to display disappear, 
making a nice seamless way to display the Hebrew OT and Greek NT next to 
another Bible translation.
  * Support for display of Strong's numbers and visible linkage of parallel 
translations and/or lexicons where the word stem matches would be nice.


On 03/22/2018 01:32 PM, Michael Johnson wrote:
> Hello, Troy & all!
>
> After a bit of testing, I have concluded that the Bishop app is awesome. :-)
> Its current version works well on both iOS and Android.
> I like its Scripture display layout. OK, there is some room for improvement 
> in poetry display, making secondary and tertiary lines indented a little more 
> like the NIV and World English Bible official printed editions do, but other 
> than that, most things I think of now fall firmly in the camp of feature 
> addition instead of bug fixes; like maybe more complete localization to other 
> user interface languages.
>
> The biggest flaw is not yet being in the Apple App Store for general use on 
> iOS devices. Sure sending Troy a UDID and side loading a special compilation 
> works for me for now, but it would get really tedious for Troy after more 
> than just a few testers... and there are limits to how many testers you can 
> have. I think it is at least as good as many iOS apps that are in Apple's App 
> Store. I have an active Apple developer account, so I could submit it if you 
> like, after I get back from the conference I am
> enroute to, now.
>  
>
> On 03/01/2018 10:26 AM, Troy A. Griffitts wrote:
>> Dear team,
>>
>> You all know we've been working on Cordova bindings for SWORD for quite some 
>> time now.  We now have a simple reader written in JavaScript which will run 
>> unchanged on both Android and iOS.Bishop includes an InstallMgr to 
>> auto-discover remote installation sources and let a user install SWORD 
>> content.
>>
>> I've kept the development code name "Bishop", my favorite android (from 
>> Aliens) and almost appropriate for a Bible app :)  I've also tacked on our 
>> boring moniker from our Windows app, "Bishop: The SWORD Project for 
>> Android".  Long name but should get more search hits.
>>
>> Basically, Bishop's UI has 2 basic modes:
>>
>> *Reader*: which simply shows 1 chapter of up to 3 Bibles in parallel.
>> *Verse* *Study*: When in reader mode, as the user scrolls, one verse 
>> will always be active, when "Verse Study" is chosen from the menu, the user 
>> can then drill down into that active verse.  Verse Study has 4 tools:*
>> *
>>
>> *Word* *Study*: shows the verse broken down word by word, showing 
>> the original Greek or Hebrew behind each word, along with a simple 
>> definition.*
>> Commentary*: shows all installed commentary for that verse.
>> *Witness* *Study*: shows all available ancient New Testament 
>> manuscript witnesses which attest to the current verse.
>> *Variant* *Study*: shows all variant between the manuscript 
>> witnesses for the current verse.
>>
>> Other features include very basic bookmarks and search.  The Android release 
>> has an initial attempt at BibleSync support to send your current verse out 
>> to all your friends running Bishop on the same network (thanks Karl!).
>>
>> The initial goal of Bishop was to be the thinnest client on top of the 
>> bindings, as an example and thus uses no 3rd party libraries, save jQuery.  
>> Now that the initial release is completed and can serve as an example, we're 
>> free to improve the mobile user interface if anyone feels called to join the 
>> team and give it a shot.
>>
>> Installation locations follow.  It's best to let Bishop install its basic 
>> set of SWORD modules upon first run, so it has a minimal set of tools it can 
>> use to operate.  It will prompt you to do this when you first launch the 
>> application and it finds no modules installed.
>>
>> Android users can install the app from:
>>
>> https://play.google.com/store/apps/details?id=org.crosswire.bishop
>>
>> iPhone users will need to send me their UDID for testing while we try to get 
>> through the Apple Store approval process.  I haven't even tried yet as I 
>> don't have much hope that it is "pretty" enough for them, but the download 
>> link for the iPhone binary is here:
>>
>> https://crosswire.org/bishop/manifest.plist
>>
>> https://crosswire.org/bishop.ipa
>>
>> The code can be had from:
>>
>> http://git.crosswire.org/main/bishop
>>
>> Please let us know what you think if 

Re: [sword-devel] Normalize the search string (comparing front-end apps)

[David Haslam]

Thanks DM,

Not all searches make use of the Lucene index !

e.g. In Xiphos, the advanced search panel gives the user a choice of which type 
of search.
Lucene is only one of these mutually exclusive options.

btw. Where is it documented that the creation of a Lucene search index 
normalizes the Unicode for the index?
Do we know for certain that this would occur irrespective of whether 
normalization was suppressed during module build?
i.e. With osis2mod option   -N do not convert UTF-8 or normalize UTF-8 to NFC

Best regards,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On 22 March 2018 10:20 AM, DM Smith  wrote:

> The requirement is not that the search is normalized to nfc but rather that 
> it is normalized the same as the index. This should not be a front end issue.
>
> Btw it doesn’t matter how Hebrew is stored in the module. Indexing should 
> normalize it to a form that is internal to the engine.
>
> — DM Smith
> From my phone. Brief. Weird autocorrections.
>
> On Mar 22, 2018, at 5:22 AM, David Haslam  wrote:
>
>> Dear all,
>>
>> Not all front-ends automatically normalize the search string to Unicode NFC.
>> e.g.
>>
>> - Eloquent does
>> - Xiphos does not
>>
>> The data is incomplete for this feature in the table in our wiki page.
>> https://wiki.crosswire.org/Choosing_a_SWORD_program#Search_and_Dictionary
>>
>> Please would other front-end app developers supply the missing information. 
>> Thanks.
>>
>> Further thought:
>> For front-ends that also have an Advanced search feature, would it not be a 
>> useful enhancement to have a tick box option for Search string normalization?
>> Then if we do make any Biblical Hebrew modules with custom normalization, 
>> search could at least still work for the "corner cases" in Hebrew, providing 
>> the user gave the proper input in the search box.
>>
>> cf. The source text for the WLC at tanach.us is not normalized to NFC, but 
>> our module is.
>> I'll refrain from going into a lot more detail here. There's an issue in our 
>> tracker that covers this.
>>
>> Best regards,
>>
>> David
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>> ___
>> 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] Normalize the search string (comparing front-end apps)

[DM Smith]

The requirement is not that the search is normalized to nfc but rather that it 
is normalized the same as the index. This should not be a front end issue.

Btw it doesn’t matter how Hebrew is stored in the module. Indexing should 
normalize it to a form that is internal to the engine. 

— DM Smith
From my phone. Brief. Weird autocorrections. 

> On Mar 22, 2018, at 5:22 AM, David Haslam  wrote:
> 
> Dear all,
> 
> Not all front-ends automatically normalize the search string to Unicode NFC.
> e.g.
> Eloquent does
> Xiphos does not
> The data is incomplete for this feature in the table in our wiki page.
> https://wiki.crosswire.org/Choosing_a_SWORD_program#Search_and_Dictionary
> 
> Please would other front-end app developers supply the missing information. 
> Thanks.
> 
> Further thought:
> For front-ends that also have an Advanced search feature, would it not be a 
> useful enhancement to have a tick box option for Search string normalization?
> Then if we do make any Biblical Hebrew modules with custom normalization, 
> search could at least still work for the "corner cases" in Hebrew, providing 
> the user gave the proper input in the search box.
> 
> cf. The source text for the WLC at tanach.us is not normalized to NFC, but 
> our module is.
> I'll refrain from going into a lot more detail here. There's an issue in our 
> tracker that covers this.
> 
> Best regards,
> 
> David
> 
> Sent with ProtonMail Secure Email.
> 
> ___
> 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] Normalize the search string (comparing front-end apps)

[David Haslam]

Dear all,

Not all front-ends automatically normalize the search string to Unicode NFC.
e.g.

- Eloquent does
- Xiphos does not

The data is incomplete for this feature in the table in our wiki page.
https://wiki.crosswire.org/Choosing_a_SWORD_program#Search_and_Dictionary

Please would other front-end app developers supply the missing information. 
Thanks.

Further thought:
For front-ends that also have an Advanced search feature, would it not be a 
useful enhancement to have a tick box option for Search string normalization?
Then if we do make any Biblical Hebrew modules with custom normalization, 
search could at least still work for the "corner cases" in Hebrew, providing 
the user gave the proper input in the search box.

cf. The source text for the WLC at tanach.us is not normalized to NFC, but our 
module is.
I'll refrain from going into a lot more detail here. There's an issue in our 
tracker that covers this.

Best regards,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
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] Diatheke ?

[David Haslam]

Hi Greg,

With Plain output format, there's a minor side effect in the way the Psalm 
title was output in the wrong place.
Verse 2 of the same Psalm was output with a leading space before the Reference.

https://www.dropbox.com/s/uz1amnrp7ez0b4y/Screenshot%202018-03-22%2008.37.42.png?dl=0

This might be less obvious in a terminal, but it's quite evident when the 
output is piped to a file.

Please ensure that the patch also removes this spurious space, if perhaps it 
ddidn't do so already.

While I'm on a roll, I noticed also that there's a subtle change in how 
diatheke treats the start and end of a hi element.
There's now a space after the leading asterisk and another space before the 
trailing asterisk.
https://www.dropbox.com/s/2h2u1768rgx9p95/Screenshot%202018-03-22%2008.38.21.png?dl=0

If this change was unintended, it ought to be reverted for consistency with 
earlier versions.

Best regards,

David

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On 21 March 2018 3:33 AM, Greg Hellings  wrote:

> On Tue, Mar 20, 2018 at 10:21 PM, Troy A. Griffitts  
> wrote:
>
>> If I had to guess, I suspect diatheke is not calling renderText before 
>> asking for the header. The renderText method triggers all entryAttributes to 
>> be filled. The header is an entryAttribute.
>
> Spot on. If I were offering commentary, I would call that a bug in the UX of 
> the API. But I do get why it is that way. Attaching a patch that solves the 
> problem.
>
> --Greg
>
>> On March 20, 2018 8:13:41 PM MST, Greg Hellings  
>> wrote:
>>
>>> To be quite specific: diatheke does not encounter that header in the 
>>> preverse content until it reaches Psalm 3:2 for some reason that is beyond 
>>> my ken. Therefore, it is properly rendering that content as preverse, but 
>>> it has attached it to the wrong verse. Output from my slightly modified 
>>> diatheke confirms this:
>>>
>>> $ ./inst/bin/diatheke -b KJV -o h -f Plain -k Ps 3
>>> key: Psalms 3:1
>>> header:
>>> Psalms 3:1: LORD, how are they increased that trouble me! many are they 
>>> that rise up against me.
>>> key: Psalms 3:2
>>> header: A 
>>> Psalm of David, >> savlm="strong:H01272">when he fled from >> savlm="strong:H053">Absalom his 
>>> son.
>>> A Psalm of David, when he fled from Absalom his son.
>>> Psalms 3:2: Many there be which say of my soul, There is no help for him in 
>>> God. Selah.
>>>
>>> --Greg
>>>
>>> On Tue, Mar 20, 2018 at 9:53 PM, Greg Hellings  
>>> wrote:
>>>
 It's easier to see the problem when using plain formatting:

 $ diatheke -b KJV -o h -f Plain -k Ps 3
 Psalms 3:1: LORD, how are they increased that trouble me! many are they 
 that rise up against me.
 A Psalm of David, when he fled from Absalom his son.
 Psalms 3:2: Many there be which say of my soul, There is no help for him 
 in God. Selah.
 Psalms 3:3: But thou, O LORD, art a shield for me; my glory, and the 
 lifter up of mine head.
 Psalms 3:4:
 I cried unto the LORD with my voice, and he heard me out of his holy hill. 
 Selah.
 Psalms 3:5: I laid me down and slept; I awaked; for the LORD sustained me.
 Psalms 3:6: I will not be afraid of ten thousands of people, that have set 
 themselves against me round about.
 Psalms 3:7: Arise, O LORD; save me, O my God: for thou hast smitten all 
 mine enemies upon the cheek bone; thou hast broken the teeth of the 
 ungodly.
 Psalms 3:8: Salvation belongeth unto the LORD: thy blessing is upon thy 
 people. Selah.
 (KJV)
 --Greg

 On Tue, Mar 20, 2018 at 9:50 PM, Greg Hellings  
 wrote:

> I'm not so sure your initial assertion is correct.
>
> $ diatheke -b KJV -o h -k Ps 3
> Psalms 3:1:  savlm="strong:H03068">Lord,  savlm="strong:H07231">how are they increased  savlm="strong:H06862">that trouble me! 
> many are  savlm="strong:H06965">they that rise up against me.
> A 
> Psalm of David,  savlm="strong:H01272">when he fled from 
> Absalom his 
> son.Psalms 3:2: Many 
> there be  savlm="strong:H0559">which say of my 
> soul, There is  savlm="strong:H03444">no help for him in 
> God. Selah.
>
> If you notice carefully, the canonical title is there. It is just 
> misplaced. It comes after the text of Psalm 3:1 and not before.
>
> --Greg
>
> On Tue, Mar 20, 2018 at 4:40 PM, David Haslam  
> wrote:
>
>> Maybe someone could patch diatheke to fix this?
>> Best regards, David
>>
>> Sent from ProtonMail Mobile
>>
>> On Wed, Mar 14, 2018 at 12:14, David Haslam  
>> wrote:
>>
>>> Diatheke does not output the canonical Psalm titles when output option 
>>> h is used.
>>>
>>> Try this and