date:20170221

Hi Troy,

Surely there's no doubt the module source text was correctly encoded as
UTF-8 and normalised to NFC?

We can examine the output of mod2imp and see that it is. Or am I missing
something?

mod2imp doesn't change the normalisation form, and I assume it doesn't
change the encoding either.

CzeCEP is not only recent module to which the script has added the
GlobalOptionFilter=UTF8GreekAccents.
FinRK was released yesterday and suffers the same issue.

What I think has happened is this:

The Greek Accents filter was probably never adequately beta tested.

It was accepted after only being alpha tested, to see that it does remove
Greek accents from Greek text that has some.

Nobody thought to check whether it did anything untoward on the UTF-8
encoded text in a variety of non-Greek scripts. The bug has gone undetected
until yesterday. It's either a very old bug, or a library has changed
without anyone noticing.

I understand that the Module Team's script does the following as part of the
automation to build the module conf file:

It applies this filter, checks for change, then adds the filter line to the
conf file if a change was detected.

Knowing this, it's not hard to see how we have ended up with a spurious
Greek Accents filter in some recently released modules, is it?

The mopping up containment action is to determine how many modules have been
released with the spurious filter in the configuration file? These must each
be corrected by removing the line, updating the version and date, and
releasing the update.

The permanent solution should be to find out exactly how this filter works
in detail, and rewrite it if necessary. That would require an update to
SWORD as a significant bug fix.

The most recent mention of this filter in SWORD releases was under 1.5.10
dated 20-Nov-2006 in which you added a further Greek accent. In fact, that's
the only explicit mention. The string "utf8" appears earlier a few times,
but in a more general sense.

NB. Using diatheke version 4.7, I have thoroughly tested CzeCEP for the
four other UTF8 filters. Only GreekAccents is delinquent.

Best regards,

David

PS. If only CrossWire had a "bug bounty" scheme Ah, but we're a
"non-income" organization.
Looking only to the heavenly reward, and the fruit of the Gospel here in
earth. :)

--
View this message in context:
http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656729.html
Sent from the SWORD Dev mailing list archive at Nabble.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] Module upload: CzeCEP

2017-02-21 Thread refdoc

Dear All,
This is to announce that we have just now uploaded CzeCEP.
This is is an updated version of CzeCEP.
Many thanks to Matej for the hard work.

yours

The Module Team

P.S.: This email is sent automatically on upload of a new/updated module

___
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] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

Further proof if this were even needed:

I temporarily added the Greek Accents filter to the conf file for the French
Bible module FreBBB.

Then I ran diatheke on the module.
(i.e. default, without any option "-oa" that would include Greek Accents).

It removed all Latin character diacritics: acute, grave and circonflex
accents, etc.

And the conversion doesn't always look right too. e.g. The word "plaça"
became "plac§a".
So it's not even respecting the UTF-8 encoding character boundaries, is it?
And last time I looked, the Greek script did not use a cedilla!

A similar experiment on our flagship KJV module also found that it removes
the "right single quotation mark" U+2019 used as the typographical
apostrophe for possessives.

In some fonts, that might look similar to U+0343 COMBINING GREEK KORONIS,
but they are not the same codepoint.

So, all in all, unless I've missed a complete howler, it's not looking good
at all.

The filter changes too much!
It's scope needs to be cut right back to deal with Greek diacritics alone.

Best regards,

David








--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656731.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

Thanks David and Troy,

What is happening is - my script tests for presence of Greek accents by doing a 
before-and-after comparison using a Greek accent strip filter. This works 
beautifully for the Hebrew stuff - vowels and breathing marks. It should work 
for the Greek accent filter. It does not. 

The script is under sword-tools/modules/conf/confmaker.pl. Right now the Greek 
accents' option has been commented out, so please have a look at the version 
svn-head-1.

I do not think I use the filter wrong in my script, though of course I am keen 
to hear about any mistakes in my use.

I have noted this a year or two ago and made a remark on the mailing list. I 
simply left my script as it was as it seemed correct and the problem was with 
the library to the best of my understanding.

Peter 

> Gesendet: Dienstag, 21. Februar 2017 um 09:04 Uhr
> Von: "David Haslam" 
> An: sword-devel@crosswire.org
> Betreff: Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek  
> modules
>
> Hi Troy,
> 
> Surely there's no doubt the module source text was correctly encoded as
> UTF-8 and normalised to NFC? 
> 
> We can examine the output of mod2imp and see that it is. Or am I missing
> something?
> 
> mod2imp doesn't change the normalisation form, and I assume it doesn't
> change the encoding either.
> 
> CzeCEP is not only recent module to which the script has added the
> GlobalOptionFilter=UTF8GreekAccents.
> FinRK was released yesterday and suffers the same issue.
> 
> What I think has happened is this:
> 
> The Greek Accents filter was probably never adequately beta tested.
> 
> It was accepted after only being alpha tested, to see that it does remove
> Greek accents from Greek text  that has some.
> 
> Nobody thought to check whether it did anything untoward on the UTF-8
> encoded text in a variety of non-Greek scripts.  The bug has gone undetected
> until yesterday. It's either a very old bug, or a library has changed
> without anyone noticing.
> 
> I understand that the Module Team's script does the following as part of the
> automation to build the module conf file:
> 
> It applies this filter, checks for change, then adds the filter line to the
> conf file if a change was detected.
> 
> Knowing this, it's not hard to see how we have ended up with a spurious
> Greek Accents filter in some recently released modules, is it?
> 
> The mopping up containment action is to determine how many modules have been
> released with the spurious filter in the configuration file? These must each
> be corrected by removing the line, updating the version and date, and
> releasing the update.
> 
> The permanent solution should be to find out exactly how this filter works
> in detail, and rewrite it if necessary. That would require an update to
> SWORD as a significant bug fix.
> 
> The most recent mention of this filter in SWORD releases was under 1.5.10
> dated 20-Nov-2006 in which you added a further Greek accent. In fact, that's
> the only explicit mention. The string "utf8" appears earlier a few times,
> but in a more general sense.
> 
> NB. Using diatheke version 4.7,  I have thoroughly tested CzeCEP for the
> four other UTF8 filters. Only GreekAccents is delinquent.
> 
> Best regards,
> 
> David
> 
> PS. If only CrossWire had a "bug bounty" scheme Ah, but we're a
> "non-income" organization. 
> Looking only to the heavenly reward, and the fruit of the Gospel here in
> earth. :)
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656729.html
> Sent from the SWORD Dev mailing list archive at Nabble.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
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Module upload: CzeCEP

Just installed. 

This fixes the spurious Greek Accents filter issue in the conf file.

NB. There are now two lines with SwordVersionDate=
The older one should be removed asap.

btw. It may take time for the InstallSize= line to be added by the server.

David

Screenshot_2017-02-21_10.png

  




--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Module-upload-CzeCEP-tp4656730p4656733.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

Hi Peter,

I'm sure that your method should work correctly for the UTF-8 Arabic and
Hebrew filters, since AFAIK, and as per my limited amount of testing
yesterday, those filters are well behaved and have restricted scope.

If there'd been nothing wrong with UTF8GreekAccents as a filter, then your
method would have been sound for sure. But the evidence being accumulated
all points to serious defects in the implementation of the filter within
SWORD, and that possibly boils down to a bug in a dependent library such as
the ICU.

It needs someone with more C++ programming knowledge than mine to delve deep
into the source code for this filter in order to find out precisely where it
goes wrong.

With it being a beta testing kind of bug, it's quite conceivable that it was
there from the very beginning.

Best regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656734.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

The filter is located in sword/src/modules/filters and is actually reasonably 
straightforward to read IIRC. Having said this, IU have stared at it many times 
in the past and never saw what was wrong.

Peter

> Gesendet: Dienstag, 21. Februar 2017 um 10:40 Uhr
> Von: "David Haslam" 
> An: sword-devel@crosswire.org
> Betreff: Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek  
> modules
>
> Hi Peter,
> 
> I'm sure that your method should work correctly for the UTF-8 Arabic and
> Hebrew filters, since AFAIK, and as per my limited amount of testing
> yesterday, those filters are well behaved and have restricted scope.
> 
> If there'd been nothing wrong with UTF8GreekAccents as a filter, then your
> method would have been sound for sure. But the evidence being accumulated
> all points to serious defects in the implementation of the filter within
> SWORD, and that possibly boils down to a bug in a dependent library such as
> the ICU.
> 
> It needs someone with more C++ programming knowledge than mine to delve deep
> into the source code for this filter in order to find out precisely where it
> goes wrong.
> 
> With it being a beta testing kind of bug, it's quite conceivable that it was
> there from the very beginning.
> 
> Best regards,
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656734.html
> Sent from the SWORD Dev mailing list archive at Nabble.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
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

Let's hear it from some of the coders, please.

I'd be way out of my depth if I dived into C++ at my age.

My IT skills are better devoted to testing and reporting issues.

Best regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656736.html
Sent from the SWORD Dev mailing list archive at Nabble.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] CrossWire Beta | Updates | English | (Easton, Smith, StrongsGreek, StrongsHebrew) ?

Is there any reason why these four dictionary modules may not be moved from
CrossWire Beta to CrossWire Main ?

CrossWire Beta | Dictionary | English | (Easton, Smith, StrongsGreek,
StrongsHebrew) ?

Best regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/CrossWire-Beta-Updates-English-Easton-Smith-StrongsGreek-StrongsHebrew-tp4656737.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] CrossWire Beta | Updates | English | (Easton, Smith, StrongsGreek, StrongsHebrew) ?

They were the brainchild of Chris and I would not even know what to look for in 
terms of testing them.

I suppose we could simply move them over and see who complains. 

Peter

> Gesendet: Dienstag, 21. Februar 2017 um 12:04 Uhr
> Von: "David Haslam" 
> An: sword-devel@crosswire.org
> Betreff: [sword-devel] CrossWire Beta | Updates | English | (Easton, Smith, 
> StrongsGreek, StrongsHebrew) ?
>
> Is there any reason why these four dictionary modules may not be moved from
> CrossWire Beta to CrossWire Main ?
> 
> CrossWire Beta | Dictionary | English | (Easton, Smith, StrongsGreek,
> StrongsHebrew) ?
> 
> Best regards,
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/CrossWire-Beta-Updates-English-Easton-Smith-StrongsGreek-StrongsHebrew-tp4656737.html
> Sent from the SWORD Dev mailing list archive at Nabble.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
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire Beta | Updates | English | (Easton, Smith, StrongsGreek, StrongsHebrew) ?

On 02/21/2017 07:14 AM, Peter Von Kaehne wrote:
> I suppose we could simply move them over and see who complains. 

That novel attitude could be applied as well to NASB, and has been
suggested exactly as such repeatedly in the past. But the naysayers have
prevailed every time the matter has come up.

___
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] CrossWire Beta | Updates | English | (Easton, Smith, StrongsGreek, StrongsHebrew) ?


Oh, indeed.

 

Von: "Karl Kleinpaste" 



On 02/21/2017 07:14 AM, Peter Von Kaehne wrote:


I suppose we could simply move them over and see who complains. 


That novel attitude could be applied as well to NASB, and has been suggested exactly as such repeatedly in the past. But the naysayers have prevailed every time the matter has come up.






___
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] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

Further proof  (specially for Peter) 

As far as I know, Luther wasn't Greek.

A similar experiment with module GerLut1545 showed that all the umlauts are
removed by the UTF8GreekAccents filter.

diff B
S:/Export/GerLut1545/2014-01-17/GerLut1545.diatheke.character.frequency.txt
S:/Export/GerLut1545/Greek
accents/GerLut1545.diatheke.character.frequency.txt
23c23
< 41A   10,838  LATIN CAPITAL LETTER A
---
> 41A   11,887  LATIN CAPITAL LETTER A
37c37
< 4FO   5,758   LATIN CAPITAL LETTER O
---
> 4FO   6,017   LATIN CAPITAL LETTER O
43c43
< 55U   9,646   LATIN CAPITAL LETTER U
---
> 55U   9,951   LATIN CAPITAL LETTER U
49c49
< 61a   194,446 LATIN SMALL LETTER A
---
> 61a   206,137 LATIN SMALL LETTER A
63c63
< 6Fo   81,022  LATIN SMALL LETTER O
---
> 6Fo   92,193  LATIN SMALL LETTER O
69c69
< 75u   135,404 LATIN SMALL LETTER U
---
> 75u   152,211 LATIN SMALL LETTER U
77,79d76
< C4Ä   1,049   LATIN CAPITAL LETTER A WITH DIAERESIS
< D6Ö   259 LATIN CAPITAL LETTER O WITH DIAERESIS
< DCÜ   305 LATIN CAPITAL LETTER U WITH DIAERESIS
81,83d77
< E4ä   11,691  LATIN SMALL LETTER A WITH DIAERESIS
< F6ö   11,171  LATIN SMALL LETTER O WITH DIAERESIS
< FCü   16,807  LATIN SMALL LETTER U WITH DIAERESIS

Best regards,

David




--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656741.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] CrossWire Beta | Updates | English | (Easton, Smith, StrongsGreek, StrongsHebrew) ?

But with the difference that Greg took it upon himself to be the NASB
custodian when a certain coder went AWOL.

Notwithstanding, it should be feasible to compare each of the four beta
modules with the one it's intended to replace.

And I suppose, we could enlist help from the experts at Tyndale House (STEP
Bible).

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/CrossWire-Beta-Updates-English-Easton-Smith-StrongsGreek-StrongsHebrew-tp4656737p4656742.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] CrossWire Beta | Updates | English | (Easton, Smith, StrongsGreek, StrongsHebrew) ?

Karl,

Presumably, the dictionary modules StrongsRealGreek and StrongsRealHebrew in
the Xiphos repository are each what one might call a "superset" of
StrongsGreek and StrongsHebrew ?

I don't know whether our good friends at Tyndale House have spotted these
yet.

Best regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/CrossWire-Beta-Updates-English-Easton-Smith-StrongsGreek-StrongsHebrew-tp4656737p4656743.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] CrossWire Beta | Updates | English | (Easton, Smith, StrongsGreek, StrongsHebrew) ?

On 02/21/2017 08:36 AM, David Haslam wrote:
> he dictionary modules StrongsRealGreek and StrongsRealHebrew in
> the Xiphos repository are each what one might call a "superset" of
> StrongsGreek and StrongsHebrew ?

I have no idea of the provenance or content of Strongs{Greek,Hebrew}. My
StrongsReal{Greek,Hebrew} are self-documenting for their origin via
links in their About content. I wanted Strong's dictionaries with the
actual (Real) alphabets rather than transliteration; they have been kept
in an ongoing maintained state for many years now, though irregularly.
(I haven't heard from Ulrik in quite a long time now.)

___
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] Lucene Complaint

I know it's been mentioned and hinted at in the past, but I wanted to -
again - lodge a complaint regarding the inertia of CLucene use in the
engine.

CLucene's last release, and last git commit on SourceForge was in 2013. It
has had none of the language-specific updates that Lucene has generated
upstream which is one of the best parts of the Lucene ecosystem.

It has always suffered from GCC-on-Windows specific compile bugs,
especially related to uses of pthread, and since upstream went defunct now
4 years ago there has been no movement to fix them correctly. Fixes need to
be maintained by downstream teams. Even the native Linux packaging depends
on a number of patches just to be able to compile, because upstream has no
interest in even putting out a usable product.

With the recent release of GCC 7, CLucene has become - once again - a FTBFS
package on MinGW/Windows targets. This is going to necessitate dropping the
package from the MinGW builds of Sword that I maintain for Fedora which
will make future releases of Xiphos for Windows incapable of offering
Lucene based searching.

Is there any whiff of hope that we might be willing to move off of
depending on CLucene for advanced search support and onto a project that
has any amount of vitality?

--Greg
___
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] NASB

2017-02-21 Thread Matt Zabojnik

What's the status on the NASB module? I saw it mentioned in the dictionary
message. This is the first I've heard of it, being new to sword devel.

I'm currently working to convert NASB with strongs, footnotes and
references, but I need to learn OSIS and RegEx better first.

Who here is the point-man on tyre work that's already been done there?
___
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] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

A further idiosyncrasy of the UTF8GreekAccents filter that proves to be an
interesting clue:

It changes U+00BE VULGAR FRACTION THREE QUARTERS ¾ to ordinary 3/4.

Vulgar fractions are about as far as you can get from Koine Greek, nicht
wahr?

This is what I think this proves:

It must first decompose the Unicode to either NFKD or NFKC as a prelude to
removing the "accents".
These are two of the four canonical normalization forms in Unicode.

It should in theory then renormalize to NFC after the Greek accents have
been removed.
Without the diacritics, this wouldn't be needed unless some non-Greek
composite characters had also been present in the original module text.

This particular example is of significance in that once you've got "3/4" no
amount of renormalization to NFC would change it back to the special Unicode
vulgar fraction ¾.

Some aspects of Unicode normalization cannot be reversed.

Who'd have thought that my suggestion to use this vulgar fraction character
in one single verse of a Punjabi Bible could later prove to be useful
evidence in the case for the prosecution?

II Chronicles 1:17: ਸੁਲੇਮਾਨ ਦੇ ਵਿਉਪਾਰੀ ਮਿਸਰ ਤੋਂ ਇੱਕ ਰੱਥ ਚਾਂਦੀ ਦੇ 15 ਪੌਂਡ ਦਾ
ਅਤੇ ਇੱਕ ਘੋੜਾ ਚਾਂਦੀ ਦੇ 3¾ ਪੌਂਡ ਦਾ ਖਰੀਦਦੇ ਸਨ । ਫ਼ੇਰ ਉਨ੍ਹਾਂ ਨੇ ਇਹ ਘੋੜੇ ਅਤੇ ਰੱਥ
ਹਿੱਤੀ ਲੋਕਾਂ ਦੇ ਰਾਜਿਆਂ ਅਤੇ ਆਰਾਮ ਦੇ ਰਾਜਿਆਂ ਨੂੰ ਵੇਚ ਦਿੱਤੇ ।   


Well there we are, you see. :)


David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656747.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] NASB

Eons ago, Crosswire received permission from Lockman to begin work on an
NSAB module that they could commercially deliver to users who paid for it.

Many people have tackled the work of performing the conversions from
Lockman's internal, proprietary markup to a Sword module. Each one has, for
various reasons, abandoned the work. Most recently it was me, and I gave up
due to a lack of a consistent or realistic objective for delivery of the
results to Lockman.

You can, essentially, assume that nothing more will ever come of it from
the official channel. You'd be best to pursue converting another digital
source for your own personal use.

--Greg

On Tue, Feb 21, 2017 at 1:06 PM, Matt Zabojnik  wrote:

> What's the status on the NASB module? I saw it mentioned in the dictionary
> message. This is the first I've heard of it, being new to sword devel.
>
> I'm currently working to convert NASB with strongs, footnotes and
> references, but I need to learn OSIS and RegEx better first.
>
> Who here is the point-man on tyre work that's already been done there?
>
> ___
> 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] Release Wrapup

On Sun, Feb 19, 2017 at 12:06 PM, David Haslam 
wrote:

> Are we any closer to a release of SWORD v1.8 ?
>

No. I don't think there's been a single commit to the engine since that
time. At least, I don't recall seeing any messages float across my desk.

>
> cf. Troy started this thread last October.
>
> As someone without any experience of C++ programming, I sometimes wonder
> how
> many C++ programmers are still active in CrossWire. It seems far, far fewer
> than when I first linked up with CrossWire in 2008.
>

As far as people who mainly work in C++, we're probably at one (Troy).
Maybe two (Karl? I feel like he prefers C).

There are a few others of us who know it, and can - in a pinch - make some
fixes to it. There are some others in the broader community who are in the
C++ world (Jaak, Gary, etc) but none of them are active on the engine for
myriad reasons.

--Greg

>
> cf. Last month, Karl noted some anniversaries that are passing us by yet
> again
>
> Which known bugs in the engine will be fixed in v1.8 ?
>
> Best regards,
>
> David
>
>
>
> --
> View this message in context: http://sword-dev.350566.n4.
> nabble.com/Release-Wrapup-tp4656501p4656698.html
> Sent from the SWORD Dev mailing list archive at Nabble.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
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Lucene Complaint

2017-02-21 Thread Peter von Kaehne

On Tue, 2017-02-21 at 11:25 -0600, Greg Hellings wrote:
> 
> Is there any whiff of hope that we might be willing to move off of
> depending on CLucene for advanced search support and onto a project
> that has any amount of vitality?
> 

I thought we had? Xapian is the new default at svn head

Peter

___
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] Lucene Complaint

Really? I know there had been some conversations around Xapian and a brief
start on a proof of concept, but I was unaware that it had made it into
HEAD or even into living code at all.

--Greg

On Tue, Feb 21, 2017 at 1:54 PM, Peter von Kaehne  wrote:

> On Tue, 2017-02-21 at 11:25 -0600, Greg Hellings wrote:
> >
> > Is there any whiff of hope that we might be willing to move off of
> > depending on CLucene for advanced search support and onto a project
> > that has any amount of vitality?
> >
>
> I thought we had? Xapian is the new default at svn head
>
> Peter
>
> ___
> 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] Release Wrapup

On Sun, Feb 19, 2017 at 1:52 PM, Matt Zabojnik  wrote:

> I don't mean to derail this in any way. I've previously only had
> experience with HTML/PHP/SQL, and I'm now learning Python (in order to
> develop a SWORD-related Android app)
>
> Would it be beneficial to port the whole project to Python? That seems to
> be a widely known and easy to learn language.
> Forgive my ignorance if this question is completely unreasonable. I've
> previously only ventured into hack-together type of workaround stuff when
> it comes to computers, rather than true programming. (Learning RegEx has
> been an amazing eye-opening experience in module making)
>

Not likely. There is already an existing Java port, and there is little
interest in maintaining more than the one official port. The language is
not a significant barrier to improvement, adoption, or advancement. In
fact, being written in decently portable C and C++ is one of the best
technical merits of the engine. It allows us to offer bindings to Perl (for
scripting) and Python (for BPBible and the like), and wrappers into
Objective-C (for our Mac and iPhone apps), and into the JNI interface (for
at least one Android app). Maintaining a pure-Java port gives access to
other environments (Java Swing UI, web, and native Android) and could allow
easy access to others as well (e.g. Jython, JRuby, JavaScript).

If you were going to start a whole new port into a language like Python you
would begin to open the door to format shifting the modules, and a whole
host of other things that would be incompatible with the current project.
Not many Python developers are going to happily attack the binary flat
format that a Sword module currently lives in. They're going to want to use
something else, most likely. You're going to lose out on around two decades
of support, features, bug fixes, and small tweaks and have to start again
to re-gain the code maturity that the engine already has. And there's far
more you'd lose out on.

No, a new port is not likely to happen within the community. Not to say it
couldn't happen outside of the community. But you're not likely to get core
developer support for abandoning the current library and shifting to a new
port into a language like Python. The closest you'll probably get is forks,
like the existing Sword++ fork. Or people who have wrapped Sword in order
to format shift content, e.g. into a SQL database or JSON or such, for use
in a new application.

--Greg

> I know BPBible was written mostly in Python. If I get good enough at
> Python and have the time I may fork and develop that front-end where I can.
> I'm still pretty green though to say the least.
>
> On Sun, Feb 19, 2017 at 11:06 AM, David Haslam 
> wrote:
>
>> Are we any closer to a release of SWORD v1.8 ?
>>
>> cf. Troy started this thread last October.
>>
>> As someone without any experience of C++ programming, I sometimes wonder
>> how
>> many C++ programmers are still active in CrossWire. It seems far, far
>> fewer
>> than when I first linked up with CrossWire in 2008.
>>
>> cf. Last month, Karl noted some anniversaries that are passing us by yet
>> again
>>
>> Which known bugs in the engine will be fixed in v1.8 ?
>>
>> Best regards,
>>
>> David
>>
>>
>>
>> --
>> View this message in context: http://sword-dev.350566.n4.nab
>> ble.com/Release-Wrapup-tp4656501p4656698.html
>> Sent from the SWORD Dev mailing list archive at Nabble.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
>>
>
>
>
> --
> --
> PGP ID: 0x5fa5cbaecfd5690c
> --
>
> ___
> 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] Lucene Complaint

On 02/21/2017 12:25 PM, Greg Hellings wrote:
> This is going to necessitate dropping the package from the MinGW
> builds of Sword that I maintain for Fedora which will make future
> releases of Xiphos for Windows incapable of offering Lucene based
> searching.

I will keep using "outdated" MinGW packages for as long as I have to,
including clucene. mingw*-clucene-2.3.3.4-14 suits me just fine.

___
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] Lucene Complaint

On 02/21/2017 02:54 PM, Peter von Kaehne wrote:
> Xapian is the new default at svn head

I experimented with Xapian in Xiphos a couple years ago. The indices it
creates are of horrifyingly monstrous size.

___
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] Lucene Complaint

If memory serves, that was back in pre-1.0 days. The version currently
packaged in Fedora is 1.2.24.

--Greg

On Tue, Feb 21, 2017 at 2:06 PM, Karl Kleinpaste 
wrote:

> On 02/21/2017 02:54 PM, Peter von Kaehne wrote:
>
> Xapian is the new default at svn head
>
> I experimented with Xapian in Xiphos a couple years ago. The indices it
> creates are of horrifyingly monstrous size.
>
> ___
> 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

The Tyndale STEP (the JSword based app) team will be releasing a Tyndale
House edition of the NASB as a SWORD module.

Dr David Instone-Brewer has let me have a prerelease copy of the module.

Here's a line from the .conf file.

About=The Holy Bible, New American Standard Version. Copyright © 1995
by The Lockman Foundation. All rights reserved.\par\par\par\par The Strong
number tagging was added by the Lockman Foundation. It was adapted by STEP
at Tyndale House Cambridge to align with the BDB lexicon. This is a
development the Lockman Foundation tagging so it is subject to their
copyright. \par\par\par\par The text of the New American Standard Bible®
may be quoted and/or reprinted up to and inclusive of five hundred (500)
verses without express written permission of The Lockman Foundation,
providing the verses do not amount to a complete book of the Bible nor do
the verses quoted account for more than 25% of the total work in which they
are quoted.\par\par Notice of copyright must appear on the title or
copyright page of the work as follows:\par\par“Scripture taken from
the NEW AMERICAN STANDARD BIBLE®, Copyright ©
1960,1962,1963,1968,1971,1972,1973,1975,1977,1995 by The Lockman Foundation.
Used by permission.”\par\par Quotations and/or reprints in excess of
the above limitations, or other permission requests, must be submitted
online or directed to and approved in writing by The Lockman Foundation, PO
Box 2279, La Habra, CA 90631, (714)879-3055.

This and some other modules made by STEP had invalid module names containing
a hyphen.
STEP are renaming these accordingly.

It is hoped that STEP will also host and maintain their own modules
repository, one that could in theory be added to CrossWire's master
repositories list.

Best regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/NASB-tp4656746p4656755.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] Release Wrapup

2017-02-21 Thread Tomas Groth

Regarding SWORD and python, I'll just leave this here:
https://gitlab.com/tgc-dk/pysword

No, it is *not* backed by anyone but me.
And no, it does not implement all the features of libSword, nor is it meant
to.

Best regards,
Tomas

Den 21/02/2017 20:52 skrev "Greg Hellings" :

>
>
> On Sun, Feb 19, 2017 at 1:52 PM, Matt Zabojnik  wrote:
>
>> I don't mean to derail this in any way. I've previously only had
>> experience with HTML/PHP/SQL, and I'm now learning Python (in order to
>> develop a SWORD-related Android app)
>>
>> Would it be beneficial to port the whole project to Python? That seems to
>> be a widely known and easy to learn language.
>> Forgive my ignorance if this question is completely unreasonable. I've
>> previously only ventured into hack-together type of workaround stuff when
>> it comes to computers, rather than true programming. (Learning RegEx has
>> been an amazing eye-opening experience in module making)
>>
>
> Not likely. There is already an existing Java port, and there is little
> interest in maintaining more than the one official port. The language is
> not a significant barrier to improvement, adoption, or advancement. In
> fact, being written in decently portable C and C++ is one of the best
> technical merits of the engine. It allows us to offer bindings to Perl (for
> scripting) and Python (for BPBible and the like), and wrappers into
> Objective-C (for our Mac and iPhone apps), and into the JNI interface (for
> at least one Android app). Maintaining a pure-Java port gives access to
> other environments (Java Swing UI, web, and native Android) and could allow
> easy access to others as well (e.g. Jython, JRuby, JavaScript).
>
> If you were going to start a whole new port into a language like Python
> you would begin to open the door to format shifting the modules, and a
> whole host of other things that would be incompatible with the current
> project. Not many Python developers are going to happily attack the binary
> flat format that a Sword module currently lives in. They're going to want
> to use something else, most likely. You're going to lose out on around two
> decades of support, features, bug fixes, and small tweaks and have to start
> again to re-gain the code maturity that the engine already has. And there's
> far more you'd lose out on.
>
> No, a new port is not likely to happen within the community. Not to say it
> couldn't happen outside of the community. But you're not likely to get core
> developer support for abandoning the current library and shifting to a new
> port into a language like Python. The closest you'll probably get is forks,
> like the existing Sword++ fork. Or people who have wrapped Sword in order
> to format shift content, e.g. into a SQL database or JSON or such, for use
> in a new application.
>
> --Greg
>
>
>> I know BPBible was written mostly in Python. If I get good enough at
>> Python and have the time I may fork and develop that front-end where I can.
>> I'm still pretty green though to say the least.
>>
>> On Sun, Feb 19, 2017 at 11:06 AM, David Haslam 
>> wrote:
>>
>>> Are we any closer to a release of SWORD v1.8 ?
>>>
>>> cf. Troy started this thread last October.
>>>
>>> As someone without any experience of C++ programming, I sometimes wonder
>>> how
>>> many C++ programmers are still active in CrossWire. It seems far, far
>>> fewer
>>> than when I first linked up with CrossWire in 2008.
>>>
>>> cf. Last month, Karl noted some anniversaries that are passing us by yet
>>> again
>>>
>>> Which known bugs in the engine will be fixed in v1.8 ?
>>>
>>> Best regards,
>>>
>>> David
>>>
>>>
>>>
>>> --
>>> View this message in context: http://sword-dev.350566.n4.nab
>>> ble.com/Release-Wrapup-tp4656501p4656698.html
>>> Sent from the SWORD Dev mailing list archive at Nabble.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
>>>
>>
>>
>>
>> --
>> --
>> PGP ID: 0x5fa5cbaecfd5690c
>> --
>>
>> ___
>> 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] Lucene Complaint

On 02/21/2017 03:10 PM, Greg Hellings wrote:
> The version currently packaged in Fedora is 1.2.24.

Something is confused.

2.3.3.4 here, along with retro 0.9.21b.

$ egrep '^(|mingw.*)clucene' /var/log/rpmpkgs
clucene09-core-0.9.21b-16.fc24.i686.rpm
clucene09-core-0.9.21b-16.fc24.x86_64.rpm
clucene-contribs-lib-2.3.3.4-24.20130812.e8e3d20git.fc24.i686.rpm
clucene-contribs-lib-2.3.3.4-24.20130812.e8e3d20git.fc24.x86_64.rpm
clucene-core-2.3.3.4-24.20130812.e8e3d20git.fc24.i686.rpm
clucene-core-2.3.3.4-24.20130812.e8e3d20git.fc24.x86_64.rpm
clucene-core-devel-2.3.3.4-24.20130812.e8e3d20git.fc24.i686.rpm
clucene-core-devel-2.3.3.4-24.20130812.e8e3d20git.fc24.x86_64.rpm
mingw32-clucene-2.3.3.4-14.fc24.noarch.rpm
mingw64-clucene-2.3.3.4-14.fc24.noarch.rpm

___
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] Lucene Complaint

On 02/21/2017 03:10 PM, Greg Hellings wrote:
> The version currently packaged in Fedora is 1.2.24.

Scratch other response -- got confused between mentions of clucene and
xapian. Duh.

___
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] Release Wrapup

2017-02-21 Thread Костя Маслюк

> There are a few others of us who know it, and can - in a pinch - make
some fixes to it. There are some others in the broader community who are in
the C++ world (Jaak, Gary, etc) but none of them are active on the engine
for myriad reasons

I d be happy if it would be possible to be more active in engine
development than Troy do.

Just a thought, blessings.
___
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] Lucene Complaint

2017-02-21 Thread DM Smith

When I contributed to Lucene (Java version) there were folks there who lurked 
on the mailing lists that were part of the C port.

Anyway, I mention it as searching those lists or signing up and asking 
questions might give appropriate insight.

DM

> On Feb 21, 2017, at 12:25 PM, Greg Hellings  wrote:
> 
> I know it's been mentioned and hinted at in the past, but I wanted to - again 
> - lodge a complaint regarding the inertia of CLucene use in the engine.
> 
> CLucene's last release, and last git commit on SourceForge was in 2013. It 
> has had none of the language-specific updates that Lucene has generated 
> upstream which is one of the best parts of the Lucene ecosystem.
> 
> It has always suffered from GCC-on-Windows specific compile bugs, especially 
> related to uses of pthread, and since upstream went defunct now 4 years ago 
> there has been no movement to fix them correctly. Fixes need to be maintained 
> by downstream teams. Even the native Linux packaging depends on a number of 
> patches just to be able to compile, because upstream has no interest in even 
> putting out a usable product.
> 
> With the recent release of GCC 7, CLucene has become - once again - a FTBFS 
> package on MinGW/Windows targets. This is going to necessitate dropping the 
> package from the MinGW builds of Sword that I maintain for Fedora which will 
> make future releases of Xiphos for Windows incapable of offering Lucene based 
> searching.
> 
> Is there any whiff of hope that we might be willing to move off of depending 
> on CLucene for advanced search support and onto a project that has any amount 
> of vitality?
> 
> --Greg
> ___
> 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] Lucene Complaint

There is another port - lucene++ - that I've read is the reason CLucene was
abandoned. It targets compatibility with Lucene 3 vs CLucene's targeting of
Lucene 2. It's on github, and its last commit was ~9 months ago. At least
it's better than 2013!

There's also Apache Lucy, which is a "loose C" port of Lucene that is
specifically targeting languages that require bindings. It's active and up
to date, based on its current git activity.

I have no idea if any of them are more feature-complete than CLucene.

If Xapian support really is present in HEAD and is decent and stable, then
my complaint would be moot - if we could get a 1.8 release moving. If those
things fail, my complaint remains lodged.

--Greg

On Tue, Feb 21, 2017 at 2:36 PM, DM Smith  wrote:

> When I contributed to Lucene (Java version) there were folks there who
> lurked on the mailing lists that were part of the C port.
>
> Anyway, I mention it as searching those lists or signing up and asking
> questions might give appropriate insight.
>
> DM
>
> > On Feb 21, 2017, at 12:25 PM, Greg Hellings 
> wrote:
> >
> > I know it's been mentioned and hinted at in the past, but I wanted to -
> again - lodge a complaint regarding the inertia of CLucene use in the
> engine.
> >
> > CLucene's last release, and last git commit on SourceForge was in 2013.
> It has had none of the language-specific updates that Lucene has generated
> upstream which is one of the best parts of the Lucene ecosystem.
> >
> > It has always suffered from GCC-on-Windows specific compile bugs,
> especially related to uses of pthread, and since upstream went defunct now
> 4 years ago there has been no movement to fix them correctly. Fixes need to
> be maintained by downstream teams. Even the native Linux packaging depends
> on a number of patches just to be able to compile, because upstream has no
> interest in even putting out a usable product.
> >
> > With the recent release of GCC 7, CLucene has become - once again - a
> FTBFS package on MinGW/Windows targets. This is going to necessitate
> dropping the package from the MinGW builds of Sword that I maintain for
> Fedora which will make future releases of Xiphos for Windows incapable of
> offering Lucene based searching.
> >
> > Is there any whiff of hope that we might be willing to move off of
> depending on CLucene for advanced search support and onto a project that
> has any amount of vitality?
> >
> > --Greg
> > ___
> > 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

2017-02-21 Thread Matt Zabojnik

Thanks for the info!

Would you mind explaining in different terms your reason for aborting the
project? I didn't fully understand. Delivering to Lockman wasn't going to
work for some reason?

I haven't yet started working on this module, but the intent will be mass
distribution rather than personal use only.

Is it common for people to convert stuff for personal use? And how
important is it to declare where I obtained a source text for public domain
materials? I didn't see coverage on either of those in the wiki.

On Tue, Feb 21, 2017, 12:15 PM Greg Hellings 
wrote:

Eons ago, Crosswire received permission from Lockman to begin work on an
NSAB module that they could commercially deliver to users who paid for it.

Many people have tackled the work of performing the conversions from
Lockman's internal, proprietary markup to a Sword module. Each one has, for
various reasons, abandoned the work. Most recently it was me, and I gave up
due to a lack of a consistent or realistic objective for delivery of the
results to Lockman.

You can, essentially, assume that nothing more will ever come of it from
the official channel. You'd be best to pursue converting another digital
source for your own personal use.

--Greg

On Tue, Feb 21, 2017 at 1:06 PM, Matt Zabojnik  wrote:

What's the status on the NASB module? I saw it mentioned in the dictionary
message. This is the first I've heard of it, being new to sword devel.

I'm currently working to convert NASB with strongs, footnotes and
references, but I need to learn OSIS and RegEx better first.

Who here is the point-man on tyre work that's already been done there?

___
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

On Tue, Feb 21, 2017 at 2:45 PM, Matt Zabojnik  wrote:

> Thanks for the info!
>
> Would you mind explaining in different terms your reason for aborting the
> project? I didn't fully understand. Delivering to Lockman wasn't going to
> work for some reason?
>
The reasons are deep and political. Those who need to know them, already
know them.


> I haven't yet started working on this module, but the intent will be mass
> distribution rather than personal use only.
>
The text is under Copyright by Lockman. Distributing the work would not be
legally permitted without obtaining their permission.

> Is it common for people to convert stuff for personal use? And how
> important is it to declare where I obtained a source text for public domain
> materials? I didn't see coverage on either of those in the wiki.
>
It's important for our own resources to know whence the upstream work was
found. This allows repeatable module generation should the upstream source
ever be updated and corrected. Very often problems are uncovered in
upstream works during the module creation process and this typically
continues once the module is in users' hands. The NASB, however, is not a
public domain work.

--Greg

>
> On Tue, Feb 21, 2017, 12:15 PM Greg Hellings 
> wrote:
>
> Eons ago, Crosswire received permission from Lockman to begin work on an
> NSAB module that they could commercially deliver to users who paid for it.
>
> Many people have tackled the work of performing the conversions from
> Lockman's internal, proprietary markup to a Sword module. Each one has, for
> various reasons, abandoned the work. Most recently it was me, and I gave up
> due to a lack of a consistent or realistic objective for delivery of the
> results to Lockman.
>
> You can, essentially, assume that nothing more will ever come of it from
> the official channel. You'd be best to pursue converting another digital
> source for your own personal use.
>
> --Greg
>
> On Tue, Feb 21, 2017 at 1:06 PM, Matt Zabojnik  wrote:
>
> What's the status on the NASB module? I saw it mentioned in the dictionary
> message. This is the first I've heard of it, being new to sword devel.
>
> I'm currently working to convert NASB with strongs, footnotes and
> references, but I need to learn OSIS and RegEx better first.
>
> Who here is the point-man on tyre work that's already been done there?
>
> ___
> 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] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

These are the principal diacritics found in Biblical Greek that have to be
removed with a UTF8GreekAccents filter.

The first five are general accents, not particular to Greek.
It's on account of these that the filter should not be applied to non-Greek
text.

U+0300 ̀ COMBINING GRAVE ACCENT
U+0301 ́ COMBINING ACUTE ACCENT
U+0308 ̈ COMBINING DIAERESIS
U+0313 ̓ COMBINING COMMA ABOVE
U+0314 ̔ COMBINING REVERSED COMMA ABOVE
U+0342 ͂ COMBINING GREEK PERISPOMENI
U+0343 ̓ COMBINING GREEK KORONIS
U+0344 ̈́ COMBINING GREEK DIALYTIKA TONOS
U+0345 ͅ COMBINING GREEK YPOGEGRAMMENI

No other diacritics or characters should be removed.
Though there are a few more combining accents in this block, they aren't
really used in Biblical Greek.
I am open to correction on this point.

e.g. The right single quotation mark (U+2019) is NOT a diacritic. It should
not be removed.

Before any of these accents can be removed, they must first be separated
from the Greek letters they are combined with.

Although normalization to the decomposed form can produce this effect, as we
have seen already, this can have undesirable side effects on any non-Greek
text in the module that may happen to include combined or unusual
characters.

It would therefore be more sensible to simply use a comprehensive mapping
table that replaces each possible accented character by the corresponding
letter in the Greek alphabet. In this way the filter can completely avoid
the need to apply any Unicode normalization.

The complete mapping table would have at least 130 rows. It will need to
take into account that there are at least 75 possible combinations of a
letter with two accents. There are none with three.

Any residual combining characters should also be removed, to cover the
possibility that a module may have been intentionally made without
normalizing the Greek source text by default to NFC.

That's my proposal. I can easily create such a mapping table that
programmers can use.
I can also readily test it with a bespoke TextPipe filter.

Best regards,

David

--
View this message in context:
http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656765.html
Sent from the SWORD Dev mailing list archive at Nabble.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

Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

2017-02-21 Thread Troy A. Griffitts


Simply don't use the UTF-8 Greek Accent filter on non-Greek texts. As you have 
discovered there are accents used in Greek which are also used in other 
languages and adverse effects will be seen for these languages. The bottom line 
is simple. Only use the UTF-8 Greek Accents filter on UTF-8 Greek texts.

Hope this helps.

On February 21, 2017 2:45:24 PM MST, David Haslam  wrote:
>These are the principal diacritics found in Biblical Greek that have to
>be
>removed with a UTF8GreekAccents filter.
>
>The first five are general accents, not particular to Greek.
>It's on account of these that the filter should not be applied to
>non-Greek
>text.
>
>U+0300 ̀   COMBINING GRAVE ACCENT
>U+0301 ́   COMBINING ACUTE ACCENT
>U+0308 ̈   COMBINING DIAERESIS
>U+0313 ̓   COMBINING COMMA ABOVE
>U+0314 ̔   COMBINING REVERSED COMMA ABOVE
>U+0342 ͂   COMBINING GREEK PERISPOMENI
>U+0343 ̓   COMBINING GREEK KORONIS
>U+0344 ̈́   COMBINING GREEK DIALYTIKA TONOS
>U+0345 ͅ   COMBINING GREEK YPOGEGRAMMENI
>
>No other diacritics or characters should be removed. 
>Though there are a few more combining accents in this block, they
>aren't
>really used in Biblical Greek.
>I am open to correction on this point.
>
>e.g. The right single quotation mark (U+2019) is NOT a diacritic. It
>should
>not be removed.
>
>Before any of these accents can be removed, they must first be
>separated
>from the Greek letters they are combined with. 
>
>Although normalization to the decomposed form can produce this effect,
>as we
>have seen already, this can have undesirable side effects on any
>non-Greek
>text in the module that may happen to include combined or unusual
>characters.
>
>It would therefore be more sensible to simply use a comprehensive
>mapping
>table that replaces each possible accented character by the
>corresponding
>letter in the Greek alphabet. In this way the filter can completely
>avoid
>the need to apply any Unicode normalization. 
>
>The complete mapping table would have at least 130 rows. It will need
>to
>take into account that there are at least 75 possible combinations of a
>letter with two accents. There are none with three.
>
>Any residual combining characters should also be removed, to cover the
>possibility that a module may have been intentionally made without
>normalizing the Greek source text by default to NFC.
>
>That's my proposal. I can easily create such a mapping table that
>programmers can use.
>I can also readily test it with a bespoke TextPipe filter.
>
>
>Best regards,
>
>David
>
>
>
>
>
>--
>View this message in context:
>http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656765.html
>Sent from the SWORD Dev mailing list archive at Nabble.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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] NASB

2017-02-21 Thread Matt Zabojnik

>
> The reasons are deep and political. Those who need to know them, already
> know them.

I appreciate your discretion in  your answer. Conversion difficulties was
what I was primarily concerned with, so this is, in a sense, good news.

The text is under Copyright by Lockman. Distributing the work would not be
> legally permitted without obtaining their permission.

Thank you. I have permission.

It's important for our own resources to know whence the upstream work was
> found.

I see. That being the case, there's no reason I wouldn't be able to convert
a PD work from Zefania XML for example, or any other format I find it in,
correct?

Thank you for your ongoing support and information. It is indeed very
helpful.

Blessings,
Matt

On Tue, Feb 21, 2017 at 1:50 PM, Greg Hellings 
wrote:

>
>
> On Tue, Feb 21, 2017 at 2:45 PM, Matt Zabojnik  wrote:
>
>> Thanks for the info!
>>
>> Would you mind explaining in different terms your reason for aborting the
>> project? I didn't fully understand. Delivering to Lockman wasn't going to
>> work for some reason?
>>
> The reasons are deep and political. Those who need to know them, already
> know them.
>
>
>> I haven't yet started working on this module, but the intent will be mass
>> distribution rather than personal use only.
>>
> The text is under Copyright by Lockman. Distributing the work would not be
> legally permitted without obtaining their permission.
>
>> Is it common for people to convert stuff for personal use? And how
>> important is it to declare where I obtained a source text for public domain
>> materials? I didn't see coverage on either of those in the wiki.
>>
> It's important for our own resources to know whence the upstream work was
> found. This allows repeatable module generation should the upstream source
> ever be updated and corrected. Very often problems are uncovered in
> upstream works during the module creation process and this typically
> continues once the module is in users' hands. The NASB, however, is not a
> public domain work.
>
> --Greg
>
>>
>> On Tue, Feb 21, 2017, 12:15 PM Greg Hellings 
>> wrote:
>>
>> Eons ago, Crosswire received permission from Lockman to begin work on an
>> NSAB module that they could commercially deliver to users who paid for it.
>>
>> Many people have tackled the work of performing the conversions from
>> Lockman's internal, proprietary markup to a Sword module. Each one has, for
>> various reasons, abandoned the work. Most recently it was me, and I gave up
>> due to a lack of a consistent or realistic objective for delivery of the
>> results to Lockman.
>>
>> You can, essentially, assume that nothing more will ever come of it from
>> the official channel. You'd be best to pursue converting another digital
>> source for your own personal use.
>>
>> --Greg
>>
>> On Tue, Feb 21, 2017 at 1:06 PM, Matt Zabojnik  wrote:
>>
>> What's the status on the NASB module? I saw it mentioned in the
>> dictionary message. This is the first I've heard of it, being new to sword
>> devel.
>>
>> I'm currently working to convert NASB with strongs, footnotes and
>> references, but I need to learn OSIS and RegEx better first.
>>
>> Who here is the point-man on tyre work that's already been done there?
>>
>> ___
>> 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
>



-- 
--
PGP ID: 0x5fa5cbaecfd5690c
--
___
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

On Tue, Feb 21, 2017 at 3:59 PM, Matt Zabojnik  wrote:

> The reasons are deep and political. Those who need to know them, already
>> know them.
>
> I appreciate your discretion in  your answer. Conversion difficulties was
> what I was primarily concerned with, so this is, in a sense, good news.
>
> The text is under Copyright by Lockman. Distributing the work would not be
>> legally permitted without obtaining their permission.
>
> Thank you. I have permission.
>

You have permission to distribute an NASB module from Lockman? That's
interesting.


>
> It's important for our own resources to know whence the upstream work was
>> found.
>
> I see. That being the case, there's no reason I wouldn't be able to
> convert a PD work from Zefania XML for example, or any other format I find
> it in, correct?
>

>From a technical perspective, you can convert from any source you can find
into a module for your own use. And from a technical perspective, it's very
easy to host your own module repository - requiring nothing more than an
accessible HTTP serving software.

As for Zefania, I don't believe you'll get much support or encouragement
from these parts surrounding Zefania.

--Greg


>
> Thank you for your ongoing support and information. It is indeed very
> helpful.
>
> Blessings,
> Matt
>
> On Tue, Feb 21, 2017 at 1:50 PM, Greg Hellings 
> wrote:
>
>>
>>
>> On Tue, Feb 21, 2017 at 2:45 PM, Matt Zabojnik  wrote:
>>
>>> Thanks for the info!
>>>
>>> Would you mind explaining in different terms your reason for aborting
>>> the project? I didn't fully understand. Delivering to Lockman wasn't going
>>> to work for some reason?
>>>
>> The reasons are deep and political. Those who need to know them, already
>> know them.
>>
>>
>>> I haven't yet started working on this module, but the intent will be
>>> mass distribution rather than personal use only.
>>>
>> The text is under Copyright by Lockman. Distributing the work would not
>> be legally permitted without obtaining their permission.
>>
>>> Is it common for people to convert stuff for personal use? And how
>>> important is it to declare where I obtained a source text for public domain
>>> materials? I didn't see coverage on either of those in the wiki.
>>>
>> It's important for our own resources to know whence the upstream work was
>> found. This allows repeatable module generation should the upstream source
>> ever be updated and corrected. Very often problems are uncovered in
>> upstream works during the module creation process and this typically
>> continues once the module is in users' hands. The NASB, however, is not a
>> public domain work.
>>
>> --Greg
>>
>>>
>>> On Tue, Feb 21, 2017, 12:15 PM Greg Hellings 
>>> wrote:
>>>
>>> Eons ago, Crosswire received permission from Lockman to begin work on an
>>> NSAB module that they could commercially deliver to users who paid for it.
>>>
>>> Many people have tackled the work of performing the conversions from
>>> Lockman's internal, proprietary markup to a Sword module. Each one has, for
>>> various reasons, abandoned the work. Most recently it was me, and I gave up
>>> due to a lack of a consistent or realistic objective for delivery of the
>>> results to Lockman.
>>>
>>> You can, essentially, assume that nothing more will ever come of it from
>>> the official channel. You'd be best to pursue converting another digital
>>> source for your own personal use.
>>>
>>> --Greg
>>>
>>> On Tue, Feb 21, 2017 at 1:06 PM, Matt Zabojnik 
>>> wrote:
>>>
>>> What's the status on the NASB module? I saw it mentioned in the
>>> dictionary message. This is the first I've heard of it, being new to sword
>>> devel.
>>>
>>> I'm currently working to convert NASB with strongs, footnotes and
>>> references, but I need to learn OSIS and RegEx better first.
>>>
>>> Who here is the point-man on tyre work that's already been done there?
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> --
> PGP ID: 0x5fa5cbaecfd5690c
> --
>
> ___

Re: [sword-devel] GlobalOptionFilter=UTF8GreekAccents and non-Greek modules

2017-02-21 Thread DM Smith

Hypothetical: What about mixed language texts such as a Greek/French lexicon?

DM

> On Feb 21, 2017, at 4:56 PM, Troy A. Griffitts  wrote:
> 
> 
> Simply don't use the UTF-8 Greek Accent filter on non-Greek texts. As you 
> have discovered there are accents used in Greek which are also used in other 
> languages and adverse effects will be seen for these languages. The bottom 
> line is simple. Only use the UTF-8 Greek Accents filter on UTF-8 Greek texts.
> 
> Hope this helps.
> 
> On February 21, 2017 2:45:24 PM MST, David Haslam  
> wrote:
> These are the principal diacritics found in Biblical Greek that have to be
> removed with a UTF8GreekAccents filter.
> 
> The first five are general accents, not particular to Greek.
> It's on account of these that the filter should not be applied to non-Greek
> text.
> 
> U+0300 ̀ COMBINING GRAVE ACCENT
> U+0301 ́ COMBINING ACUTE ACCENT
> U+0308 ̈ COMBINING DIAERESIS
> U+0313 ̓ COMBINING COMMA ABOVE
> U+0314 ̔ COMBINING REVERSED COMMA ABOVE
> U+0342 ͂ COMBINING GREEK PERISPOMENI
> U+0343 ̓ COMBINING GREEK KORONIS
> U+0344 ̈́ COMBINING GREEK DIALYTIKA TONOS
> U+0345 ͅ COMBINING GREEK YPOGEGRAMMENI
> 
> No other diacritics or characters should be removed. 
> Though there are a few more combining accents in this block, they aren't
> really used in Biblical Greek.
> I am open to correction on this point.
> 
> e.g. The right single quotation mark (U+2019) is NOT a diacritic. It should
> not be removed.
> 
> Before any of these accents can be removed, they must first be separated
> from the Greek letters they are combined with. 
> 
> Although normalization to the decomposed form can produce this effect, as we
> have seen already, this can have undesirable side effects on any non-Greek
> text in the module that may happen to include combined or unusual
> characters.
> 
> It would therefore be more sensible to simply use a comprehensive mapping
> table that replaces each possible accented character by the corresponding
> letter in the Greek alphabet. In this way the filter can completely avoid
> the need to apply any Unicode normalization. 
> 
> The complete mapping table would have at least 130 rows. It will need to
> take into account that there are at least 75 possible combinations of a
> letter with two accents. There are none with three.
> 
> Any residual combining characters should also be removed, to cover the
> possibility that a module may have been intentionally made without
> normalizing the Greek source text by default to NFC.
> 
> That's my proposal. I can easily create such a mapping table that
> programmers can use.
> I can also readily test it with a bespoke TextPipe filter.
> 
> 
> Best regards,
> 
> David
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/GlobalOptionFilter-UTF8GreekAccents-and-non-Greek-modules-tp4656719p4656765.html
>  
> 
> Sent from the SWORD Dev mailing list archive at Nabble.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
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
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] Release Wrapup