Re: [sword-devel] Pre-verse div and headings

[DM Smith]

On Jan 21, 2013, at 9:23 AM, "Peter von Kaehne"  wrote:

> 
>> Von: DM Smith 
> 
>> In the past, I've viewed the "headings" toggle as a toggle for
>> non-canonical material. But the discussion on the other thread has me 
>> wondering
>> whether intros (non-canonical) information is handled by it.
>> 
> 
> That is exactly what I said - the headline toggle switches on everything, 
> intros and the like. 
> 
> Now Troy says this is not how it should be and how the engine is handling it, 
> but fact is that it does so. On all modules I have tried out where I know 
> there is intro material.
> 
> Now, my question - is there something very simple we module makers do wrong? 
> Or is there some major and overarching misunderstanding between engine 
> design, osis2mod and module makers?

Here is what osis2mod expects regarding intros and headings.

Intro to the work as a whole: not expected, and not handled.
Intro to a testament: not expected, not handled.
These intros are not ignored, but accumulated for the first write done by 
osis2mod. Hopefully it will be a book intro, but the behavior is not defined.

Intro to a book. This is everything between  and  (or 
, the other chapter start).

Intro to a chapter. This is a bit more difficult. The problem is that it 
occupies the space between a chapter start and verse 1. These may be a chapter 
title, or verse title, or both. Osis2mod uses markup help to distinguish these. 
Here are the rules:
o If the  is within  it is understood as a verse 
title.
o If the  has a type other than main, chapter or sub, it is understood 
as a verse title.
Note, the first of these conditions determines a boundary between chapter and 
verse. If after one of these there is a title that has a type of main, chapter 
or sub. It is understood as belonging to the verse, not the chapter.

That is how the title element is decided.


> 
> FWIW, usfm2osis.pl (and presumably usfm2osis.py) do not produce a verse or 
> chapter 0 div but produce div type intro or something similar.

Note, when the chapter start is seen an inChapterIntro is set. And when one of 
the above is met, then inChapterIntro is cleared and inPreVerse is set.

So, the div type of intro is not directly taken into account.

There is another part to preVerse determination:  whether interVerse material 
falls with verse n (where n >= 1) or verse n+1. (This does not apply to the 
division between chapter start and first verse).

Basically, after the  (or equivalent) is found it looks for start, end 
and empty tags. As long as end and empty tags are found, it is seen as 
belonging to the prior verse. Otherwise it is seen as the next verse. This 
applies to the division between chapter and first verse and to one verse and 
the next. But it does not apply to stuff after the last verse of the chapter 
(such as colophons). That is appended to the last verse.

Hope this helps.

In Him,
DM
___
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] Pre-verse div and headings

[DM Smith]

On Jan 21, 2013, at 10:07 AM, "Troy A. Griffitts"  wrote:

> OK, to clear this up technically.
> 
> setIntros() turns on and off the versification extra 'slots':
> 
> TSTMT BK CH:0 - chapter intro
> TSTMT BK 0:0 - book intro
> TSTMT 0 0:0 - testament intro
> 0 0 0:0 - module intro

As noted, not all these are handled by osis2mod, but only book and chapter 
intros. Someday, I'd like direction to add module and testament intros.

> 
> This has nothing to do with filtering tagged content (In the engine)
> __
> 
> setGlobalOption("Headings", "On"|"Off")
> 
> This will tell the filter set to turn on/off showing anything considered a 
> section heading.  This used to only be pre-verse titles (e.g., "The Sermon On 
> The Mount")-- as DM has pointed out. (Relatively) Recent changes have 
> expanded this to be any content 'pre-verse'-- not just stuff in a  tag.

This is a problem. It should not toggle the entire pre-verse div, but only the 
titles (title element and its content) and other text (presumably 
non-canonical) contained in it. It should not filter the structural tags. The 
filtering of those structural tags is the problem mentioned in the thread 
"Vertical Whitespace."

> 
> I can see conceptually how these can easily get blurred.  It was much easier 
> to see the difference when "Headings" was limited to titles like "The Sermon 
> On The Mount".  I don't like seeing these when I am reading through the text. 
>  They are sometimes like "spoilers" in a movie, e.g., "The Death of King 
> Saul"  I usually turn these off when I am reading.  On the other hand, when I 
> am flipping through my printed Bible, I value these to help orient me to 
> about where I am.  Intros were seen as lengthy book or chapter introductions 
> frequent in printed study Bibles.  Now that "pre-verse" material can be 
> lengthier than simply a section heading, it does blur the lines a little.

I'm still confused. When verse 0 is requested (regardless of what type of intro 
it is), Peter notes that it is affected by the headings render filter. I'm 
pretty sure that the material in it is not marked pre-verse.

It seems to me that verse 0 is always non-canonical and should be toggled by a 
"not canonical" render filter.

> 
> Anyway, just wanted to technical state the difference between the two 
> mechanisms.
> 
> Troy
> 
> 
> 
> 
> 
> On 01/21/2013 03:23 PM, Peter von Kaehne wrote:
>>> Von: DM Smith 
>>> In the past, I've viewed the "headings" toggle as a toggle for
>>> non-canonical material. But the discussion on the other thread has me 
>>> wondering
>>> whether intros (non-canonical) information is handled by it.
>>> 
>> That is exactly what I said - the headline toggle switches on everything, 
>> intros and the like.
>> 
>> Now Troy says this is not how it should be and how the engine is handling 
>> it, but fact is that it does so. On all modules I have tried out where I 
>> know there is intro material.
>> 
>> Now, my question - is there something very simple we module makers do wrong? 
>> Or is there some major and overarching misunderstanding between engine 
>> design, osis2mod and module makers?
>> 
>> FWIW, usfm2osis.pl (and presumably usfm2osis.py) do not produce a verse or 
>> chapter 0 div but produce div type intro or something similar.
>> 
>> 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


___
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] Pre-verse div and headings

[DM Smith]

On Jan 21, 2013, at 12:52 PM, "Troy A. Griffitts"  wrote:

> On 01/21/2013 05:52 PM, DM Smith wrote:
>> On Jan 21, 2013, at 10:07 AM, "Troy A. Griffitts"  
>> wrote:
>> 
>>> OK, to clear this up technically.
>>> 
>>> setIntros() turns on and off the versification extra 'slots':
>>> 
>>> TSTMT BK CH:0 - chapter intro
>>> TSTMT BK 0:0 - book intro
>>> TSTMT 0 0:0 - testament intro
>>> 0 0 0:0 - module intro
>> As noted, not all these are handled by osis2mod, but only book and chapter 
>> intros. Someday, I'd like direction to add module and testament intros.
>> 
>>> This has nothing to do with filtering tagged content (In the engine)
>>> __
>>> 
>>> setGlobalOption("Headings", "On"|"Off")

Well, Karl's post clears up why this works. From my best recollection the 
material in verse 0 is not marked as pre-verse. The headings filter does not 
filter verse 0. So the app has to.

>>> 
>>> This will tell the filter set to turn on/off showing anything considered a 
>>> section heading.  This used to only be pre-verse titles (e.g., "The Sermon 
>>> On The Mount")-- as DM has pointed out. (Relatively) Recent changes have 
>>> expanded this to be any content 'pre-verse'-- not just stuff in a  
>>> tag.
>> This is a problem. It should not toggle the entire pre-verse div, but only 
>> the titles (title element and its content) and other text (presumably 
>> non-canonical) contained in it. It should not filter the structural tags. 
>> The filtering of those structural tags is the problem mentioned in the 
>> thread "Vertical Whitespace."
> 
> What do you envision in the inter-verse material which should be displayed?  
> Newlines?

Yes. Exactly. In the "Vertical Whitespace" post, I outlined how they should be 
displayed.

>  Is this the only thing that prevents toggling preverse material based on the 
> "Headings" option?

I'm not sure what you mean by "prevents." I think that for Bibles, the only 
text between verses that should be displayed regardless of the toggle are 
titles marked canonical="true".

But I don't mind if titles and introductory material is handled by cooperating 
toggles.


> 
> I'm not arguing one way or another (yet).  I'm just interested. The previous 
> "purpose" for the "preverse" material concept was to isolate material which 
> should be shown when a verse is being viewed in context, but which needs to 
> be shown before the verse marker. There are many use cases for this need.  
> One is:
> 
> When the verse is being shown stand-along (e.g., in a search results list) 
> this material is (typically) not shown by a frontend.

Right.

The corollary of this is when verses are shown one per line. This is asking for 
much of the structural formatting to be ignored. Not sure how much should be 
kept.


> 
> Another is:
> 
> Many users which to turn this material off when reading in context.

Yes. Part of the context is paragraphing. Part of the context is proper 
indentation of poetry (or what has been formatted as such). Most paragraphing 
and poetry markup is between verses.

> 
> Until recently, the only thing in this space was section headings., so 
> turning on and off pre-verse material based on section headings made sense.

Right.

> 
> What kinds of things would you still want to be shown when sections headings 
> are turned off?

New lines and also indents (for poetry based on the level (?) attribute.) So 
both vertical and horizontal whitespace.

Again, I don't mind if intros are handled independently from titles.

> 
>>> I can see conceptually how these can easily get blurred.  It was much 
>>> easier to see the difference when "Headings" was limited to titles like 
>>> "The Sermon On The Mount".  I don't like seeing these when I am reading 
>>> through the text.  They are sometimes like "spoilers" in a movie, e.g., 
>>> "The Death of King Saul"  I usually turn these off when I am reading.  On 
>>> the other hand, when I am flipping through my printed Bible, I value these 
>>> to help orient me to about where I am.  Intros were seen as lengthy book or 
>>> chapter introductions frequent in printed study Bibles.  Now that 
>>> "pre-verse" material can be lengthier than simply a section heading, it 
>>> does blur the lines a little.
>> I'm still confused. When verse 0 is requested (regardless of what type of 
>&

Re: [sword-devel] Location of prebuilt lucene indexes.

[DM Smith]

On Jan 23, 2013, at 11:02 AM, "Peter von Kaehne"  wrote:

> 
>> Von: Andrew Thule 
> 
>> The nice thing about when
>> repo administrators do this, is when you get a module from that repo, you
>> also automatically get the lucene index. 
> 
> The reason that this is not done are manifold - including that sword and 
> jsword indices are different, that not all platforms have the same 
> lucene/clucene incarnation etc.
> 
> Most users are better off not to use downloaded indices, but to create 
> indices suitable for their specific frontend. 

To add to what Peter said, this mailing list's archives have extensive 
discussion on why we don't do this and why we have done it for mobile devices 
(only PocketSword and AndBible, and specific to them only).

Also, the transfer time for a lucene index exceeds the time of a recent 
computer to build them, e.g. my laptop. As a Bible Desktop user, I'd really 
rather not transfer an index that is unusable by Bible Desktop.

In Him,
DM


___
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] Location of prebuilt lucene indexes.

[DM Smith]

The repo admin needs to decide what is best for all users of the repo.

For example, they cannot assume that Xiphos (to pick out one SWORD application) 
is the same version for every user. And even if it is the same version, they 
cannot assume that lucene is the same. So, having the indexes in a public repo 
is a bad idea. In a private repo, it doesn't matter.

To repeat earlier threads of what can cause indices to become invalid:
New version of Unicode. For JSword, this is based upon the version of Java. A 
Java upgrade requires indices to be rebuilt. (Note: JSword and SWORD cannot 
share indices.) For Windows, I think it is part of the OS. If so XP, Vista, Win 
7 and Win 8 clients may have different Unicode. The same idea applies to Linux.

To the extent that ICU is used to provide Unicode, the same applies. The app 
can be compiled w or w/o ICU.

The version of the SWORD lib has to be the same.

The version of Lucene has to be the same.

There is no mechanism in SWORD or JSword to know when an index is not valid and 
in need of being rebuilt.

Short of an application having tight control over the index (such as 
PocketSword, AndBible and STEP) it does not make sense to have indices stored 
in the repo. Even then, the indices should be stored in parallel, not with the 
module.

The only reason I see to have it otherwise is if the repo is private and 
personal.

Hope this clarifies.

In Him,
DM


On Jan 23, 2013, at 12:52 PM, Andrew Thule  wrote:

> Peter, DM, Thanks for your response.  I wasn't being critical and I agree.  
> There are Pros and Cons either way (resource usage and download time being 
> considerations) as you point out.
> 
> I also agree it's ultimately it's up to the repo administrator and the user, 
> to decide for themselves what works best for them.  I happen to like having 
> the index included as part of the repo, because I'm not limited by resources, 
> and I don't mind the wait.
> 
> Regardless, it is still a matter of preference (based upon considerations, 
> such as the ones you cite).
> ~A
> 
> On Wednesday, January 23, 2013, DM Smith wrote:
> 
> On Jan 23, 2013, at 11:02 AM, "Peter von Kaehne"  wrote:
> 
> >
> >> Von: Andrew Thule 
> >
> >> The nice thing about when
> >> repo administrators do this, is when you get a module from that repo, you
> >> also automatically get the lucene index.
> >
> > The reason that this is not done are manifold - including that sword and 
> > jsword indices are different, that not all platforms have the same 
> > lucene/clucene incarnation etc.
> >
> > Most users are better off not to use downloaded indices, but to create 
> > indices suitable for their specific frontend.
> 
> To add to what Peter said, this mailing list's archives have extensive 
> discussion on why we don't do this and why we have done it for mobile devices 
> (only PocketSword and AndBible, and specific to them only).
> 
> Also, the transfer time for a lucene index exceeds the time of a recent 
> computer to build them, e.g. my laptop. As a Bible Desktop user, I'd really 
> rather not transfer an index that is unusable by Bible Desktop.
> 
> In Him,
> DM
> 
> 
> ___
> 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] OSIS questions

[DM Smith]

Others should chime in too. This just a partial answer.

Basic overview:
OSIS should be written to the OSIS specification. We recommend a document 
centric representation where Book, Chapter, Section, Paragraph, Line Group and 
Lines are dominant and verse elements are milestoned.
This is transformed by osis2mod into Book, Chapter, Verse representation.
Front-ends then use a SWORD renderer to transform module content into 
presentational output. This is driven by values in a module's conf.

So questions regarding OSIS fall into:
How should it be done in OSIS.
How does osis2mod handle it.
And how do SWORD renderers handle such and so content.

On Jan 26, 2013, at 10:13 AM,  wrote:

> I'm trying to convert a number of USFM documents to OSIS using my own
> software, and then to Sword using osis2mod.  However, I'm relatively new to
> OSIS, and am struggling somewhat.  Don't know if anyone can comment on any
> of the following issues?

Peter and Chris maintain a converter for USFM to OSIS, written in Perl. You 
might find that helpful. Off hand I don't know where that is. You can get more 
information by searching this list or from them.

Also, Kahunapule Michael Johnson on this list has converters that he uses. He 
has many, many texts in USFM.

> 
> * : "Normalized name of the Bible
> version (Usually 3 letters for language, 3 for translation)".  Does this
> have any significance to anything (ie does it matter that I get it "right")?
> If so, I assume the first three characters are the ISO language code?  What
> should you do where you also have a variant code?  Does the "translation"
> portion of the name need to follow any particular convention?


The documentation that we've provided relates to an OSIS document used as a 
source for a SWORD module. Most of our answers will also be SWORD centric.

To SWORD, the value does not matter. Osis2mod strips out everything until the 
first meaningful  element. At some time in the future, osis2mod will 
examine the header info to provide a best guess for key conf elements.


> 
> * According to http://crosswire.org/wiki/OSIS_Bibles, the minimal
> document header consists of just .  This does not
> seem at first sight to square with Appendix L of the OSIS user manual
> (dealing with conformance requirements), which appears to require a scope
> definition, to which the document must conform.  Is the minimal header shown
> above in fact adequate?  And what do you lose by not giving a fuller header
> (for example, by not giving "scope")?

In a SWORD context, you lose nothing. At least until we improve osis2mod to 
suggest a conf. But it is a great place to document information that will be 
helpful to you or others later.

> 
> * An example text I have picked up includes the refSystem tag in a
> number of places.  I'd prefer to avoid using this if I can, since it is not
> always immediately apparent what versification schemes have been used in the
> texts I have available to me.  Is it a problem if the tag is not supplied?
> (If it must be supplied, then I presume it has to come from some predefined
> list of valid schemes?  Where do you get the details of these schemes?)
> 

Reference systems are rather bothersome. Your goal is to determine the best fit 
of those that SWORD provides. IIRC, Greg has put together a script that'll help 
figure out which reference system (which osis2mod refers to as a 
"versification" system) is most encompassing.

Osis2mod is good in that it retains all verse material. But when you pick the 
wrong ref system, osis2mod will warn you that the verse is not in the 
versification and that it is being appended to the prior verse.

The details are rather cryptic (held in arrays in SWORD header files.) 
Basically most of us just try each one to see which has the least warnings. And 
from there try to understand those warnings.

Chris has defined these. So he might be able to clarify.

> * http://crosswire.org/wiki/OSIS_Bibles includes  type="bookGroup">.  I presume this enables you to group together, say OT or
> NT books?  What are the implications of having it (or of not having it)?

It is not needed for a SWORD module. All that osis2mod requires are the 

Having it has no impact.

> 
> * OSIS appears to support a tableOfContents marker, which I believe
> corresponds to USFM toc/toc1/toc2/toc3.  How is it used?  Suppose I have the
> text for Matthew, and somewhere else I want a table of contents.  Does the
> marker go at the start of Matthew itself, to mark the place to which the
> table of contents should point?  Or does it go into the table of contents,
> to indicate that you want it to include a reference to Matthew?  And either
> way what does the full tableOfContents tag look like?  (I tried the former
> of the two options - putting Matthew into
> Matthew itself, but the only effect seemed to be that the word Matthew was
> output as part of the text.)

I don't know the answer to this specifically (how to encode it properl

Re: [sword-devel] BibleCS 1.7.0RC1

[DM Smith]

I doubt it is there. The location differs between Linux, Windows and Mac. It is 
not easy to document for Windows as the variable is not on all versions that 
SWORD/JSword runs on (Bible Desktop still runs on Windows 98). Even when I've 
tried to explain it to a user, it is confusing.
In Him,
DM

On Jan 29, 2013, at 9:27 AM, David Haslam  wrote:

> Did we document this in the wiki ?
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/BibleCS-1-7-0RC1-tp4651850p4651864.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] StrongsPadding

[DM Smith]

JSword never had this problem. It has been well ahead of SWORD for many years 
(on this).

As a reminder, JSword is not a port of SWORD. It is an independent 
implementation. As such, how it handles Strong's numbers is entirely different.

On occasion, JSword differs from SWORD in a way that can only be characterized 
as a bug.

Regarding features, JSword follows SWORD. 

In Him,
        DM Smith

On Feb 1, 2013, at 5:03 AM, David Haslam  wrote:

> I also added a further note:
> 
> # This is only available in SWORD version 1.7 or later. JSword will need to
> catch up later. 
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/StrongsPadding-tp4651872p4651874.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] Small Fix for Mark 9:43 in KJV module

[DM Smith]

Thank you very much.

I think that perhaps 4 and 7 need to be swapped. Isn't the Greek "hand of you" 
so that would be (7), (5 6)?

Also, I think that the definite article 19 binds to 21 and 30 to 31.

I've made these changes, putting your initials on the verse, and you can get a 
current copy of the xml at:
www.crosswire.org/~dmsmith/kjv2006/sword/2011/kjv-osis.zip
In the same directory, you'll find different updates that are suffixed with the 
date and time of a set of changes.

You'll also find that there are many other changes.

In His Service,
DM Smith

On Feb 1, 2013, at 5:38 AM, Vladimir Támara Patiño  
wrote:

> Dear Friends,
> 
> Mark 9:43 in the KJV module does not have associated the Strong concordance 
> with the words of the verse, a proposal here:
> 
> $$$Mark 9:43
> 
> And
> if
> thy
> hand
> offend
> thee,
>  type="x-split">cut
> it
> off:
> it is
> better
> for thee
> to enter
> into
> life
> maimed
> than
> having
> 
> two
> hands
> to go
> into
> hell
> into
> the fire
> 
> that
> never shall be
> quenched
> 
> 
> God bless
> -- 
> Dios, gracias por tu amor infinito.
> --   Vladimir Támara Patiño.  http://vtamara.pasosdeJesus.org/
> http://www.pasosdejesus.org/dominio_publico_colombia.html
> 
> 
> ___
> 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] Small Fix for Mark 9:43 in KJV module

[DM Smith]

Yes, there are "slightly less obvious" problems!

I've been working diligently on the KJV for the last few weeks. 

I went through and updated all verses with 4 or more empty Strong's Numbers.

I also got the TR that was used in the 2003 effort and used it to identify 
those verses that had a variant in the TR. I then proofread and updated if 
necessary those verses. There were two different kinds of variants:
a) variant differences between Stephens and Scrivener. This caused two 
problems: 1) improper src numbering and 2) improper tagging.
b) variant differences for a Strong's Number and/or Robinson's Morphological 
codes. These caused many extra words in the verse (improper src numbering) and 
confusion for the taggers.

Variants cause a problem with src= numbering. In the KJV, for each variant, it 
uses either the Stephens variant or the Scrivener variant. There are several 
different types of Stephens/Scrivener variants:
a) Stephens and Scrivener have the same number of words.
b) Stephens has text that is not in Scrivener.
c) Scrivener has text that is not in Stephens.
d) Stephens and Scrivener have phrases of different lengths.
There is no problem with the first, but obvious problems from the variant 
(inclusive) to the end of the verse.
Having figured out which variant was used, I adjusted the src= values in the 
KJV to match.

Here is what I have left:
-- There are a few verses where the Greek is in another (adjacent) verse than 
the English. Need to figure out a way to mark these up. Here are those verses:
Rom.1.3-4
Rom.1.9-10
Rom.3.25-26
2Cor.1.6-7
2Cor.8.14
2Pet.1.1-2

I'm thinking of using src="Xp" (for the x-th Greek word in the previous verse) 
or src="Xn" (for the x-th Greek word in the next verse).

In all but one case, the Greek is at the end of one and the English at the 
beginning of the other (or visa versa). From what I understand, this is merely 
a difference in versification, not in what verses there are, but where the 
boundaries are.

In that other case, a phrase is pulled out of the middle of one verse and put 
into the middle of the other (the two verses form one sentence. So it makes 
sense.)

-- There are many verses (thousands) that have 1-3 empty tags (I've addressed 
all those with 4 or more). For the most part, the biggest problem with these is 
where they are located. Many times they are unordered and at an end of the 
verse. It'd be better for them to be placed within the verse based on the 
src="N" attribute.

-- Update the KJV with the most recent version of the TR.
Interestingly, the Strong's numbers in it don't match the Strong's Concordance 
for the same verses. This is mostly with the tagging of the definite article. 
The most recent version seems to address all the variant differences for 
Strong's Numbers and Robinson's Morphological codes.

-- Noting which variants are used with   
. Right now I have it documented in a separate document. You can get it 
in the same directory as above, where it is called variants.zip
There are several columns, The first is the verse, the second is the variant, 
the third has a + for the variant that is used by the KJV, the fourth is the 
source of the variant and the last is the content of the variant.


Input welcomed.

Together in His Service,
DM


On Feb 1, 2013, at 7:50 AM, Ben Morgan  wrote:

> I reported this nearly 4 years ago: 
> http://www.crosswire.org/tracker/browse/MOD-76
> There are some other verses which are slightly less obvious as well.
> 
> God Bless,
> Ben
> -
> For I have no pleasure in the death of anyone, 
> declares the Lord God; so turn, and live.”
> Ezekiel 18:32 (ESV)
> 
> 
> 
> On Fri, Feb 1, 2013 at 11:34 PM, David Haslam  wrote:
> Noted in http://crosswire.org/wiki/User:Dmsmith/KJV2011#Omissions
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Vertical-whitespace-tp4651708p4651879.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

___
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] poetry formatting (was Re: Vertical whitespace)

[DM Smith]

 0.5em 0em 0.5em 3em;
>> }
>> 
>> /* We want our indented lines to behave nicely - wrapped lines should be
>>  * indented further. text-indent undoes the wide margin only for the first
>>  * line */
>> div.indentedline.width-2 {
>>  -moz-padding-start: 5em;
>>  text-indent: -3em;
>> }
>> div.indentedline.width-4 {
>>  -moz-padding-start: 5em;
>>  text-indent: -1em;
>> }
>> div.indentedline.width-6 {
>>  -moz-padding-start: 7em;
>>  text-indent: -1em;
>> }
>> 
>> div.indentedline.width-0 {
>>  -moz-padding-start: 5em;
>>  text-indent: -5em;
>> }
>> 
>> God Bless,
>> Ben
>> -
>> For I have no pleasure in the death of anyone, 
>> declares the Lord God; so turn, and live.”
>> Ezekiel 18:32 (ESV)
>> 
>> 
>> 
>> On Fri, Feb 1, 2013 at 9:32 PM, Nic Carter  wrote:
>> 
>> Is this caused by improperly formed modules that have fun with  poetry & 
>>  ?
>> [I think I have already emailed through what I do after the filter gives me 
>> it's result in order to try to reduce the vertical whitespace!]
>> 
>> And while I'm on the topic of poetry, in Proverbs you often see couplets 
>> (altho are they termed that in the Bible?) where in a printed Bible the 2nd 
>> line is indented. Would we be able to do that to some degree? I don't know 
>> the OSIS tags that refer to this, but if someone were able to point me in 
>> the right direction, I may even be able to hack this together myself? I am 
>> looking around line 360 of osishtmlhref.cpp
>> 
>> On 20/01/2013, at 8:12 AM, DM Smith  wrote:
>> 
>> > I've noticed that OSIS modules sometimes render with a lot of vertical 
>> > whitespace (blank lines).
>> >
>> > I'd like for this to be sorted as part of the next release. I don't think 
>> > it'd be too hard. I've been in the osishtmlhref filter to see if I could 
>> > figure it out, but it is beyond me.
>> >
>> > So this is a suggestion for others.
>> >
>> > Using the HTML notion of block and inline elements, I think we can 
>> > classify OSIS elements as block or inline. Off the top of my head, , 
>> > , , , , , ,  and  are the block 
>> > elements.
>> > The key feature of a block element is that block elements that follow each 
>> > other stack one on top of each other.
>> > Some block elements allow nesting, such as .
>> >
>> > In HTML, an empty  occupies no vertical space. A nested div does not 
>> > cause additional vertical space.
>> >
>> > In HTML, a  has semantics as to whether it is preceded or followed by 
>> > whitespace. A  at the beginning of a document is not preceded by a 
>> > blank line. Nor is a  at the end of a document. This is also true 
>> > after a heading element.
>> >
>> > I think that the SWORD renderers always cause a  to occupy vertical 
>> > whitespace.
>> >
>> > The other issue with  is that we now have a "pre-verse" div, which is 
>> > a great way of marking off what stands before a verse, but this  
>> > really shouldn't have any  semantic. It probably would have been 
>> > better if we used  instead.
>> >
>> > I seem to remember that there is a "swollow" flag for whitespace (I think 
>> > it might be for horizontal whitespace.) I think something like this could 
>> > be used for vertical whitespace.
>> >
>> > The other part to this is when a chapter is shown verse-per-line. If 
>> > because of rendering the pre-verse content the verse already starts on a 
>> > new line, I don't think more vertical whitespace should be produced.
>> >
>> >
>> > Together in His Service,
>> >   DM
>> > ___
>> > sword-devel mailing list: sword-devel@crosswire.org
>> > http://www.crosswire.org/mailman/listinfo/sword-devel
>> > Instructions to unsubscribe/change your settings at above page
>> 
>> 
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>> 
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] KJV Update

[DM Smith]

I have an update for the KJV here:
http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/kjv.zip

Basic details:
Splits: (Indicate Greek translated into an English phrase that is interrupted 
by the translation of another Greek word or added text.)
In the Greek, the mechanism for denoting splits have changed. In the past the 
type and subType attributes were used to indicate this with type="x-split" and 
subType="x-NN", where NN was unique to the verse. It was on one part of the 
split and not the other. Sometimes the first part, and sometimes the other. 
There were several problems with this. First, it was inconvenient to have it 
only on one part. To use it one had to use the src attribute to find the other 
part. SwordWeb in fact ignored it and just used the src attribute. Now, the 
type and subType attributes are merged into the type attribute. The form is now 
type="x-split-NN" where NN is a globally unique number identifying the split. 
And now it is on all parts of the split. 

In the Hebrew there were references to the Strong's Number H00. These indicated 
a split. These have been replaced with the above notation for splits. No sense 
in having two different mechanism.

Clean up of Strong's Numbers and Robinson Morphological Codes.
There were many verses that had many words in the Greek that were not attached 
to English text. All verses having 4 or more have been updated. Many of the 
other verse were updated as well.

There were some that had Strong's Numbers but no Robinson. These have been all 
updated.

There were many verses that had extraneous Greek. This was an artifact of the 
Greek text that was used for the KJV2003 effort. These have been deleted.

There are about 400 verses having variants in the Greek. These verses have been 
compared and fixed up as needed.

I've added in the Greek from the TR, it is in the lemma attribute, prefixed by 
tr: When there are more than one Strong's Number, there is more than one TR 
word. The first Strong's number pairs with the first TR word, the second with 
the second and so forth. The SWORD and JSword engine has no special ability 
regarding this. That may come. 

I would appreciate feedback. 

In His Service,
DM
___
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] Poetry, verse 0, setIntros() and the state of things thus.

[DM Smith]

A bit more on osis2mod and .

Osis2mod takes valid OSIS and transforms BSP (Book/Section/Paragraph) into BCV 
(Book/Chapter/Verse) it so that it will will have valid xml fragments for every 
verse, when wrapped with a  element.

In the transformation, each element which can cross verse boundaries (start or 
end in a verse but not both) into a milestoned element that is syntatically 
valid OSIS. However, this does guarantee that the element in context is valid.

This is the case for  as it is transformed from it's container form to its 
milestoned form. The  elements, whether milestoned or not are not allowed 
anywhere but in an  element. This is a bug in the OSIS spec. Either the 
 element has to change to not be milestoned or the container elements for 
 have to be modified to allow  (as has been done with . I think the 
latter.

Ben's "hack" is a proper observation.  should have as little presentation 
tied to it as possible. What you are attempting is necessary. Always assume 
that every  is in an .

So the ESV, when presented to osis2mod was valid BSP OSIS. Note that in a few 
instances, the  is not in the same chapter.

The problem with "stuff" being put into verse 0 (aka intros) is that the 
everything before the first verse in a chapter is put into the chapter intro 
until osis2mod sees something that indicates that the intro is done and the 
rest of the "stuff" goes with the verse. (This is documented in the wiki and in 
the code and I've mentioned it in detail here also.) But suffice it to say, the 
simple solution is to add  around groups of verses. That 
will divide what is before it for the intro and what is after it for verse 1.

Hope this helps,
DM

On Feb 5, 2013, at 6:49 AM, Nic Carter  wrote:

> 
> Well, as far as I'm aware, I have the ESV poetry 100% correct in PS now. And 
> given I use either the ESV or the KJV in PS & the KJV doesn't do indentation, 
> PS does poetry 100% correct for _me_ ;)
> 
> So I'm going to leave it at that, and get on with other stuff. :)
> 
> Which reminds me, if anyone else is interested in beta testing PocketSword, 
> please shoot me a private email, as it's been so long since I did beta 
> testing for it that half of my beta testers have other commitments now & can 
> no longer help out.  :)
> 
> 
> Thanks, ybic
>   nic...  :)
> 
> ps: Thanks for your help Ben! I agree, that having some way of keeping track 
> of which tags are currently open would be great. I was going to hack together 
> some stuff, such as the ability to create your own userData stuff & pass that 
> through to the filters, but I doubt that that would be accepted into SVN & so 
> I coded my stuff in Objective-C instead, meaning it'll only work in PS & 
> Eloquent/MacSword. :)
> 
> pps: in my delvings into SWORD I noticed a few comments regarding binary 
> compat with 1.6.x and I was wondering if those were going to be cleared up 
> before 1.7.0 was going to be released?
> 
> On 05/02/2013, at 9:57 PM, Ben Morgan  wrote:
> 
>> Yep, there are lots of inconsistencies. Hopefully over time with more 
>> support they will tend to go away.
>> 
>> Just to be clear with the ESV, I doubt it is incorrectly encoded. It's just 
>> it's not encoded in a way that greatly helps per-chapter rendering (or even 
>> per-verse) rendering. Especially the presence of per-verse rendering (e.g. 
>> in a list of cross-references) means that you have to be able dispense with 
>> s and infer them from the  (side note: it would be nice if SWORD 
>> provided some way of keeping track of what tags are open at which verses so 
>> partial renders will work (e.g. for  - Words of Jesus, , paragraphs, 
>> etc.))
>> 
>> When I looked recently, the WEB was encoded in such a way that I found I 
>> didn't have the time to make it work properly, mostly due to the  being 
>> at the end of the previous verse - I believe due to issues with osis2mod as 
>> previously discussed. I still think this needs fixing. 
>> I think they should definitely be tied to the verse they start at.
>> 
>> God Bless,
>> Ben
>> -
>> For I have no pleasure in the death of anyone, 
>> declares the Lord God; so turn, and live.”
>> Ezekiel 18:32 (ESV)
>> 
>> 
>> 
>> On Tue, Feb 5, 2013 at 9:33 PM, Nic Carter  wrote:
>> 
>> Hi gang,
>> 
>> I just wanted to touch base with where I'm at with the poetry stuff.
>> 
>> Taking Ben's code as a guide, I've ported it across to SWORD and it's kinda 
>> working. You can see my current version on bit bucket.
>> 
>> Note that this current version is very similar to the patch I sent through a 
>> few days ago, but I'm going to suggest that we don't implement this in SWORD 
>> just yet.
>> 
>> The reason being that I have discovered that we need to incorporate Ben's 
>> hack to work around the fact that modules may not be properly formed OSIS & 
>> may contain s outside of s. This then simply makes things look messy 
>> and so I have had to write more co

Re: [sword-devel] KJV Update

[DM Smith]

Thanks. It was commented out in the source. Uncovered another bug. Perhaps in 
osis2mod.
In Him,
DM
On Feb 6, 2013, at 7:26 AM, David Haslam  wrote:

> DM requested feedback. Happy to oblige. There's an error!
> 
> *Matthew 11:8-23* is missing from version 2.5 of the updated KJV module that
> DM announced.
> 
> I just ran the emptyvss utility and got this output.
> 
> Matthew 11:8
> Matthew 11:9
> Matthew 11:10
> Matthew 11:11
> Matthew 11:12
> Matthew 11:13
> Matthew 11:14
> Matthew 11:15
> Matthew 11:16
> Matthew 11:17
> Matthew 11:18
> Matthew 11:19
> Matthew 11:20
> Matthew 11:21
> Matthew 11:22
> Matthew 11:23
> 
> =
> 
> Confirmed by displaying this chapter in Xiphos.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/KJV-Update-tp4651895p4651903.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

[sword-devel] Compressing a module

[DM Smith]

I'm having problems with compressing a module. I'm trying to use zip 
compression at the book level. I've tried it on the CrossWire server using 
osis2mod and mod2zmod, freshly built from source. In both cases, when I get the 
module it is corrupt.

The file is http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/kjv.zip. In 
there you'll also find the raw text as av.zip, which is just fine.

Is there a bug in the code? A problem with the server? With transmission to my 
computer? 

Help would be appreciated!

In Him,
DM
___
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] Compressing a module

[DM Smith]

Never mind. My conf was wrong. Had no CompressType=ZIP.

On Feb 6, 2013, at 4:35 PM, DM Smith  wrote:

> I'm having problems with compressing a module. I'm trying to use zip 
> compression at the book level. I've tried it on the CrossWire server using 
> osis2mod and mod2zmod, freshly built from source. In both cases, when I get 
> the module it is corrupt.
> 
> The file is http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/kjv.zip. In 
> there you'll also find the raw text as av.zip, which is just fine.
> 
> Is there a bug in the code? A problem with the server? With transmission to 
> my computer? 
> 
> Help would be appreciated!
> 
> In Him,
>   DM
> ___
> 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] Strong tagging and Septuagint

[DM Smith]

In SWORD the various GlobalOptionFilter values indicate to the SWORD engine 
which pieces of code (filters) to enable. Same with some other entries in the 
conf.

In JSword, we don't have a filter architecture. We convert everything from the 
source type (ThML, Plaintext, GBF, ...) to OSIS. Then we use xslt to transform 
that into HTML. The xslt is passed what the user would like to see or not see. 
It doesn't really matter (so far) what is set in the module's conf.

This has one problem. Regarding Headings (aka Titles). They should always show 
in a commentary, as they should all be assumed to be canonical (properly part 
of the module) unless marked non-canonical.

Hope this clarifies.

In Him,
DM


On Feb 8, 2013, at 11:00 AM, Chris Burrell  wrote:

> Perhaps in Sword-terms a property isn't a statement of what's there, however 
> JSword does seem to read it and give the front-end information about whether 
> an option is available in the module or not...
> 
> Maybe I misunderstand something?
> 
> Chris
> 
> 
> 
> On 8 February 2013 15:12, David Haslam  wrote:
> Our three Finnish modules do not have Strong's numbers.
> 
> The conf files do not include GlobalOptionFilter=OSISStrongs, yet the
> pseudo-markup in the source text files
> (from an /ad hoc/ workaround to provide the original verse references from
> an Av11n translation)
> get interpreted as if they were Strongs!!!
> 
> The engine still parses the text, and displays these tags, despite the fact
> that they can't be hidden by a filter.
> 
> A filter property in a conf file is just that! It tells the engine what to
> do when asked.
> It's not a statement about what's there.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Strong-tagging-and-Septuagint-tp4651344p4651916.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

___
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] OSIS Variants

[DM Smith]

The form in Byz and WHNU are what we've settled on for OSIS.

If we find something else in an OSIS module, then we probably should log it in 
Jira.

In Him,
DM

On Feb 8, 2013, at 1:09 PM, Chris Burrell  wrote:

> Hi
> 
> Is there are standard subType pattern that modules are supposed to follow?
> 
> It seems Byz and WHNU are using x- where n is the variant number. 
> 
> αχας | αχαζ | 881 {N-PRI} | αχας
> αχαζ
> 
> 
> I'm seeing some code taken originally from BibleDesktop which suggests 
> subType can be x-class-1 ?
> 
> A post on the sword list 
> (http://sword-dev.350566.n4.nabble.com/OSIS-variants-td1009209.html) 
> suggests, there is also a third subtly different form:
> 
> (i.e. a colon separating "class" from the number.
> 
> Is one more appropriate than the other form? Does a UI have to cater for all 
> possible forms of subtypes? Is there a page somewhere listing the mutlitple 
> forms this can take?
> Chris
> 
> ___
> 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] Strong tagging and Septuagint

[DM Smith]

For OSIS, the only values to indicate Strong's Numbers are:
GlobalOptionFilter=OSISStrongs
and
Feature=StrongsNumbers

There is nothing defined to further distinguish.

BTW, what is extended Greek? Are you referring to the TVM codes that look like 
Strong's Number with a G prefix?

I guess what we need is to understand how you'd use the knowledge in a program.

In Him,
DM

On Feb 8, 2013, at 3:15 PM, Chris Burrell  wrote:

> Thanks, that does clarify. Still the problem remains in that we want to be 
> able to distinguish between different types of tagging (greek, hebrew, 
> extended greek) by questioning the module. Does the conf file not also define 
> supported features? Can we not make it so? Or have a flag in there to 
> indicate the Strongs tagging is abnormal/Septuagint (i.e. Greek tags in the 
> OT)
> 
> Chris
> 
> 
> 
> On 8 February 2013 20:11, DM Smith  wrote:
> In SWORD the various GlobalOptionFilter values indicate to the SWORD engine 
> which pieces of code (filters) to enable. Same with some other entries in the 
> conf.
> 
> In JSword, we don't have a filter architecture. We convert everything from 
> the source type (ThML, Plaintext, GBF, ...) to OSIS. Then we use xslt to 
> transform that into HTML. The xslt is passed what the user would like to see 
> or not see. It doesn't really matter (so far) what is set in the module's 
> conf.
> 
> This has one problem. Regarding Headings (aka Titles). They should always 
> show in a commentary, as they should all be assumed to be canonical (properly 
> part of the module) unless marked non-canonical.
> 
> Hope this clarifies.
> 
> In Him,
>   DM
> 
> 
> On Feb 8, 2013, at 11:00 AM, Chris Burrell  wrote:
> 
>> Perhaps in Sword-terms a property isn't a statement of what's there, however 
>> JSword does seem to read it and give the front-end information about whether 
>> an option is available in the module or not...
>> 
>> Maybe I misunderstand something?
>> 
>> Chris
>> 
>> 
>> 
>> On 8 February 2013 15:12, David Haslam  wrote:
>> Our three Finnish modules do not have Strong's numbers.
>> 
>> The conf files do not include GlobalOptionFilter=OSISStrongs, yet the
>> pseudo-markup in the source text files
>> (from an /ad hoc/ workaround to provide the original verse references from
>> an Av11n translation)
>> get interpreted as if they were Strongs!!!
>> 
>> The engine still parses the text, and displays these tags, despite the fact
>> that they can't be hidden by a filter.
>> 
>> A filter property in a conf file is just that! It tells the engine what to
>> do when asked.
>> It's not a statement about what's there.
>> 
>> David
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://sword-dev.350566.n4.nabble.com/Strong-tagging-and-Septuagint-tp4651344p4651916.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
> 
> 

___
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] OSIS Variants

[DM Smith]

I noticed this a few weeks ago. We should change JSword's ThML converter to 
output OSIS as is used in Byz and WHNU. And the xslt to handle it.

When I did the original, there were not any variants in an OSIS text.

In Him,
DM
On Feb 8, 2013, at 1:09 PM, Chris Burrell  wrote:

> Hi
> 
> Is there are standard subType pattern that modules are supposed to follow?
> 
> It seems Byz and WHNU are using x- where n is the variant number. 
> 
> αχας | αχαζ | 881 {N-PRI} | αχας
> αχαζ
> 
> 
> I'm seeing some code taken originally from BibleDesktop which suggests 
> subType can be x-class-1 ?
> 
> A post on the sword list 
> (http://sword-dev.350566.n4.nabble.com/OSIS-variants-td1009209.html) 
> suggests, there is also a third subtly different form:
> 
> (i.e. a colon separating "class" from the number.
> 
> Is one more appropriate than the other form? Does a UI have to cater for all 
> possible forms of subtypes? Is there a page somewhere listing the mutlitple 
> forms this can take?
> Chris
> 
> ___
> 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] support for locale codes with region/script subtags

[DM Smith]

Chris,
We've got this in JSword (not sure it works) for  a while now for the next 
release. We used the codes as you've given here. But in the conf file you have 
ur_Deva. We're not expecting an _ but a -. We can change the code. Please 
advise.

In Him,
DM

On Feb 10, 2013, at 5:56 AM, Chris Little  wrote:

> Just a quick heads up:
> 
> In general, locale codes (the Lang= field of .confs) can have subtags that 
> indicate region, script, etc. Ideally these should be dealt with in some 
> fashion by front ends since they identify important distinctions (in the eyes 
> of the module maker or publisher at least).
> 
> When unknown subtags are encountered, it's probably best to recursively fall 
> back to the tag minus its right-most subtag. For example, if 'en-Latn-US' is 
> unknown, fall back to 'en-Latn'. If that is unknown, fall back to 'en'. 
> (Hopefully nearly all language subtags are known.)
> 
> We should handle this in the library, but currently don't. :(
> 
> 
> As a specific case in point:
> We now have two Urdu translations. They're the same translation and differ in 
> their script (one is Arabic, the other Devanagari). Their language codes (as 
> of the 1.2.1 release just made, which corrected the code for the Devanagari 
> version) are: ur (Urdu in Arabic script--the usual script for Urdu) and 
> ur-Deva (Urdu in Devanagari script).
> 
> Possible behaviors are to categorize the ur-Deva module as belonging to an 
> unknown language (bad), to fall back and categorize it as simply Urdu 
> (better, but certainly confusing if the language name is written in Arabic 
> and the module is itself written in Devanagari), or to categorize it 
> separately as Urdu written in Devanagari (best).
> 
> For implementers who localize the language name, Urdu written in Arabic is 
> written "اردو". Urdu written in Devanagari is written "उर्दू".
> 
> --Chris
> 
> ___
> 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] support for locale codes with region/script subtags

[DM Smith]

Didn't mean this to become a JSword thread. We're using Java 5 which does not 
have any notion of script. So we roll our own and replace it when we get to 
Java 7.

The question still remains, is _ intended in the module conf? If so, we'll 
change JSword code to handle it.

In Him,
DM

On Feb 10, 2013, at 3:26 PM, Chris Burrell  wrote:

> Hi DM/Chris
> 
> The standard is defined in BCP47 which only supports a '-'. 
> (http://tools.ietf.org/html/bcp47)
> 
> as documented by JAVA here: 
> http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#def_variant. 
> Java seems to support both a dash and an underscore.
> 
> DM, we should ideally be using the Java functionality which supports both, 
> rather than implementing our own decoding scheme. Not sure what we do/don't 
> do here.
> Chris
> 
> 
> 
> On 10 February 2013 20:09, DM Smith  wrote:
> Chris,
> We've got this in JSword (not sure it works) for  a while now for the next 
> release. We used the codes as you've given here. But in the conf file you 
> have ur_Deva. We're not expecting an _ but a -. We can change the code. 
> Please advise.
> 
> In Him,
> DM
> 
> On Feb 10, 2013, at 5:56 AM, Chris Little  wrote:
> 
> > Just a quick heads up:
> >
> > In general, locale codes (the Lang= field of .confs) can have subtags that 
> > indicate region, script, etc. Ideally these should be dealt with in some 
> > fashion by front ends since they identify important distinctions (in the 
> > eyes of the module maker or publisher at least).
> >
> > When unknown subtags are encountered, it's probably best to recursively 
> > fall back to the tag minus its right-most subtag. For example, if 
> > 'en-Latn-US' is unknown, fall back to 'en-Latn'. If that is unknown, fall 
> > back to 'en'. (Hopefully nearly all language subtags are known.)
> >
> > We should handle this in the library, but currently don't. :(
> >
> >
> > As a specific case in point:
> > We now have two Urdu translations. They're the same translation and differ 
> > in their script (one is Arabic, the other Devanagari). Their language codes 
> > (as of the 1.2.1 release just made, which corrected the code for the 
> > Devanagari version) are: ur (Urdu in Arabic script--the usual script for 
> > Urdu) and ur-Deva (Urdu in Devanagari script).
> >
> > Possible behaviors are to categorize the ur-Deva module as belonging to an 
> > unknown language (bad), to fall back and categorize it as simply Urdu 
> > (better, but certainly confusing if the language name is written in Arabic 
> > and the module is itself written in Devanagari), or to categorize it 
> > separately as Urdu written in Devanagari (best).
> >
> > For implementers who localize the language name, Urdu written in Arabic is 
> > written "اردو". Urdu written in Devanagari is written "उर्दू".
> >
> > --Chris
> >
> > ___
> > 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] support for locale codes with region/script subtags

[DM Smith]

On Feb 10, 2013, at 8:21 PM, Chris Little  wrote:

> 
> 
> On Feb 10, 2013, at 3:23 PM, DM Smith  wrote:
> 
>> Didn't mean this to become a JSword thread. We're using Java 5 which does 
>> not have any notion of script. So we roll our own and replace it when we get 
>> to Java 7.
>> 
>> The question still remains, is _ intended in the module conf? If so, we'll 
>> change JSword code to handle it.
>> 
> 
> No, this was updated before I sent the previous email.

Thanks!
I was checking a prior download of mods.d.tar.gz then.

-- DM


___
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] GerLut1912 incorrectly encoded?

[DM Smith]

An older version of osis2mod pulled titles out and put them at the top of the 
"verse". It no longer does that.

I suggest mod2imp to debug what is stored. osis2mod attempts to rewrite the 
module contents.

The output you give indicates that it was built with that older version. But it 
might be an artifact of osis2mod.

In Him,
DM
On Feb 12, 2013, at 1:25 PM, Joachim Ansorg 
 wrote:

> Hi all,
> it's been a while since I did work with OSIS.
> 
> The GerLut1912 module in the beta repository seems to have an invalid tag 
> order, I think.
> For example Gen.1.9 is (taken from mod2osis output):
> 
> 1.Mose 1,9 
> - Der zweite Tag   Und Gott sprach: Es sammle 
> sich das Wasser unter dem Himmel an besondere Örter, daß man das Trockene 
> sehe. Und es geschah also. osisRef="2Pet.3.5">2.Petr 3,5; Hiob 
> 38,8-11
>   
> The tag is opened inside of the verse tag but not closed 
> inside of it.
> 
> Is this the output of osis2mod or is this the module's encoding?
> 
> Thanks a lot,
> Joachim
> -- 
> <>< Re: deemed!
> 
> ___
> 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] KJV with references?

[DM Smith]

The ThML version has them, but they are not from the KJV, but Treasury (IIRC). 
Want those that were part of the 1769 (as best as can be reconstructed.)

Also, the margin notes are present for the OT but not the NT. I'd like to get 
these, too.

And the KJV should have section titles. We don't have those. We should.

In Him,
DM

On Feb 18, 2013, at 8:08 AM, David Haslam wrote:

> My copy of a printed edition of the Authorized Version has pages with a
> center margin containing references. 
> 
> This is a *1936* edition published by William Collins Sons and Company,
> Limited in Glasgow.
> 
> The front page declaration is dated the Third Day of November, Nineteen
> Hundred and Thirty-Six.
> T. M. Cooper, /Lord Advocate/, recorded its compliance on the Seventeenth
> day of the same month.
> 
> Does anyone know of or have access to an electronic version of the KJV in
> which these cross-references are included?
> 
> cf. Our KJV module does not contain any scripture cross-references.
> 
> David

___
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] FTP, JSword and Xiphos

[DM Smith]

It has long been known that JSword uses HTTP to get CrossWire's zip files as 
its only download mechanism. It used to have FTP but it was flaky on Windows.

I'm in the process of adding it back in, but realized that it too only goes 
after the zip files. So I've now got "proper" code to get the files 
individually.

And it works on all the repos except Xiphos. I can't seem to connect via ftp at 
all, even from the command line. Is this my problem or Xiphos.org?

Many thanks,
DM
___
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] ESV module updated to current version possible?

[DM Smith]

I like 3 day holidays! I'm devoting it to finishing up some long awaited 
changes:

JSword -- av11n (done) and ftp (prototyped, good enough to put off till later ;)

KJV -- bug in osis2mod which is adding spaces before punctuation in colophons.

ESV -- need to verify the xml is valid OSIS. I have the most recent files 
provided by Crossway as of a couple of months ago. Don't recall the edition. 
Once I get it done, I'll make it available to key devs of the frontend makers 
for response (Xiphos, Pocket Sword, BibleTime, SWORD Project, And Bible, 
AlKitab, STEP, ) before release.

In Him,
DM

On Feb 18, 2013, at 6:58 AM, Chris Burrell  wrote:

> Hi Martin
> 
> DM is currently working on the ESV 2007, at which point Tyndale will add 
> (once the work is finished) the Strong tagging to it. I'm not sure when the 
> 2011 work will happen, but as far as the tagging is concerned we're hoping it 
> shouldn't be too difficult to move it from 2007 to 2011.
> 
> Chris
> 
> 
> 
> On 18 February 2013 11:36, Martin Denham  wrote:
> I had a query regarding an ESV version update from an AB user recently: 
> 
> "... I have to admit some surprise when I found the text that pastor was 
> using was different in places. For example, Isa. “he was wounded for our 
> transgressions” in the app, but “pierced for our transgressions” in the 
> church Bible.
>  I now realize there have been some ESV revisions, with the church using the 
> ESV 2011 Text Version. What version is the ESV in the AndBible? Any 
> possibility it will ever be updated or have the new text version available?"
> 
> 
> 
> 
> 
> Can I tell him Yes/No/Maybe.  Have we asked Crossway for permission?
> 
> 
> 
> Regards
> 
> Martin
> 
> 
> 
> 
> On 30 August 2012 18:35, Jared Meidal  wrote:
> I would love to see the ESV version updated to reflect 2011 changes for 
> CrossWire Bibles.  Is this something I can contribute to by manual changes in 
> mark-up code?  I've seen this module remain at 1.0.1 (Copyright © 2001 by 
> Crossway Bibles) for a long time.
> 
> I currently use Xiphos, AndBible and FireBible front-ends.
> 
> --Jared
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
> 
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] osis2mod

[DM Smith]

FYI, I just checked in a bug fix and a minor enhancement.

The enhancement allows newlines within tags as in:


This will become . It simply replaces a '\n' 
with a ' '.
Note: This also changes \n in an attributes value to a ' '.

The bug was that space was being introduced within interverse content. This 
typically wouldn't be noticable, but it was putting a space after every tag 
even when the text that was between tags started with punctuation.

In Him,
DM
___
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] KJV update

[DM Smith]

I think I have a ready-to-release update to the KJV. Please do one last check.
You can get the modules here:
http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/kjv.zip
or if you want one with a different name and in raw format:
http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/av.zip

Many thanks to David H for finding lots of bugs.

Hope to release very soon.

In Him,
DM
___
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] KJV update

[DM Smith]

On Feb 19, 2013, at 8:55 AM, Ben Morgan  wrote:

> Hi DM,
> 
> I'm looking at it for how it displays in BPBible. Mostly it seems to show up 
> fine. 
> At the moment the code I had in place actually shows the tr greek text links, 
> though it doesn't know what to look them up in (there's no dictionary 
> matching the tr: scheme, right?). 

There are a few other modules that have lemmas other than "strong:". If you 
want Strong's numbers look only for strong:.

> I think I'll make it ignore them for now. It would be nice to have a common 
> way with non-strongs type lemmas to
> 1) have them togglable with options (on a class by class basis? what would 
> you label this for tr: - TR? Greek?)

The tr: lemma is the original greek from the TR Bible module. The src attribute 
gives the position of that word in the same verse. 

You can use the tr: value for an interlinear. You could also show the tr value 
and use the strong for the link.


> 2) have some way to look them up in dictionaries
> 
> However, one change I did notice was that you've swapped the order in at 
> least one place of a q and a paragraph marker so that in the new KJV module, 
> the  contains the paragraph marker:
> 

I think this is across the board. 

> 
> Was this a deliberate change?

Actually, it is osis2mod that is doing that. The latest osis2mod allows for the 
WoC to be marked up naturally, even spanning chapters, such as with the 
beatitudes. So that would have a start in chapter 5 and an end in chapter 7. 
osis2mod then marks up the words individually with the WoC markup. It always 
puts the marker at the beginning of the verse as it has not seen any content 
from the verse.

So yes it was deliberate. The old source file used to have per verse markup. 
The new file has natural markup.


> This doesn't work with BPBibles code as-is

It doesn't work with Bible Desktop either.

> (though I could probably get it to work with a little more hacking). In 
> general, BPBible:
> 1) turns pilcrows into paragraphs

Bible Desktop would do both: add a paragraph break and show the pilcrow.
I plan to check to see if the verse has a pilcrow, instead of seeing if the 
verse has it at the beginning. Haven't made the change, but it will be small.

> 2) floats whitespace before verse numbers
> 
> At the moment, the paragraph tag doesn't float out before the verse number 
> due to the  tag. This ends up with the awkward situation where the 
> previous line ends with the verse number and then the verse actually starts 
> on a new line.

Yes, that doesn't sound good. Bible Desktop doesn't have this problem as it has 
not identified the pilcrow as a paragraph separator.

> 
> Also, in BPBible at least words of Christ are done with span tags, and having 
> the  inside a span doesn't really work and the highlighting goes missing. 
> 
> Quite possibly other frontends don't try and tweak the text like this and so 
> aren't affected.
> 
> This isn't causing any problems, but I'm interested in the  tag 
> which now shows up in v0. e.g.
>   type="chapter">CHAPTER 1.
> Is there any expectation this will be used? Does it need to be retained here 
> (seeing as  is there too)?

osis2mod retains all tags and content from the module except the OSIS preamble.

If you dump the module w/ mod2imp, it is a simple matter of adding in verse 
tags to have a valid OSIS file.

You'll find lots of other tags that a renderer won't care about.

> 
> God Bless,
> Ben
> -
> For I have no pleasure in the death of anyone, 
> declares the Lord God; so turn, and live.”
> Ezekiel 18:32 (ESV)
> 
> 
> 
> On Tue, Feb 19, 2013 at 9:19 AM, DM Smith  wrote:
> I think I have a ready-to-release update to the KJV. Please do one last check.
> You can get the modules here:
> http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/kjv.zip
> or if you want one with a different name and in raw format:
> http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/av.zip
> 
> Many thanks to David H for finding lots of bugs.
> 
> Hope to release very soon.
> 
> In Him,
> DM
> ___
> 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] KJV update

[DM Smith]

I updated the wiki with my response. They are the Unicode standard's preferred 
possessive apostrophe.

In Him,
DM

On Feb 19, 2013, at 10:14 AM, David Haslam  wrote:

> Please revert possessives back to ordinary apostrophes!
> 
> See http://crosswire.org/wiki/User:Dmsmith/KJV2011#Apostrophes
> 
> I already wrote to you about this, but I received no response.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/KJV-update-tp4651977p4651984.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] KJV update

[DM Smith]

Yes. I thought my prior response was sufficient. The module has had them that 
way for 7 years. Front-ends have a variety of ways that they handle the 
pilcrow. I don't see the need for the change in the module.

If you take a look at the 1611, there is no space following the pilcrow:
http://sceti.library.upenn.edu/sceti/printedbooksNew/index.cfm?TextID=kjbible&PagePosition=77

I had noticed that the NT only used them until that location. Until you pointed 
out the reason, I had no clue as to why.

In Him,
DM

On Feb 19, 2013, at 9:53 AM, David Haslam  wrote:

> Hi DM,
> 
> Did you think further about
> http://crosswire.org/wiki/User:Dmsmith/KJV2011#Pilcrow_signs
> since my last response therein?
> 
> David
> 
> PS. A curious aside: After Acts 20:36 there are no more pilcrows in the KJV.
> /Specialist historians think the 1611 printers simply ran out of the movable
> type for this character./
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/KJV-update-tp4651977p4651983.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] KJV update

[DM Smith]

On Feb 19, 2013, at 11:12 AM, Chris Little  wrote:

> On 2/19/2013 6:43 AM, DM Smith wrote:
>> 
>> On Feb 19, 2013, at 8:55 AM, Ben Morgan > <mailto:benpmor...@gmail.com>> wrote:
>> 
>>> Hi DM,
>>> 
>>> I'm looking at it for how it displays in BPBible. Mostly it seems to
>>> show up fine.
>>> At the moment the code I had in place actually shows the tr greek text
>>> links, though it doesn't know what to look them up in (there's no
>>> dictionary matching the tr: scheme, right?).
>> 
>> There are a few other modules that have lemmas other than "strong:". If
>> you want Strong's numbers look only for strong:.
>> 
>>> I think I'll make it ignore them for now. It would be nice to have a
>>> common way with non-strongs type lemmas to
>>> 1) have them togglable with options (on a class by class basis? what
>>> would you label this for tr: - TR? Greek?)
>> 
>> The tr: lemma is the original greek from the TR Bible module. The src
>> attribute gives the position of that word in the same verse.
>> 
>> You can use the tr: value for an interlinear. You could also show the tr
>> value and use the strong for the link.
> 
> A small note on the choice of lemma workIDs:
> Our ad hoc standard way of identifying lemma types is to use a workID of 
> lemma.. The only module I can think of that employs this 
> is MorphGNT, which has lemma.Strong. You might use something like lemma.TR, 
> given the source. There's some special logic in the OSISLemma filter for 
> workIDs of this form, IIRC.
> 
> (Brief) documentation, to prove I'm not just making this up :), at:
> http://www.crosswire.org/wiki/OSIS_Bibles#Marking_other_lemmas

OK. I can change it to lemma.TR:, rather than tr:. And I can add the proper 
workID to the header (which I forgot to do). Troy has already incorporated this 
change into a program, but that would be a very simple change for him to make.

But then what is the "proper" way to mark up the content of the lemma?

It is not a reference to that work but a word in the parallel verse in that 
module at the location given by the src attribute. And it has to interpret the 
src= value based upon the variant that is used by the KJV from that verse. Some 
verses have multiple variants, so the choice of earlier affects later.

The purpose of this was to record the original Greek used in the src= 
reference. Maybe, it really isn't lemma.TR, but something else?

> 
> If you validate the OSIS with this, the validator will complain. Ignore it. 
> The bug is in the schema.

I've my own modified schema to avoid bug complaints, I'll add it to that. Going 
forward w/ such a schema is a separate discussion and should be on its own 
thread.

-- DM

> 
> --Chris
> 
> 
> ___
> 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] KJV update

[DM Smith]

On Feb 19, 2013, at 7:57 PM, Nic Carter  wrote:

> 
> Pilcrows look fun when they're red :)
> But that's not a bug. :P
> 
> Oh, and if pilcrows could be moved to the end of the previous verse instead 
> of the start of the current verse, that would be fun :) But all good if 
> they're staying where they are ;)

In the printed text they show as a character after the verse number and 
immediately before the first character of the verse.

I've thought about adding  or  to surround these, but 
atm SWORD lib produces too much vertical whitespace.

> 
> There was some comments about the TR markup, and it would be cool if there 
> was some more direction about what we are meant to do with them? PS currently 
> displays them as if they are another Strong's Number link and so tapping on 
> them will try to look it up in the current Strong's Numbers dictionary, which 
> fails to work and instead will always show Strong's Number 1 (ie: Alpha).
> If they're not currently supported at all, are we able to have 2 copies of 
> the OSIS and create our SWORD module from the copy of the OSIS that doesn't 
> contain these bits? :)


Here is my thought in putting them in.

When fixing the tagging of the Strong's numbers to English phrases in the KJV, 
I had to constantly refer to the TR to see the actual word. I found myself 
doing a lot of counting to find the n-th Greek word (for src="n"). Also, the TR 
module has variants in some verses. These represented choice between two Greek 
texts as to what the src="n" referenced. Sometimes the variants were words in 
one variant but no words in the other. Other times one variant had more words 
than the other. And other times they were the same length, but just different 
words. So, the src="n" was ambiguous in these verses. Adding the words from the 
TR made it unambiguous.

They certainly belong in the OSIS master text and don't have to be in the 
module. It is trivial to create a copy of the OSIS master file without them and 
use that to make a module. There is other markup in the master that is not in 
the module.

Troy has said he'd like for them to remain, but I think we need to ensure that 
the SWORD lib handles them such that front-ends works well with them.

I'm going to follow Chris' advice and prefix them as lemma.TR:. Let's see what 
that does. Can you point me to instructions on how to load a module into 
PocketSword (again)? I'm too lazy to dig for it ;)

As to direction regarding their use: not sure. Ultimately I think it forms part 
of an interlinear.

For Bible Desktop, I'm thinking of presenting it along with the Strong's 
Number. I'm not sure if I'll present the word in place of the Strong's number 
as the text for the Strong's number link, or have it as a clickable link along 
side of the Strong's Number with the the same href or have it as plain text. Or 
not show it at all (which is what I'm doing now.)

But they shouldn't be broken links.


> Other than that, seems all good?

Thanks. We'll sort this out before a release.

In Him,
DM


> 
> 
> On 19/02/2013, at 9:19 AM, DM Smith wrote:
> 
>> I think I have a ready-to-release update to the KJV. Please do one last 
>> check.
>> You can get the modules here:
>> http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/kjv.zip
>> or if you want one with a different name and in raw format:
>> http://www.crosswire.org/~dmsmith/kjv2006/sword/2011/av.zip
>> 
>> Many thanks to David H for finding lots of bugs.
>> 
>> Hope to release very soon.
>> 
>> In Him,
>>  DM

___
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] Searching Morphology Codes

[DM Smith]

In the NT we have Robinson codes which have meanings that ultimately do not 
require a dictionary to understand.

In SWORD you can search SN@RC (where SN is a Strong's Number and RC is a 
Robinson's Code) or for just RC.

I'm wondering whether searches can be more focused in a linguistically 
meaningful way?

I'm not a linguist, but wondering what would be helpful to those that are.

What would those searches be?

Gender?

Person?

Voice?

Many thanks in advance.

In Him,
DM
___
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] Pre-verse div and headings

[DM Smith]

The KJV has book and chapter intros. These are merely the title for the book 
and chapter, but they'll be a good test case.

I don't know of any that have a module intro or a testament intro.

I haven't added them to osis2mod as I don't know how to reference them in the 
SWORD lib.

I don't know how to detect them using SWORD lib.

I do think it'd be good to have an indicator in the conf for these. 

Currently these are treated as "headings", but they can be much more than that.

I have the intro to the KJV, but haven't put it in the source yet because I 
don't know how to get it into the module.

In Him,
DM

On Feb 21, 2013, at 8:24 PM, Nic Carter  wrote:

> 
> Quick question about introductions in modules:
> 
> On 22/01/2013, at 2:07 AM, Troy A. Griffitts  wrote:
> 
>> OK, to clear this up technically.
>> 
>> setIntros() turns on and off the versification extra 'slots':
>> 
>> TSTMT BK CH:0 - chapter intro
>> TSTMT BK 0:0 - book intro
>> TSTMT 0 0:0 - testament intro
>> 0 0 0:0 - module intro
> 
> Is there any way to detect if a module contains these introductions?
> 
> Right now PocketSword will display chapter intros if they exist (well, in 
> v1.4.3, which is currently "in review" with Apple).
> After that, I am thinking about the rest of these intros.
> Do I programmatically check 69 different locations (well, for Bibles with 66 
> books) to test for
> 66 lots of (book intro != NULL)
> 2 lots of (testament intro != NULL)
> 1 lot of (module intro != NULL)
> and then know whether to offer a user to select these intros to view?
> 
> Or is there a simpler way of knowing if these exist?
> 
> Also, is there an English module that contains various of these intros that I 
> can use for testing purposes? (actually, non-English will work as well, but I 
> just won't be able to read the content!)
> 
> Thanks heaps, ybic
>   nic...  :)
> 
> ps: alternatively, I could check to see if I'm displaying chapter 1 & then 
> include the book intro at the top.
> pps: along these lines, I could check if we're viewing the first book in a 
> testament & then display the testament intro at the top as well?
> ppps: and, carrying on, check if we're viewing the first book in the first 
> testament in a module, and display the module intro as well?
> 
> s: However, all of these ps' will make things a little more messy for the 
> reader...  :/
> 
> 
> ___
> 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] Forums down?

[DM Smith]

It's back. Jira is down. Working to make sure all are up.
-- DM

On Feb 21, 2013, at 10:32 PM, Nic Carter  wrote:

> 
> http://www.crosswire.org/forums reports a 503 :(
> 
> ___
> 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] Forums down?

[DM Smith]

It's all good now.


On Feb 21, 2013, at 11:11 PM, DM Smith  wrote:

> It's back. Jira is down. Working to make sure all are up.
> -- DM
> 
> On Feb 21, 2013, at 10:32 PM, Nic Carter  wrote:
> 
>> 
>> http://www.crosswire.org/forums reports a 503 :(
>> 
>> ___
>> 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] Searching for hyphenated words?

[DM Smith]

I see two different questions being posed:
a) The correctness of using an ndash within a word.
b) The ability to search for words containing ndash or any kind of dash, 
including a simple hyphen.

I'll start with my conclusion: Changing the ndash to a simple hyphen does not 
really address the questions.

Regarding correctness:
The usage of ndash in the KJV is within names only. At the bottom, I've 
included a list of the names having an ndash. In the 2003 version of the 1769 
KJV, these words were not hyphenated. They were hyphenated with an ndash in the 
2006 cleanup. As an interesting aside, I looked at some of the non-name words 
that are hyphenated in the 1769 KJV and compared them to a photocopy of the 
1611. These are word such as God-ward, us-ward, thee-ward, joint-heirs,  My 
search was not exhaustive, but the 1611 didn't have hyphens, but either 
concatenated the words as with the -ward suffixes or with a space as in joint 
heirs. The other thing I noticed was that in each case where the KJV (either 
1769 or 1611) had a hyphenated name, it was a Hebrew transliteration of some 
sort and had an attached note to at least one of the instances.

One question is whether they should be taken as a whole or parts? So, is 
Beth–el, equivalent to Beth el or to Bethel? Another question, does a dash 
(hyphen, ndash, mdash, ...) have the same meaning today as it did hundreds of 
years ago? Same question but regarding different languages: Do different 
languages use a dash with different semantics than modern English?

Regarding search:
This regards several issues:
How does Lucene handle these different characters?
What does an end user want/expect?
Can we leverage that to meet user expectation?

Lucene's handling:
Lucene uses an Analyzer to split text into words on punctuation for indexing 
and for search. JSword uses SimpleAnalyzer because it makes no further 
assumptions on the text. SWORD lib uses StandardAnalyzer which does. I think 
the StandardAnalyzer has special rules for hyphens. In Lucene 3.6 the 
StandardAnalyzer behavior changes to use UAX 29 rules for splitting the text. 
This is a huge step forward. I don't know whether it handles '-' differently 
than other punctuation. (JSword switched from the StandardAnalyzer to the 
SimpleAnalyzer very early on because of the extra assumptions that 
StandardAnalyzer makes about what the user wants to index and not index and 
because it was significantly slower.)

With the SimpleAnalyzer a dash (hyphen, ndash, mdash) are used to create 
phrases. As such Beth–el, Beth-el and "Beth el" are equivalent. (This is with 
Lucene 3.0.3, earlier versions may differ). Note, it really doesn't matter that 
it's a dash, any punctuation will do. I don't think this is the case with the 
StandardAnalyzer.

One of the impacts of having hypenated words is that searching for Bethlehem 
won't find Beth–lehem. (The NT and OT differ on the spelling in the KJV.) It 
doesn't matter what kind of dash is used. The user cannot omit the hyphen to 
concatenate the words.

Another impact of hyphenated words is that it is much harder to do a wild card 
search. It doesn't matter what kind of dash is used. If the search request has 
a dash a * cannot be used.

So Lucene can do the right thing wrt the ndash and hyphen. They are identical 
wrt indexing and searching. The user does not have to know the form that is 
used in the file and match that.

The other feature that Lucene offers out of the box is Fuzzy Searching. I will 
find close approximations to the word that you are requesting. All that needs 
to be done is append a ~ to the end of the word. For example, Abimelek~ finds 
Abimael, Abimelech, Abiezer and Ahimelech. This is not a Soundex search, so the 
results are often surprising. Bethelham~ finds Meshullam and Bethlehem~ finds 
betrothed but not Bethlehem.

Some front-ends don't use Lucene for indexing. Some use an older version. So 
the behavior can differ.
Also, SWORD doesn't require indexing for "slow" search. Don't know if the SWORD 
"slow" search treats the various dashes the same or differently. (I think this 
is the Multi-word search mentioned by David)

User expectation:
The hyphenation of these names is not common in other translations. I think 
that most users would expect Bethel and not Beth–el or Beth-el. Together this 
makes searching multiple Bibles at the same time very difficult.

I think that a user might have a reasonable expectation not knowing that proper 
spelling of more than a few of them. Let alone that they are hyphenated. 

Leveraging:
I think that if StandardAnalyzer does not give expected behavior then 
SimpleAnalyzer should be used.

I think that hyphenated words should also be indexed as unhyphenated.

Adding a simple filter to change different forms of dashes into a single form 
for both search and index is a good solution but would break backward 
compatibility with existing indexes and changing from StandardAnalyzer to 
SimpleAnalyzer would be as 

Re: [sword-devel] Searching for hyphenated words?

[DM Smith]

Couple of corrections on the list. David pointed out some problems:
Hazar–maveth should not be on the list. It is without the hyphen in the text.
These should be on the list:
Abi–ezrites
Beth–elite
Beth–lehemite
Rab–mag

The following are programmatic "typos"
KirhereKir–heres
RabsariRab–saris


Also, if you are looking for Gibeah–haaraloth, you'll find it in a note in Joel 
5:3.


Thanks,
DM

On Mar 2, 2013, at 11:42 AM, DM Smith  wrote:

> I see two different questions being posed:
> a) The correctness of using an ndash within a word.
> b) The ability to search for words containing ndash or any kind of dash, 
> including a simple hyphen.
> 
> I'll start with my conclusion: Changing the ndash to a simple hyphen does not 
> really address the questions.
> 
> Regarding correctness:
> The usage of ndash in the KJV is within names only. At the bottom, I've 
> included a list of the names having an ndash. In the 2003 version of the 1769 
> KJV, these words were not hyphenated. They were hyphenated with an ndash in 
> the 2006 cleanup. As an interesting aside, I looked at some of the non-name 
> words that are hyphenated in the 1769 KJV and compared them to a photocopy of 
> the 1611. These are word such as God-ward, us-ward, thee-ward, joint-heirs, 
>  My search was not exhaustive, but the 1611 didn't have hyphens, but 
> either concatenated the words as with the -ward suffixes or with a space as 
> in joint heirs. The other thing I noticed was that in each case where the KJV 
> (either 1769 or 1611) had a hyphenated name, it was a Hebrew transliteration 
> of some sort and had an attached note to at least one of the instances.
> 
> One question is whether they should be taken as a whole or parts? So, is 
> Beth–el, equivalent to Beth el or to Bethel? Another question, does a dash 
> (hyphen, ndash, mdash, ...) have the same meaning today as it did hundreds of 
> years ago? Same question but regarding different languages: Do different 
> languages use a dash with different semantics than modern English?
> 
> Regarding search:
> This regards several issues:
> How does Lucene handle these different characters?
> What does an end user want/expect?
> Can we leverage that to meet user expectation?
> 
> Lucene's handling:
> Lucene uses an Analyzer to split text into words on punctuation for indexing 
> and for search. JSword uses SimpleAnalyzer because it makes no further 
> assumptions on the text. SWORD lib uses StandardAnalyzer which does. I think 
> the StandardAnalyzer has special rules for hyphens. In Lucene 3.6 the 
> StandardAnalyzer behavior changes to use UAX 29 rules for splitting the text. 
> This is a huge step forward. I don't know whether it handles '-' differently 
> than other punctuation. (JSword switched from the StandardAnalyzer to the 
> SimpleAnalyzer very early on because of the extra assumptions that 
> StandardAnalyzer makes about what the user wants to index and not index and 
> because it was significantly slower.)
> 
> With the SimpleAnalyzer a dash (hyphen, ndash, mdash) are used to create 
> phrases. As such Beth–el, Beth-el and "Beth el" are equivalent. (This is with 
> Lucene 3.0.3, earlier versions may differ). Note, it really doesn't matter 
> that it's a dash, any punctuation will do. I don't think this is the case 
> with the StandardAnalyzer.
> 
> One of the impacts of having hypenated words is that searching for Bethlehem 
> won't find Beth–lehem. (The NT and OT differ on the spelling in the KJV.) It 
> doesn't matter what kind of dash is used. The user cannot omit the hyphen to 
> concatenate the words.
> 
> Another impact of hyphenated words is that it is much harder to do a wild 
> card search. It doesn't matter what kind of dash is used. If the search 
> request has a dash a * cannot be used.
> 
> So Lucene can do the right thing wrt the ndash and hyphen. They are identical 
> wrt indexing and searching. The user does not have to know the form that is 
> used in the file and match that.
> 
> The other feature that Lucene offers out of the box is Fuzzy Searching. I 
> will find close approximations to the word that you are requesting. All that 
> needs to be done is append a ~ to the end of the word. For example, Abimelek~ 
> finds Abimael, Abimelech, Abiezer and Ahimelech. This is not a Soundex 
> search, so the results are often surprising. Bethelham~ finds Meshullam and 
> Bethlehem~ finds betrothed but not Bethlehem.
> 
> Some front-ends don't use Lucene for indexing. Some use an older version. So 
> the behavior can differ.
> Also, SWORD doesn't require indexing for "slow" search. Don't know if the 
> SWORD "slow"

Re: [sword-devel] Searching for hyphenated words?

[DM Smith]

Lucene is highly configurable, but out of the box StandardAnalyzer and 
SimpleAnalyzer do not do anything with this. To handle it requires adding a 
folding filter. I think they have one suitable for it, but it is not hard to 
write one to do it.

It may require creating ones own Analyzer, which is nothing more than a 
tokenizer and a chain of filters, to add in a filter.

This is something that JSword needs also and I haven't gotten around to work on 
it. I see it as part of a larger solution of handling accents which is another 
folding problem.

In Him,
DM

On Mar 3, 2013, at 7:53 AM, Jonathan Morgan  wrote:

> Another possibly related normalisation problem which BPBible at least has an 
> open issue about is Caesar vs. Cæsar.  Theoretically I guess you want either 
> search to match both forms.  I don't know how Lucene etc. deals with this (if 
> at all).
> 
> Jon
> 
> On Mon, Feb 25, 2013 at 2:48 AM, David Haslam  wrote:
> In the KJV module, if you want to search for [say] the hyphenated name
> "Maher–shalal–hash–baz", you first have to be aware that this module uses
> the ndash in place of the hyphen.
> 
> btw.  It's not so easy to enter the ndash from a keyboard, and probably even
> harder in an Android tablet or mobile.
> 
> If you use ordinary hyphen/minus for the search key hyphen for this module,
> you don't find anything with "Exact phrase".
> If you use "Multi-word", you do find "Maher" highlighted in the found verse.
> (e.g. using Xiphos).
> 
> For modules in general, however, the user cannot usually know in advance
> whether hyphenated words use the ndash, the hyphen or something else.
> 
> Has anyone else looked into this aspect of the search feature?
> 
> David
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Searching-for-hyphenated-words-tp4652016.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

___
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] Searching for hyphenated words?

[DM Smith]

You're not missing anything. These kind of problems are handled best by 
normalization.

In my earlier post I was suggesting that we normalize an hyphenated word, say 
"God-ward",  to its parts and the whole: "God", "ward" and "Godward".

Solving backward compatibliity is fairly simple. Have a version number for the 
built index. If it doesn't match the expected value from the normalizer, the 
index is invalid and can't be used. JSword has the code for such a mechanism, 
but it hasn't been woven in. One could go deeper than a single coarse grain 
version number and have version numbers for each feature that is part of an 
index.

In Him,
DM
On Mar 3, 2013, at 8:36 AM, Chris Burrell  wrote:

> I still think normalisation of what is searched for would be good, in that it 
> basically means the user sees the results that he is looking for.
> 
> I understand the concern for backwards compatibility and perhaps that means 
> frontends should be able to turn this normalisation off. But looking ahead, 
> for new front-ends, front-ends that can make rebuilding indexes part of the 
> upgrade to a new version and for all new downloads of frontends, this has to 
> be a benefit.
> 
> Not normalising, seems to me like perpetuating an existing problem into all 
> new downloads from this day forth. Or am I missing something?
> Chris
> 
> 
> 
> On 3 March 2013 12:53, Jonathan Morgan  wrote:
> Another possibly related normalisation problem which BPBible at least has an 
> open issue about is Caesar vs. Cæsar.  Theoretically I guess you want either 
> search to match both forms.  I don't know how Lucene etc. deals with this (if 
> at all).
> 
> Jon
> 
> 
> On Mon, Feb 25, 2013 at 2:48 AM, David Haslam  wrote:
> In the KJV module, if you want to search for [say] the hyphenated name
> "Maher–shalal–hash–baz", you first have to be aware that this module uses
> the ndash in place of the hyphen.
> 
> btw.  It's not so easy to enter the ndash from a keyboard, and probably even
> harder in an Android tablet or mobile.
> 
> If you use ordinary hyphen/minus for the search key hyphen for this module,
> you don't find anything with "Exact phrase".
> If you use "Multi-word", you do find "Maher" highlighted in the found verse.
> (e.g. using Xiphos).
> 
> For modules in general, however, the user cannot usually know in advance
> whether hyphenated words use the ndash, the hyphen or something else.
> 
> Has anyone else looked into this aspect of the search feature?
> 
> David
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Searching-for-hyphenated-words-tp4652016.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
> 
> ___
> 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] Searching for hyphenated words?

[DM Smith]

On Mar 3, 2013, at 11:53 AM, Chris Burrell  wrote:

> Yes although in French only the contacted form is correct
> 
> 

WRT indexing and searching, it really doesn't matter which is correct. The 
normalization is not visible to the user. Normalization often goes to forms 
that are ugly for the end-user.

-- DM

> On 3 Mar 2013 16:10, "David Haslam"  wrote:
> There are similar issues in French modules.
> 
> e.g. Some French Bibles have "coeur", some have "cœur", and some even use
> both!
> 
> etc., etc.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Searching-for-hyphenated-words-tp4652016p4652042.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

___
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] Hebrew Morphology Codes (was Searching Morphology Codes)

[DM Smith]

As part of the development of JSword we've been trying to figure out a good way 
to do searching as noted below. A big problem is Hebrew. We have references but 
nothing backing those codes. There are two parts to a good solution:
a) A searchable code that also is readily understandable by people.
b) A mapping of those codes to those in our modules.

In Jira we have a recommendation for a) provided by David Instone-Brewer. I've 
blind copied a few of you that are on this list hopefully to make it more 
visible to you in seeking your input.

In the following Jira issue, take a look at the most recent Encoding.doc 
attachment.
http://www.crosswire.org/tracker/browse/JS-226

Once we settle on a code set and have a mapping from the existing codes, I'll  
make a module for the codes and update the KJV to use them.

In His Service,
DM

On Feb 21, 2013, at 8:00 PM, Daniel Owens  wrote:

> I am so glad you asked about this, DM. 
> 
> As an OT scholar I want to be able to search for any possible combination of 
> lemma and morphology. The possible combinations depend on the structure of 
> the morphology codes. Chris has helpfully listed those for Robinson, but the 
> WHM module will have its own, as will the OpenScriptures Hebrew Bible, when 
> it gets morphology. :) 
> 
> As a practical matter, the first step it seems to me is to have the ability 
> to use wildcards to construct searches without using an interface, just 
> typing the codes. Let's say * is the wildcard. Theoretically I want to be 
> able to search for *@*, but in actual practice obviously elements should be 
> able to be filled in. So if γενεαὶ (from γενεα) is N-NPF (Noun-Nominative 
> Plural Feminine), I may want to search for: 
> 
> *@N-NPF
> γενεα@Ν-*PF
> 
> And many other iterations. Maybe I can do that already. But I also want to be 
> able to search for two terms within a certain proximity (two, three words 
> away, for example) or for terms in a particular order (A comes before B, 
> within a certain number of words). 
> 
> Because different morphologies structure the data differently (why Robinson 
> has case and number before gender is beyond me—I learned Gender-Number-Case), 
> any gui search builder would be specific to that morphology.
> 
> Daniel
> 
> On 2/21/13 11:17 PM, Chris Burrell wrote:
>> Hi DM
>> 
>> Robinson's morphology define the following:
>> 
>> Function
>> Tense
>> Voice
>> Mood
>> Person
>> Case
>> Number
>> Gender
>> Suffix
>> 
>> 
>> STEP intends to eventually allow a user to select any of the values in each 
>> of the categories and carry out either a colour filter or a search on a 
>> text/a whole Bible for a particular Strong number.
>> 
>> Chris
>> 
>> 
>> 
>> On 21 February 2013 14:25, DM Smith  wrote:
>> In the NT we have Robinson codes which have meanings that ultimately do not 
>> require a dictionary to understand.
>> 
>> In SWORD you can search SN@RC (where SN is a Strong's Number and RC is a 
>> Robinson's Code) or for just RC.
>> 
>> I'm wondering whether searches can be more focused in a linguistically 
>> meaningful way?
>> 
>> I'm not a linguist, but wondering what would be helpful to those that are.
>> 
>> What would those searches be?
>> 
>> Gender?
>> 
>> Person?
>> 
>> Voice?
>> 
>> Many thanks in advance.
>> 
>> In Him,
>> DM
>> ___
>> 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] HTTPS and crosswire.org

[DM Smith]

I probably can do the work, but I don't know what the change needs to be.

On Mar 16, 2013, at 12:28 PM, Greg Hellings  wrote:

> Chris, DM, Troy - I think you guys are the only ones who can do anything 
> about this. Any chance you could?
> 
> --Greg
> 
> 
> On Sat, Mar 16, 2013 at 11:05 AM, yvand  wrote:
> I drop it.
> 
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
> 
> ___
> 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] HTTPS and crosswire.org

[DM Smith]

I'm booked for the day. Hopefully, I can look into it tomorrow. I'll see if 
Apache docs have instructions.

On Mar 16, 2013, at 12:53 PM, Chris Burrell  wrote:

> I agree. Looks Le there is no forwarding from the ssl port.  I think we use 
> mod jk so we need to check its configured the same. 
> Most likely the Apache config for the :443 host needs to be updated like the 
> :80 host is so it hands off execution of jsp files to our servlet handler. It 
> looks like the :443 hanlder in ssl.conf is very minimal compared with the :80 
> handler.
> 
> --Greg
> 
> 
> On Sat, Mar 16, 2013 at 11:30 AM, DM Smith  wrote:
> I probably can do the work, but I don't know what the change needs to be.
> 
> On Mar 16, 2013, at 12:28 PM, Greg Hellings  wrote:
> 
>> Chris, DM, Troy - I think you guys are the only ones who can do anything 
>> about this. Any chance you could?
>> 
>> --Greg
>> 
>> 
>> On Sat, Mar 16, 2013 at 11:05 AM, yvand  wrote:
>> I drop it.
>> 
>> 
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>> 
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
> 
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Status of av11n conversions

[DM Smith]

Konstantin,

Thanks very much for the work you've done.

I'm trying to understand the data structure. JSword is an independent 
implementation and doesn't use SWORD libraries. So to implement something like 
this, it'll be helpful to understand what the data structures and the data 
means.

If I understand, you are using the KJVA as the common bridge between different 
versifications.

For the NRSV you have the following:

unsigned char mappings_nrsv[] = {
0,
66,  12,  18,  19,  13,  1,   0,
66,  13,  1,   1,   13,  1,   0,
0
};

If I read this correctly, 66 refers to Revelation (with the books are numbered 
from 1 for Genesis to 66 for Rev as appears in the KJV, and all apocryphal 
books are numbered higher than the canonical ordered as in the KJVA).

In the first non-zero row, the 66, 12, 18, 19 means Rev 12:18-19 from the NRSV.

And the "13, 1, 0" means Rev 13:1 in the KJV.

So basically, NRSV Rev 12:18-19 is the same as KJV Rev 13:1.

When I look into the NRSV versification in SWORD, I'm seeing that Rev 12 goes 
to verse 18. Whereas the KJV goes to verse 17. Where does the 19 come in?

The next line has 66, 13, 1, 1 (So NRSV 13:1) maps to 13, 1, 0 (to KJV 13:1).

Putting all of this together, KJV 13:1 is NRSV 12:18-13:1.

Curious why is it 66, 13, 1, 1 and not 66, 13, 1, 0?

Am also wondering why there's no entry for John 3. In the NRSV, there are 15 
verses but in the KJV there are 14. So shouldn't there be a line with:
64, 1, 14, 15, 1, 14, 0

I'm sure as I dig into Synodal, I'll have more questions. But I wait until I 
find out whether I'm missing something here.

In Him,
DM

On Mar 18, 2013, at 3:24 PM, "Konstantin Maslyuk"  
wrote:

> Hello. There really is done work for av11n conversion support for sword. You 
> even may get patch at
> 
> https://gitorious.org/~kalemas/sword-svn-mirrors/kalemas_at_mail_ru-trunk/commit/35a3fc6bde1ccff945d51558d7e21ab1074a4152
> 
> and use it if you compile libsword for your self. But you also should take 
> into account that this feature is not supported officially and would be 
> incompatible with future releases of Sword. And there is no known schedule 
> for this as this work was not considered for two years.
> 
> Blessings.
> 
> 
> 
> Chris Burrell  писал(а) в своём письме Tue, 12 Mar 2013 
> 23:44:36 +0400:
> 
>> Hi
>> 
>> I was wondering if someone is working on being able to convert from 1
>> versification system to another. This very important for being to line up
>> verses and therefore very important to STEP for our interlinears.
>> 
>> I'm told someone is doing the work for Sword first and then we will bring
>> it across into JSword.
>> 
>> Is someone working on this? Does anyone know what the status of this is? Is
>> there a target date for when the design will be finalised such that we can
>> implement this in JSword?
>> 
>> Chris
> 
> 
> -- 
> Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
> 
> ___
> 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] Status of av11n conversions

[DM Smith]

Thanks. It'll take me some time to wrap my head around this.

-- DM

On Mar 19, 2013, at 5:54 AM, Костя Маслюк  wrote:

> There is code/tool/data set at
> http://crosswire.org/~kalemas/work/v11nmapping
> That would be missed link to understand how it works. RefMap2cpp.py is
> used to convert v11n description in XML file to data table that you
> have been seen in the patch. XML files contain of two parts: full list
> of the verses and mapping data for transitions only.
> 
> There is also testmappings.exe if you would like to test NRSV John 3,
> it probably would work (i remember that in nrsv there are two cases,
> but John would need no corrections). You can quickly move along the
> module with this, switch active modules with different versification. Source 
> code is also available.
> 
> 
> I use KJVA versification as intermediate, with use of meta space. I did
> not encountered with complicated cases of meta space usage so I did not
> documented it anywhere.
> 
> 
> In NRSV Rev 12.18-19 is necessary for backward transition from KJVA to
> NRSV. Rev 12.19 means next chapter first verse.
> 
> 
> 66, 13, 1, 1, 13, 1, 0,
> 
> 66 - Rev, 13 - chapter, 1, 1 and 1, 0 means mapping ranges. It is exact
> verse if range end is equal to zero or is below range start. In this
> case nrsv is range and kjv is exact verse... This is necessary when we
> transit from nrsv to vulg, because Rev 12.18-Rev 13.1 is the same, so i do 
> ranges comparision in KJV to correctly bring NRSV.Rev.13.1 to VULG.Rev.13.1, 
> because KJV.Rev.13.1 = VULG.Rev.12.18-Rev.13.1
> 
> 66,  12,  18,  19,  13,  1,   0,
> 66,  13,  1,   1,   13,  1,   0,
> Note, there is also different parse order: to KJV we parse backwards from 
> last to first, from KJV - forward data table parsing (or vice versa, i do not 
> remember :^).
> 
> 
> Absent Books
> unsigned char mappings_nrsv[] = {
> 0,
> 66,  12,  18,  19,  13,  1,   0,
> 66,  13,  1,   1,   13,  1,   0,
> 0
> };
> This data contain of two parts, first in Book Names list, NULL terminated, 
> second is Mapping Rulles List, also NULL terminated. Here Book names is 
> empty, but for Vulg there is:
> unsigned char mappings_vulg[] = {
> 'E', 'p', 'J', 'e', 'r', 0,
> 'P', 'r', 'A', 'z', 'a', 'r', 0,
> 'S', 'u', 's', 0,
> 'B', 'e', 'l', 0,
> 0,
> ...
> It is absent book names in KJV, necessary to correctly transit with non KJV 
> v11ns. For example, KJV does not contain PrAzar, but we able to correctly 
> transit from Synodal to Vulg, because Synodal have following:
> 
> 
> 
> ...
> In cpp data we use book numbers above versification book count: like 
> refSys.getBookCount() + 1 = "Sus". In Synodal:
> unsigned char mappings_synodal[] = {
> 'P', 'r', 'A', 'z', 'a', 'r', 0,
> 'S', 'u', 's', 0,
> 'B', 'e', 'l', 0,
> 0,
> ...
> 26,  7,   2,   0,   7,   1,   0,
> 79,  3,   24,  0,   1,   1,   0,  35,
> We test if 79 is greater than getBookCount(), if so we take last number - 35 
> as current book and 79 as target book: 79 - getBookCount() = "PrAzar". 
> Chapter and verse data is used as always.
> 
> 
> Verse Shifting
> 21,  106, 0,   0,   107, 0,   0,
> 21,  107, 1,   2,   108, 1,   0,
> First line - Vulg Ps.106 = KJV Ps.107, it should be clear.
> Second Line: for whole chapter there is only one rule. I only need to declare 
> expansion or contraction, the rest of the chapter will be shifted, including 
> meta-versification space. Rules works on chapter level.
> 
> 
> In conclusion two things i would add. Probably v11n xmls should be converted 
> to OSIS format, i have no decision because i do not see advantages for now. I 
> plan to change cpp rules format to have first number equal to binary size of 
> the rule, this seem to me good tone and would bring backward compatibility 
> for if we ever have module supplied versification with mappings included.
> 
> Blessings.
> 
> 
> 2013/3/19 DM Smith 
> Konstantin,
> 
> Thanks very much for the work you've done.
> 
> I'm trying to understand the data structure. JSword is an independent 
> implementation and doesn't use SWORD libraries. So to implement something 
> like this, it'll be helpful to understand what the data structures and the 
> data means.
> 
> If I understand, you are using the

Re: [sword-devel] breakage in verse management at -r2785?

[DM Smith]

The presence or absence of a verse in a particular module should not matter. It 
should merely be a matter of whether the v11n defines it.

On Mar 22, 2013, at 5:02 AM, David Haslam  wrote:

> Has anyone tested how -r2785 manages for John 8 in the SBLGNT which omits the
> Pericope Adulterae?
> 
> In the SBLGNT module, John 8 starts at verse 12, and John 7 omits verse 53.
> 
> Question prompted by an unrelated bug reported for And Bible.
> 
> David


___
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] KJV 1611

[DM Smith]

I maintain the KJV 1769. This is frequently and mistakenly referred to as the 
1611 version.

You can see on the wiki Gen 1: http://www.crosswire.org/wiki/KJV_1611

We'd love to have the 1611 text but have not found a suitable etext. I'm 
looking for one that has the long 's' which looks like an f. If you know of 
one, let me know.

In Him,
DM

On Apr 11, 2013, at 1:29 PM, "Barnes, Jeffrey"  wrote:

> I've seen the objections to the AV on the Crosswire website.
> 
> Is there a 1611 Sword module available anywhere? It's interesting to see that 
> the OSIS tutorial uses 1611 text.
> 
> The poetry and flow of the version I find to be beautiful. It would be nice 
> to be able to get it as a Sword module instead of reading someone's comments 
> who doesn't appear to appreciate it like I do.
> 
> Regards,
> Jeff
> ___
> 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] KJV 1611

[DM Smith]

On Apr 11, 2013, at 4:14 PM, "Barnes, Jeffrey"  wrote:

> 
> On Apr 11, 2013, at 1:45:52PM, DM Smith  wrote:
> 
>> I maintain the KJV 1769. This is frequently and mistakenly referred to as 
>> the 1611 version.
>> 
> 
> Most of the folks in my circles who read KJV know the difference, although 
> many would not know the difference between 1769 and AKJV.
> 
>> We'd love to have the 1611 text but have not found a suitable etext. I'm 
>> looking for one that has the long 's' which looks like an f. If you know of 
>> one, let me know.
> 
> You mean U+017F? Seems like that would be a pretty easy regex. I think it's 
> only a lower case entry that appears only if it is not the last character in 
> a word. Any other glyphs?

Yes there are other glyphs. There is one for "and" (it is something like &) and 
another for "the" (an y with a e above). There are a few others but I don't 
remember them off the top of my head.

I think u017f is the long s (I don't have it memorized). Substituting non 
terminal s with it is fairly close but not quite there. A regex would not be 
accurate enough, imho.

In Him,
DM
___
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] Sword support of indents and line breaks

[DM Smith]

The ESV encoding into OSIS tried to retain the markup of the source. In the 
case of x-indent and x-indent-2, these are attributes on the  element. These 
should have been level="2" and level="3". In the next release of the ESV SWORD 
module, it is corrected.

I have a little bit more before it is ready for release.

IMHO, we should not support x-indent as used in the ESV module (nor any of the 
other x-yyy attribute values used in it, except as already present in the SWORD 
engine).

In Him,
DM Smith

On Apr 12, 2013, at 8:41 AM, David Haslam  wrote:

> It's notable that the ESV module includes these OSIS tags for indentation:
> 11334 x-indent
> 00021 x-indent-2
> 
> The question arises therefore, do we support these two eXtensions?
> 
> If not, then we are falling short of satisfying the publishers of the ESV.
> 
> If yes, then there should be no objection to also supporting  type="x-p-indent" /> elements that are used in the IBT modules, just as John
> has requested.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Sword-support-of-indents-and-line-breaks-tp4652140p4652149.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] Sword support of indents and line breaks

[DM Smith]

I think there are bigger problems to solve first. I think Troy alluded to this 
in his response that there is a need to fix the whitespace problem. I think 
this causes most of the differences you see when rendering in most SWORD 
frontends.

The whitespace problem is exacerbated in that osis2mod takes the BSP container 
model and converts the containers into milestoned elements so that a verse can 
be displayed in a different context than a chapter as a whole (two examples: 
with in a table cell, in a list of verses). In most (all?) frontends the user 
can also choose to start each verse on a line to itself, changing the entire 
notion of paragraphs.

Regarding line break, you noted the  element provides just that. 

Regarding paragraph formats, the  element does not define any. There is no 
notion of "justified", "indented", "line-spacing", "centering",  that most 
word processors provide. These have to use the type/subType attribute 
extension. And as you noted, SWORD does not support these. Chris has suggested 
that we could allow  as a way of handling this. I'd go a bit 
further and allow any type and subType x-yyy values on any element, to become a 
class attributes (without the x- ) on the resulting html element.

Regarding front-ends and paragraph display, most (all?) have a blank line 
between paragraphs, rather than indenting. A front-end might be able to make 
that a user choice.

In Him,
DM

On Apr 12, 2013, at 2:04 AM, John Austin  wrote:

> Sword should support basic indents and line breaks. Content providers should 
> be able to control the formatting of their texts and should not be required 
> to assign their content to artificial ... or other containers to do 
> so. Although these containers might be useful, the text of some translation 
> styles cannot be fit nicely into them. But often content providers do rightly 
> desire their texts to appear with formatting similar to their printed texts, 
> since this is exactly what the translators deemed easiest to read and 
> understand.
> 
> People who convert texts to Sword are often not at liberty to change the 
> source texts to do so, and source texts in strange languages come with many 
> unexpected language constructs. For these reasons it is important that Sword 
> tries to offer content providers a simple, reliable way of formatting their 
> own texts, without requiring them to fit into Sword's container scheme to do 
> so.
> 
> IBT of Russia is already using simple osis  
> and  to achieve all their formatting needs for their Sword modules. 
> Currently, only xulsword supports both of these. But perhaps they should both 
> be included in Sword's osis2html filters so that all front-ends can support 
> them. At least something very similar should be adopted, if there is a strong 
> reason not to adopt IBT's well tested method.
> 
> Hard spaces and other such formatting are not acceptable solutions because 
> they cannot be easily filtered. It is important that unformatted text can 
> easily be obtained from formatted text since there are many uses for 
> unformatted text, such as bookmark and cross-reference verse texts etc.
> 
> Here is one example to show why forcing containers on a text is not a good 
> idea. This is a section of SFM from the book of Ruth 1:8-12:
> 
> \v 8 Йўлда давом этишаркан, Наима иккала келинига деди:
> \p — Боринглар, икковингиз ҳам оналарингизнинг уйларига қайтинглар. Менга ва 
> марҳумларга бўлган иззат–ҳурматингиз учун Эгам сизларга ҳам марҳамат қилсин.
> \v 9 Икковларингизга ҳам яхши жойлардан ато қилсин, турмуш қуриб, ўз 
> эрларингиз билан бахтли бўлинглар!
> \p Шундай деб Наима келинларини ўпди, иккаласи эса йиғлаб фарёд кўтаришди:
> \p
> \v 10 — Йўқ, биз сиз билан кетамиз, сизнинг халқингиз орасида яшаймиз, — 
> дейишди.
> \v 11 Наима эса яна келинларига:
> \p — Қайтинглар, жон қизларим! — деди. — Мен билан кетганингиздан нима 
> фойда?! Қорнимда яна ўғилларим бормидики сизларга умр йўлдоши бўлса?!*
> \v 12 Бўлди энди, қизларим, қайтинглар! Мен энди кексайдим, эрга тегишга 
> ожизман. Борди–ю, мен, ҳали умид қилсам бўлади, деб шу кеча эрим билан 
> қовушсаму ўғиллар туғсам,
> 
> Here is a PDF of exactly what the translators designed this SFM to look like: 
> http://ibt.org.ru/russian/bible/uzb/otcyr/08%20Rut%20-%20Uzbek%20Cyrillic.pdf
> 
> And here is what it looks like in Sword format using only basic osis intents 
> and line breaks, rendered by xulsword's osis2html filter: 
> http://ibt.org.ru/en/text.htm?m=UZV&l=Ruth.1.1.1&g=0. As you can see, the 
> Sword module renders this strange (to us) formatting of text just like the 
> translators wanted.
> 
> However, now imagine trying to programmatically apply ..., ... 
> etc. constructs to the above SFM to achieve the same effect. The designers of 
> the SFM in this case are using the \p tag to represent a simple indent (not a 
> paragraph) in order to achieve their desired non-Western layout. One might 
> try and argue that the SFM designers h

Re: [sword-devel] Sword support of indents and line breaks

[DM Smith]

On Apr 12, 2013, at 11:37 PM, Chris Little  wrote:

> On 4/12/2013 12:12 PM, DM Smith wrote:
>> Regarding paragraph formats, the  element does not define any.
>> There is no notion of "justified", "indented", "line-spacing",
>> "centering",  that most word processors provide. These have to
>> use the type/subType attribute extension. And as you noted, SWORD
>> does not support these. Chris has suggested that we could allow > type="x-indent"> as a way of handling this. I'd go a bit further and
>> allow any type and subType x-yyy values on any element, to become a
>> class attributes (without the x- ) on the resulting html element.
> 
> This sounds like a great idea.
> 
> Some things to consider:
> 
> Should we necessarily strip the x-? I don't think keeping it harms anything, 
> but removing it looses the information that the type is a defined OSIS type. 
> Removing the x- also introduces the possibility of collisions (e.g. the note 
> types 'allusion' and 'x-allusion' would be mapped to the same class value), 
> but this might be a desirable feature.
> 
> Should types & subTypes be composed or listed? E.g., if a note has type 
> 'variant' and subType 'MT', would the class value be:
> 'variant MT'
> or something like
> 'variant|MT'. (I don't know whether | is necessarily a good character for 
> making compound classes.)

No problem keeping the prefix x-. Keeping it will minimize collisions and 
having duplicate selectors for a rule set is common in CSS.

Since this is a mapping of OSIS type and subType to HTML class, the CSS 
semantic should probably be used. This would have the values be separated by 
space. The character | is not an allowable for a CSS value.

In Him,
DM___
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] Sword support of indents and line breaks

[DM Smith]

I would add that the new HTML filter is a work in progress. It is moving to 
class attributes as a way to abstract presentation out of the filter.

This is goodness. I'd recommend that we take the OSIS spec and create a mapping 
of each element to the corresponding HTML element and class variables (i.e. a 
design doc, fancy that ;)

A full implementation would represent all OSIS in HTML and move presentation to 
the front-end, where it belongs.

In Him,
DM

On Apr 13, 2013, at 7:35 AM, Peter von Kaehne  wrote:

> Can I try and summarise what I think is going on here?
> 
> Basis of problem:
> 
> 1) CrossWire has a whitespace/title/poetry problem which has been
> discussed at nauseam for many years. But it has neither been thoroughly
> resolved nor even isolated. Various parties have blamed each other -
> module makers, osis2mod maintainer, filter maintainer, frontend
> developers (and maybe others, including bystanders) DOI - module maker
> and happy to blame anyone, including myself as long as it finally
> improves.
> 
> 2) IBT had a specific need and had someone in their midst willing to
> cater to that need, using our CrossWire's efforts but was miffed by
> problem (1)
> 
> 3) IBT - outside of the Wycliffe/UBS "tradition" of using Paratext - has
> developed it own use of USFM with specific rules about markup, sometimes
> breaking semantic rules.
> 
> The problem grows:
> 
> 4) IBT's lead programmer decides to solve IBT's immediate problem by
> applying his own patches to sword and maintain his own version of
> libsword and OSIS with little or no communication with Sword people and
> no attempt to isolate and solve the underlying problem (1) either.
> 
> The problem becomes apparent:
> 
> 5) People in IBT's area start to use smartphones and Mac's and
> subsequently IBT's offer of xulsword is not sufficient anymore - making
> (1) obvious to everyone and letting (4) fail.
> 
> The problem becomes a bunfight:
> 
> 6) Instead of looking at (1), (2) and (3) respectively and finding both
> the remaining whitespace bugs + fix IBT's "dodgy" USFM encoding we are
> fighting for two positions which are actually both not particularly
> good.
> 
> I note John's recent email which says that translators do not understand
> and/or care about semantic markup, just how it looks like and that it is
> understandable. I think this is fair enough - only the "understandable"
> varies from platform to platform. What is understandable on paper will
> not work on gobible and will create a mess in other places too. So, as
> computer people it is our job to find the patterns and encode the
> patters correctly, semantically, including on occasion feeding back to
> the translaters - "yes, I know what you want to achieve, but _this_ is
> the way you should encode it, we will fix the presentation afterwards."
> 
> The  element is indeed intended to encode translater intent
> for the odd and bizarre. But IBT's desire is not odd and bizarre. Only
> its solutions are. A lot of times when the  is used there are
> perfectly adequate structural OSIS elements available - q, p, div,
> poetry markup and a few more. A few milestones will subsequently maybe
> still remain. But not even 10% by my reckoning. 
> 
> On CrossWire's side though we need 
> 
> a) the ability to add per language or per module the means (maybe CSS?_
> to ensure that certain language conventions which are necessary for
> readability do not fall foul of our (mis)understanding how certain
> structures should look like. If a language requires that e.g. a 
> element is not just encoded with a ", but will include a linebreak, an
> indent, a longdash and a few more things at the beginning and some
> others at the end, then this should be acceptable and reproducible.
> Routinely and easily.
> 
> b) a final push to get the USFM/OSIS/module witespace/interverse
> content/intraverse extra content/title etc mess sorted. 
> 
> 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] Sword support of indents and line breaks

[DM Smith]

On Apr 13, 2013, at 9:24 AM, Nic Carter  wrote:

> 
> On 13/04/2013, at 11:09 PM, DM Smith  wrote:
> 
>> I would add that the new HTML filter is a work in progress. It is moving to 
>> class attributes as a way to abstract presentation out of the filter.
>> 
>> This is goodness. I'd recommend that we take the OSIS spec and create a 
>> mapping of each element to the corresponding HTML element and class 
>> variables (i.e. a design doc, fancy that ;)
>> 
>> A full implementation would represent all OSIS in HTML and move presentation 
>> to the front-end, where it belongs.
> 
> Having looked briefly at this, I gave up. I couldn't figure out how to deal 
> with the BCV model output, given that the input is the other model. At least, 
> to me it seemed like we needed a major refactoring of how the filters work. I 
> think it was BPBible that I was looking at that had done things quite 
> differently to handle this? But given we have both the need to be able to 
> correctly display a single verse by itself as well as a verse in it's 
> context, it appeared that the filters needed some sort of state saved so we 
> knew what sorts of containers we are currently in and which we are currently 
> not in?
> My understanding led me to realise that  was the wise choice to use 
> throughout the filters, rather than trying to deal with opening and closing 
>  markers depending on how many verses in context were currently being 
> displayed?
> 
> But this is just my quick interpretation based on trying to add bits and 
> pieces to the filters over the last three years... Which reminds me, did I 
> ever submit a patch for getting OSIS underline working in osishtmlhref?
> 
> My quick 2 cents...  :)
> 
> 
> Thanks, ybic
>   nic...  :)
> 
> ps: sure, this may just be a challenge for someone to prove how wrong I am 
> and how quick and easy it is to get this all working properly?

Don't you love it when a thread gets hijacked! ;)

As the maintainer of osis2mod I've been thinking about this for years. It is 
not an easy problem to solve.

Recently, I've been coming to the conclusion that we need two filters (or a 
context flag) to distinguish between display of verse in context and verse in 
isolation.

The basic difference between the two is that inter-verse vertical whitespace is 
nearly eliminated for verse in isolation.

The problem of verse in isolation is that it is used in a context where the 
verse may have begin tags w/o end tags or visa versa.

osis2mod solves this by converting from BSP to BCV. If osis2mod did not do this 
(leaving the doc as BSP) but left it to the filter to close or remove these 
when used in isolation, this would help.

I'm working on JSword to allow this.

In Him,
DM


___
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] Sword support of indents and line breaks

[DM Smith]

We're getting off topic. But yes, the NT was all caps, no diacritics, no 
punctuation, no verse numbers, no chapter numbers and *no spacing between 
words*. 

Thai does not space words.

In Him,
DM 

On Apr 14, 2013, at 8:14 AM, Trevor Jenkins  
wrote:

> 
> On 14 Apr 2013, at 13:11, Arthur Bolstad  wrote:
> 
>> I'm sure if you ask your translators, they will tell you that the spaces 
>> between words mean something! Word boundaries tell you how intonation 
>> affects the gathering of syllables for example:  blackbird vs black bird is 
>> spoken differently in English.  You convince me that there is meaning the 
>> linguist is trying to express.
> 
> Aren't the early source manuscripts run on with no inter word spacing?
> 
> Regards, Trevor.
> 
> <>< Re: deemed!
> 
> 
> ___
> 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] Log error suggest a module issue?

[DM Smith]

Chris,

There is no issue with UKJV, per se.

osis2mod preserves all module markup, perhaps transformed, except the  
element. Earlier versions of osis2mod did not transform the  element 
to its milestoned version.

This should be considered JSword's problem to deal with, which is what JSword 
is doing. Whenever JSword encounters a "verse" (in this case verse 0) it uses 
an xml parser to convert the text into DOM. All xml parsers require well-formed 
xml and are required to fail when otherwise. When JSword encounters an error in 
its assumption, it reports it and then strips xml from it.

We have an open issue to do a better job with the handling of broken xml.

There are a couple of improvements:
Gather the text to display and convert all of it, instead of converting each 
verse one at a time. This recognizes that a tag opened in one verse may be 
closed in another. However, it does not work for "verse in isolation" (search 
results, lookups, parallel viewing, ...)

Use a "lenient" xml parser (by definition there is no such thing) to repair 
text to be well-formed. I found Flying Saucer and jsoup, which look promising.

The other possibility is to not use an xml parser at all to create the DOM but 
to do it with our own parsing (like we do for GBF and ThML).

I'll cross-post this to JSword-devel, as that is where this belongs.

In Him,
DM


On Apr 15, 2013, at 4:15 PM, Chris Burrell  wrote:

> Hi all
> 
> There is perhaps an issue with the UKJV module. My logs show me:
> 
> 2013-04-15 20:31:30,236 INFO   - UKJV:Exo 21:0: Parse UKJV(Exo 21:0) failed: 
> Error on line 1: The element type "chapter" must be terminated by the 
> matching end-tag "".
> 
> Cheers,
> Chris
> 
> ___
> 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] Generating / displaying Sword

[DM Smith]

On Jan 12, 2013, at 4:26 AM, ARA Jamieson  wrote:

> I'm a newbie with OSIS / Sword, so apologies if this is a dumb question or
> I'm posting it to the wrong place.
> 
> I'm currently converting USX to OSIS using my own processing, then using
> osis2mod.pl

I'm not familiar w osis2mod.pl. Is this a wrapper around osis2mod? If it is not 
calling SWORD's osis2mod then all bets are off on getting a good answer.

To provide an accurate answer (not sure if that is needed) it may be helpful to 
know the version of osis2mod and the version of xiphos and the OS that you use.

I think USX is a variant of SFM? If so, the wiki entry might be helpful:
http://www.crosswire.org/wiki/Converting_SFM_Bibles_to_OSIS

> to generate Sword, and then displaying the results using Xiphos
> on PC.  As a test, before I start with non-English language texts, I'm
> working with a copy of the King James Version, since it makes it easier to
> see what's going on.  The first few hundred characters of the OSIS appear
> below :-
> 
>   
>   
>osisRefWork='TESTKJVBible' xml:lang='en' canonical='true'>
>   
>   
> 
>   
>
> short='Matthew_A'>Matthew_B
>Matthew_C 
> Matthew_D
> The Gospel
> According to St. Matthew  
> 
>   sID='Matt.1.1' /> The book of the generation of Jesus Christ, the son of
> David, the son of Abraham. 
>  sID='Matt.1.2' /> Abraham begat Isaac ...
> 
> (I've hacked this manually a bit, because I needed to distinguish the
> various occurrences of "Matthew" in the output to help me understand what
> was coming from where.)
> 
> I thought this was in line with the OSIS spec.

If you ran it through an xml validator, providing the schema, then it is in 
line with the spec. That doesn't mean that it is proper OSIS (see answer to 
last numbered question) That doesn't mean that it plays well with any SWORD 
frontend.

> , but maybe it isn't, because
> Xiphos isn't display what I might have expected / hoped for - at least when
> it comes to chapter headings and titles ...

There are problems in the SWORD engine when it comes to whitespace differences 
when toggling headings. It doesn't appear that is your question. So I'll skip 
past that at this time.

Also, I suggest getting the nightly build of Bible Desktop. It handles the text 
differently than xiphos as it is based on JSword not SWORD. It should help you 
understand your markup better. Please note that JSword does not set the 
standard for display of a SWORD module. xiphos is a lot closer to what would be 
considered standard.


> 
> 
> 
> 1."Chapter 1", along with the "1" for verse 1, come out before any of
> the headings.

Most SWORD (and JSword) frontends create their own headings. It appears that is 
what is happening here, since you don't provide a title "Chapter 1" in your 
text. For Bible Desktop (a JSword frontend), our next release will be styling 
these differently so that it is obvious to developers.

Originally a SWORD module consisted only of verse text. So manufactured titles 
were very reasonable. Some more recent texts include titles. This means that 
frontends may duplicate that effort.

>   
> 2.I'm seeing an awful lot of headings - Matthew_B, Matthew_C,
> Matthew_D and "The Gospel ...".  I assume this means I'm generating too many
> "title" tags, but I'm not sure which of these I can safely get rid of.

All text will be displayed to the user at some point. If it is in a note or 
title, there is a toggle for that. If you don't want text to appear, then don't 
include it in your module.

You may want to move some of your titles to an attribute on the element, if 
supported. Our KJV does that.

Titles at the beginning of a book or chapter are put into verse 0 or verse 1 
depending on how it is marked up. There are two pages in our wiki that'll help 
you understand how to control that:
http://www.crosswire.org/wiki/OSIS_Bibles
http://www.crosswire.org/wiki/Osis2mod

> 
>   
> 3.I'd assumed that the "tableOfContents" tag was used to mark the
> place in the text to which a table of contents should point.  Is this
> correct?  If so, clearly I'm using it wrongly, because Matthew_C is being
> displayed rather than simply being used internally to sort out the linkage.

SWORD does nothing special with a table of contents per se. It is merely marked 
up text. While the default, the div should have canonical="false" on it. It 
should be put into chapter 0, verse 0 (by osis2mod) and probably will toggle 
with the heading. This would be the expected behavior.

>   
> 4.I'm wondering about the fact that I have two s.
> The first of these is there because we genuine

Re: [sword-devel] TanakhML Project

[DM Smith]

Have you checked the internet wayback machine (http://archive.org/web/web.php)? 
It is very useful in finding the old page, grabbing text from it and looking 
for it's new home.

On Oct 22, 2012, at 4:32 AM, DavidIB  wrote:

> I've found this very useful in the past, but today I find it is dead.
> Does anyone know if it is (or will be) resurrected elsewhere?
> 
> David IB
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/TanakhML-Project-tp3972321p4651195.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] XHTML Rendering of OSIS Reference Doc - Whitespace

[DM Smith]

+1

I agree that OSIS uses divs in a different manner than HTML. IMHO, they should 
be ignored.

We've outlined best practices regarding div in the wiki. They bound Bible, 
testament, book, chapter and section. Regarding the first four there is no 
reason to introduce any whitespace. Regarding sections, the recommendation is 
that the content of a section has a title and possibly paragraphs, tables or 
poetry. If any of these are present at the start of a div then appropriate 
whitespace is (should be) introduced.

osis2mod also introduces a "pre-verse" div which merely marks the beginning and 
the end of where content coming before the verse is located. These divs should 
never be rendered in any fashion.

I think this will solve the majority of the whitespace issues.

The other vertical whitespace issues regard poetry, especially the  
element, and verse per line rendering (and other verse in isolation conditions).

Regarding horizontal whitespace, if it hasn't been done already, there should 
be some respect to the level attribute on an  element, at least as a HTML 
class attribute.

In Him,
DM

On May 9, 2013, at 7:01 AM, "Troy A. Griffitts"  wrote:

> 
> 
> On 05/08/2013 12:31 PM, Troy A. Griffitts wrote:
> 
> OK, so from this:
> 
>>  Old Testament > sID="gen2" type="book"/> THE FIRST BOOK OF MOSES CALLED GENESIS 
>>  Introduction and Outline  
>> This is the Book of Genesis, the first book in the Bible. It 
>> may be outlined as follows:   1Creation of Heaven 
>> and Earth, 1:1-2:4a 2Creation of Man and Woman, 2:4b-25 
>> 3Fall, 3:1-24 ...   Tables work 
>> like this: Column 1 Label Column 2 Label Column 1, Row 1 
>> Column 2, Row 1 Column 1, Row 2 Column 2, Row 2 > type="section"/>
>>  From Creation to Abraham 
>> (1:1–11:9)
>> [ Genesis 1:1 ] In the beginning God created the heaven and the earth. 
>> [ Genesis 1:2 ] Text of verse 2.
> 
> As a first run, I'm going to shoot for this below.  Will this make everyone 
> happy regarding whitespace?  Please ignore the poor table output-- that 
> another issue.
> 
> Old Testament
> 
> THE FIRST BOOK OF MOSES CALLED GENESIS
> 
> Introduction and Outline
> 
> 
> This is the Book of Genesis, the first book in the Bible. It 
> may be outlined as follows:
> 
> 
>1Creation of Heaven and Earth, 1:1-2:4a
>2Creation of Man and Woman, 2:4b-25
>3Fall, 3:1-24
>...
> 
> 
> 
> Tables work like this: Column 1 Label Column 2 Label Column 1, 
> Row 1 Column 2, Row 1 Column 1, Row 2 Column 2, Row 2 
> From Creation to Abraham (1:1–11:9)
> 
> [ Genesis 1:1 ] In the beginning God created the heaven and the earth. 
> [ Genesis 1:2 ] Text of verse 2.
> 
> 
> 
> 
> Really, thanks for all the feedback on the removal of the divs and otherwise. 
>  I am sorry to force this thread to concentrate on an immediate solution for 
> release.  I'm happy to talk future solutions and value your input for those.  
> I just need your help on this solution right now.
> 
> Nic, regarding round-trip, the OSISXHTML Render filter wouldn't be used for 
> the round-trip.  We would use the OSISOSIS filter for that (it goes from 
> "SWORD annotated OSIS" (like the x-preverse stuff and any other augmentation 
> we might make in the markup to help with our on-demand internal processing) 
> -> OSIS proper.  So, we can strip the divs out in the OSISXHTML Render filter 
> and not worry about breaking the round-trip.
> 
> Thanks for the input!
> 
> Troy
> 
> ___
> 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] Synodal versification & IBT modules?

[DM Smith]

We have many modules whose scope does not match the versification. E.g. NT 
Bibles, translations with a book or two. Having an adaptive list of books based 
upon the modules being viewed is the way to go.

Chris Burrell added some code to JSword that allows for the quick determination 
of whether a verse is present in a module. He is using this in STEP to prune 
the v11n to only those books, chapters and verses that are actually present. On 
old slow hardware he reported that it is very fast to analyze an entire module.

Given that C++ is even faster than Java, I'd suggest such a mechanism for SWORD 
lib.

So, I concur with Chris L but for different reasons.

In Him,
DM

On May 11, 2013, at 5:28 PM, David Haslam  wrote:

> Did IBT's programmer actually know that you'd provided it during the period
> in question?
> 
> It might just have been not used due to his excessive workload, or other
> factors affecting his situation.
> 
> If we have Luther and German as two similar cases, why balk at SynodalP?
> 
> IMHO, the argument against it is flimsy.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Synodal-versification-IBT-modules-tp4652282p4652284.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] Synodal versification & IBT modules?

[DM Smith]

JSword (Java) is quite different from SWORD (C++). But I'll give you an 
overview. Each module has a similar structure. There is an index file where 
slots have records indicating offset and size into a data file. For a Bible 
module, each slot represents a verse.

If the size is 0 then that indexed location is empty. A compressed module is 
slightly more complicated. The index consists of two parts. But the idea is the 
same. If the length of the data is 0, then it is empty.

Basically if you look at the chain of calls to get the raw text of a verse, it 
digs down and at some point it gets the data size. Our code merely bails once 
it gets the data size.

I can point you to our Java code, if you like, but I don't know how much that'd 
help.

In Him,
DM

On May 12, 2013, at 9:53 PM, Nic Carter  wrote:

> 
> Hi DM,
> 
> On 12/05/2013, at 7:40 AM, DM Smith  wrote:
> 
>> Chris Burrell added some code to JSword that allows for the quick 
>> determination of whether a verse is present in a module. He is using this in 
>> STEP to prune the v11n to only those books, chapters and verses that are 
>> actually present. On old slow hardware he reported that it is very fast to 
>> analyze an entire module.
> 
> Could you please let me know where this is? Would be interesting to look at 
> and see how it performs on a handheld in C++ or Obj-C :)
> 
> Thanks heaps, ybic
>   nic...  :)
> 
> ps: I don't know the JSword codebase at all, so it may be easier if I'm 
> pointed in the right direction rather than trying to find it :)
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page


___
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] Synodal versification & IBT modules?

[DM Smith]

More:
Once that is written, the worst case for analysis is a book that is entirely 
absent. Basically, when you find something from a book, you don't need to look 
any further in the book and go to the next.


On May 12, 2013, at 10:06 PM, DM Smith  wrote:

> JSword (Java) is quite different from SWORD (C++). But I'll give you an 
> overview. Each module has a similar structure. There is an index file where 
> slots have records indicating offset and size into a data file. For a Bible 
> module, each slot represents a verse.
> 
> If the size is 0 then that indexed location is empty. A compressed module is 
> slightly more complicated. The index consists of two parts. But the idea is 
> the same. If the length of the data is 0, then it is empty.
> 
> Basically if you look at the chain of calls to get the raw text of a verse, 
> it digs down and at some point it gets the data size. Our code merely bails 
> once it gets the data size.
> 
> I can point you to our Java code, if you like, but I don't know how much 
> that'd help.
> 
> In Him,
>   DM
> 
> On May 12, 2013, at 9:53 PM, Nic Carter  wrote:
> 
>> 
>> Hi DM,
>> 
>> On 12/05/2013, at 7:40 AM, DM Smith  wrote:
>> 
>>> Chris Burrell added some code to JSword that allows for the quick 
>>> determination of whether a verse is present in a module. He is using this 
>>> in STEP to prune the v11n to only those books, chapters and verses that are 
>>> actually present. On old slow hardware he reported that it is very fast to 
>>> analyze an entire module.
>> 
>> Could you please let me know where this is? Would be interesting to look at 
>> and see how it performs on a handheld in C++ or Obj-C :)
>> 
>> Thanks heaps, ybic
>>  nic...  :)
>> 
>> ps: I don't know the JSword codebase at all, so it may be easier if I'm 
>> pointed in the right direction rather than trying to find it :)
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> ___
> 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] Synodal versification & IBT modules?

[DM Smith]

I don't think the SWORD v11n allows for starts other than 1 nor for numbering 
out of order. In the v11n there is merely verse counts per chapter.

In Him,
DM

On May 14, 2013, at 8:34 PM, jonathon  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 05/13/2013 11:34 AM, Костя Маслюк wrote:
>> No need to introduce new functions because last chapter would be always 
>> calculated via getChapterMax().
> 
> For Greek Esther, that approach is always going to fail.
> 
> The first verse of Greek Esther is Esther 10:2.
> The last verse of Greek Esther is Esther 10:1.
> Alternatively, the v11n scheme starts with I:2, and ends with I:1, or
> starts with I:1, and ends with VI:3.
> Then there are the other schemes, that are equally non-sequential, but
> typically the last chapter is not the highest numbered chapter.
> 
> The other point of failure of that approach is Esther 9:19/9:19a.
> 
> jonathon
> - -- 
> Email with a precedence of other than "junk", "bulk", or "list" is
> automatically forwarded to Dave Null. Those emails will never be seen by me.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJRktgYAAoJENBziGtNrBEnqPIIALTmvi7ewKu9OxHwDblCW2CP
> sZROUnRoX7wkOgxLyA+pO0N1OdPWZzh/LNE4j2GfMdSmug8F9XIuvOZsm7dNiZHK
> WqaZ/p2/2HrKvK8BzSmjDEfvXWVO56olaoFLFEic7V27Bwe39zVnAfb2pVU/5hCa
> BvqO+/iZUQHh/coUyPFyzAhVn4r/Ke0I4Ahvt3/lDizOoi4ZRvvGDiCIsDeIxb25
> HA/bROPfLlCo2AMELlFmpSGmI6aO9mb+kxbEWQK0Y47I/z1m11O+PWB/OFhBSaMI
> Rc8zYZWLfaiAbS1MR5l9arCv3bT9Bl9lF73k9+n5MOLF469B5gfuWeVEpaT5Omg=
> =qDqq
> -END PGP SIGNATURE-
> 
> ___
> 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] XHTML Rendering of OSIS Reference Doc - Whitespace

[DM Smith]

David,
You've brought up 3 issues here. Two should be on separate threads.

Regarding rendering of titles, an OSIS  should be transformed into a 
, , ...  element by the SWORD api when rendered to (x)html. If it 
is, then it will be rendered as a block element and not on the same line. If it 
does not then this thread is an appropriate place to discuss that. Please note, 
this thread regards the new xhtml filter, not the current filters. But I think 
this statement is true of the current html filter.

If usfm2osis.py does not transform USFM titles into an OSIS  then all 
bets are off. This is the only element which osis2mod considers to be a title. 
If it does not, please bring up this on a new thread.

The placement of titles in the prior verse has nothing to do with the SWORD 
rendering of a module into (x)html. It is a problem with the interaction of 
your module source and osis2mod. It is osis2mod that chunks the input into 
verses. SWORD api merely grabs what has been stored in the module and renders 
it.

If you can provide (in a new thread please), an example of your problem we can 
proceed. In that new thread, I'll explain (yet again) how osis2mod handles 
ambiguity in input regarding headings (titles and intros). Ultimately that 
should go into the wiki for OSIS Bibles. It will also apply to commentary 
modules.

In Him,
DM

On May 17, 2013, at 7:41 AM, David Haslam  wrote:

> Vertical whitespace is one thing - I've certainly seen several modules in
> which the display has too much of it.
> 
> But surely a related issue is that the titles in OSIS files generated by
> usfm2osis.py don't even end up with new line when the OSIS is converted to a
> module using osis2mod 
> 
> As Chris's stated aim has been to produce "best practice" OSIS XML, it
> shouldn't be too much to expect that both SWORD & JSword would know that a
> title element requires at least a new line, such that it does not get
> appended to the end of the previous verse text.
> 
> This applies to titles of all kinds: section titles, parallel passages,
> acrostic titles, and major section titles, etc., etc.
> 
> I'll restrict my message to this one point - yet there are many other
> frustrations that module makers face whenever they attempt to get one to
> work properly in more than one front-end.
> 
> David
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/XHTML-Rendering-of-OSIS-Reference-Doc-Whitespace-tp4652262p4652308.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] XHTML Rendering of OSIS Reference Doc - Whitespace

[DM Smith]

Regarding your  rule. I think it is generally good. But I'm wondering 
whether the rule should be that 3 or more are condensed to two (instead of 2+ 
into 1).

I think regarding titles, most HTML renders them with extra vertical whitespace 
(half line above and below), so it'd be good to consider it as 2 high.

In looking at the  issue again. There is one use of  that is 
non-standard.

In OSIS,  is the only document level container that cannot be milestoned. 
osis2mod replaces ... with ..., where xxx is unique in the doc. (Ostensibly, this 
is bad OSIS, which Chris has aptly pointed out.)

These should produce vertical whitespace.

In Him,
DM

On May 29, 2013, at 11:53 PM, "Troy A. Griffitts"  wrote:

> Just checked in another update for the whitespace issues.
> 
> This checkin attempts to track vertical whitespace by counting block and 
>  output and mutes more than 2 contiguous vspace directives.
> 
> e.g., This was changed in the osisReference output:
> 
> 
> 
> 
> 
> to:
> 
> 
> 
> 
> Question: should  directives be automatically considered 2 vspace.  I 
> am only counting them as 1 right now. e.g., should
> Title
> 
> 
> be changed to simply:
> 
> Title
> 
> ?
> 
> I'm thinking so, but other 'block' tags I'm only ++ the vspace counter.  It's 
> simply enough to +=2 the counter for  tags.
> 
> Hope I didn't break too much.
> 
> Troy
> 
> 
> 
> On 05/21/2013 05:55 PM, Troy A. Griffitts wrote:
>> Thanks for the feedback Peter. I'm not sure I understand what you mean. 
>> Could you give me a line in the OSISReference document which you feel is not 
>> rendered well.
>> 
>> I just checked in an update which has preliminary support for tables, sub, 
>> and super. Here's the latest output:
>> 
>> Old Testament
>> 
>> THE FIRST BOOK OF MOSES CALLED GENESIS
>> 
>> Introduction and Outline
>> 
>> 
>> This is the Book of Genesis, the first book in the Bible. It 
>> may be outlined as follows: 
>> 
>> 
>> 1Creation of Heaven and Earth, 1:1-2:4a
>> 2Creation of Man and Woman, 2:4b-25
>> 3Fall, 3:1-24
>> ...
>> 
>> 
>> 
>> Tables work like this: 
>>  Column 1 Label Column 2 Label 
>>  Column 1, Row 1 Column 2, Row 1 
>>  Column 1, Row 2 Column 2, Row 2 
>> 
>> 
>> 
>> From Creation to Abraham (1:1–11:9)
>> 
>> 
>> Creation of the Heavens and the Earth
>> 
>> 
>> 
>> [ Genesis 1:1 ] In the beginning God created the heaven and the earth. 
>> 
>> 
>> 
>> [ Genesis 1:2 ] Text of verse 2.
>> 
>> 
>> 
>> 
>> On 05/20/2013 07:31 AM, Peter von Kaehne wrote:
>>> On Sun, 2013-05-19 at 22:29 -0700, Troy A. Griffitts wrote:
 OK, so here's my latest cut at the whitespace issue.  From the
 osisReference document here:
 
 http://crosswire.org/svn/sword/trunk/tests/testsuite/osisReference.xml
 
 ... we now get this output from the osisxhtml filter set when rendering
 module top until Gen.1.2 (not the greatest output, but I believe a great
 step forward, any comments?):
>>> Ok, I like what you have done. Question:
>>> 
>>> chapter group titles (Psalm 1-40, Sermon on the mount etc) and
>>> subsection titles are not catered for, or did I miss this?
>>> 
>>> 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
> 
> 
> ___
> 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] Bible book introductions

[DM Smith]

I'm thinking of having a "sidecar" conf for a module. Right now when a user 
wants to save certain settings for a module, we (JSword) modify the conf. (I.e. 
CipherKey and Font).

This could then be used to save anything a front end discovers and does not 
want to discover a second time. Such as Scope (which to my recollection was not 
shot down), Introductions, Colophons, user settings(?)

The basic idea is that the engine (JSword in my case) would read the conf and 
then the sidecar for the module, merging into a single internal representation 
of the conf. That way the module's conf would be then kept pristine.

In Him,
DM Smith

On Jun 3, 2013, at 8:03 AM, Nic Carter  wrote:

> 
> I think (& I hope?) what is being proposed is a method in Sword that will 
> check any book of the Bible to see if it is empty or not. This will 
> ultimately be very fast, as it may need to test a large number of verses?
> This same method should be able to be adapted to live-test introductions for 
> books &/or testaments? Then you could determine whether or not to allow such 
> a preference/toggle? Also, then you could tell which introductions should be 
> navigable to?
> 
> FYI, in PS I simply don't show options for modules that don't support a 
> feature. Why show a greyed-out Strong's Numbers toggle in the NET, for 
> example? Or Greek accents toggle for any English-language module? But, 
> obviously, this is a design decision :) :)
> 
> BTW, I believe we're still waiting to hear whether or not an 
> isEmpty(BookName) method is going to be incorporated into Sword? I'm 
> interested in it, but I was just reminded that PS still doesn't support 
> GenBooks & thought I might actually rectify that rather than look into an 
> isEmpty() implementation... ;)
> [yes, Karl, you requested it about 3.5 years ago, & I'm looking at the 
> redesigns required to make this happen!]
> 
> Just my thoughts :)
> ybic,
> Nic :)
> 
> Sent from my phone, hence this email may be short...
> 
> On 03/06/2013, at 21:04, Chris Burrell  wrote:
> 
>> For clarity, my use case is as follows. 
>> 
>> I have a menu displaying options such as Verse numbers, Headings, Verses on 
>> New Lines, Red letters. I'd like to add an option called Introductions (and 
>> perhaps one called Colophon).
>> 
>> The options in this menu are grayed out when the underlying module doesn't 
>> support this. If the option is grayed out, I add an explanation as to why 
>> that is (e.g. the module doesn't support it, or 1 option is not compatible 
>> with another option that is already selected, etc.)
>> 
>> The availability of the options is uniquely dependant on which version of 
>> the Bible or Commentary a user has selected. If a user selects a different 
>> module, the options available to him are updated automatically. For example, 
>> a user is clearly aware that most of the Old Testament doesn't have a Red 
>> Letter option. He might however work mainly from the ESV and want his 
>> frontend to show Jesus's words in red when they are in the text, so he sets 
>> up the option once. 
>> 
>> At this stage, we don't care about what passage/text a user is going to 
>> lookup. We can't guess what's in his mind! And we can certainly not guess 
>> what he's going to lookup tomorrow, the day after tomorrow, next month, next 
>> year.
>> 
>> This is the same for Introductions & Colophons. He might decide he's never 
>> interested in seeing Introductions and Colophons and want to turn them off 
>> completely. Or on the other hand he might want to turn them on all the time 
>> because he is always interested in them. 
>> 
>> But a toggle button available to turn the introductions on/off is pretty 
>> pointless if the module doesn't have any. In actual fact, it's pretty 
>> annoying because it looks like there may be a bug, since in the ASV toggling 
>> this option never makes a difference. In the same way a toggle button to 
>> turn red letters on/off for the ASV is pretty useless as well.
>> 
>> It should be obvious by now that having Sword/JSword being able to tell a 
>> frontend whether or not Introductions are contained within a module is a big 
>> plus to what we have now.
>> 
>> Chris
>> 
>> 
>> 
>> On 3 June 2013 07:26, Chris Burrell  wrote:
>> One could apply your reasoning for every option we have in the Conf file so 
>> far.
>> 
>> Headings, notes, cross references, strongs, morphology... A verse or chapter 
>> is not guaranteed to contain any 

Re: [sword-devel] Bible book introductions

[DM Smith]

I saw that Scope was yanked from the wiki with a comment that it had been 
rejected. I really don't remember it being rejected. I just remember that the 
discussion never went anywhere so it was dropped. I documented the desire of 
that discussion by putting an entry into the wiki. Even if engine support is 
given for determining this by examining a module, it will be far slower than 
having a declaration in the conf. On phones (low powered devices), such 
discovery is much too expensive and needs to be cached on a per module basis so 
that it is not recomputed.

I still think that it is very needed. I'm getting tired of how such discussions 
go.

I'm not at all clear why NoParagraphs was added as a Feature for the frontends 
to use. I don't remember any discussion of it here. I don't see the need for 
it. A frontend can examine each and every verse to see if there is paragraphing 
or other such structural elements that imply paragraphing. I have no intention 
of using it for the KJV. At least not without community discussion and buy-in.

How is NoParagraphs any different than NoIntroductions (or Introductions) !

In Him,
DM Smith 

On Jun 2, 2013, at 5:47 PM, Chris Little  wrote:

> On 6/2/2013 9:23 AM, Chris Burrell wrote:
>> Hi
>> 
>> Some books have Bible introductions. Can I suggest adding a flag to the
>> conf file to indicate this is the case? In the similar mindset as a
>> previous post, I'd prefer being able to query the conf file for features
>> of a particular module rather than having to read part of the module and
>> hope for that particular book/chapter to have an introduction. A yes/no
>> flag in the .conf file would be helpful.
>> 
>> (In particular, I have in mind the book introductions that are part of
>> the ESV text). But no doubt other modules will also (or in the future
>> will also) have the same aspects.
>> 
>> Chris
> 
> I would say no. This doesn't add anything.
> 
> Identifying that a module possesses introductions at some level does not 
> indicate that it possesses all of the introductions at that level. 
> Accordingly, knowing that a module possesses introductions still requires 
> checking for non-empty contents in order to know that a particular 
> introduction is non-empty.
> 
> This is along the lines of the request for a Scope .conf entry, which was 
> already rejected. Whatever solution is used for that case can also be used 
> for introductions.
> 
> --Chris
> 
> 
> ___
> 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] Bible book introductions

[DM Smith]

On Jun 3, 2013, at 10:43 AM, Greg Hellings  wrote:

> 
> 
> 
> On Mon, Jun 3, 2013 at 7:32 AM, Chris Burrell  wrote:
> I thought of that - but then that means that low powered devices, or devices 
> with large numbers of modules have to scan every part of every module on 
> installation of the module while they do their discovery process.
> 
> The Scope was related to Copyright & Distribution, but I'm not sure a 
> discovery approach would work. The idea here is that the data doesn't exist, 
> and the conf file was suggested as the place to store it. We can't derive 
> that very easily from the module contents.
> 
> I'm curious what this option would represent for Introductions. You're 
> talking about checking ~70 string values for empty either at module load time 
> or at module install time (and then adding some sort of cache value). Even on 
> a low-powered device, reading 70 entries is not going to be a cumbersome time 
> waster if done once at module installation.
> 
> In terms of computation, this is nowhere near some of the heavier checks 
> where time is being saved looking for every possible Jesus quote for markup 
> or the like.

> 
> --Greg

It is far more than 70. Every chapter can have an introduction. To see if a 
module one would have to check every verse 0 for text content. It is not 
sufficient to see if it has content. It may only have structural content. So 
that means it will have to be parsed for text.

Worst case is a module that does not have introductions. One would have to 
check every verse 0. If all that is wanted is to know whether a module has at 
least one introduction, the code can stop having found the first one.

Also, non-canonical, non-title content can appear anywhere. It is quite 
possible for there to be section introductions. AFAIK, we just haven't had any 
modules with that. (But I have paper study bibles with that feature.) So that 
would mean that every verse would have to be checked to see if it has pre-verse 
content with introductory material.

-- DM

>  
> 
> Another example, was my previous thread on having a marker indicating the 
> type of strong numbers used (e.g. following the Septuagint in the OT, or the 
> Hebrew). I'm still after a solution on that (although I believe we did decide 
> to add a flag for those modules - can't recall exactly now).
> 
> Chris
> 
> 
> 
> On 3 June 2013 13:16, DM Smith  wrote:
> I'm thinking of having a "sidecar" conf for a module. Right now when a user 
> wants to save certain settings for a module, we (JSword) modify the conf. 
> (I.e. CipherKey and Font).
> 
> This could then be used to save anything a front end discovers and does not 
> want to discover a second time. Such as Scope (which to my recollection was 
> not shot down), Introductions, Colophons, user settings(?)
> 
> The basic idea is that the engine (JSword in my case) would read the conf and 
> then the sidecar for the module, merging into a single internal 
> representation of the conf. That way the module's conf would be then kept 
> pristine.
> 
> In Him,
>   DM Smith
> 
> On Jun 3, 2013, at 8:03 AM, Nic Carter  wrote:
> 
>> 
>> I think (& I hope?) what is being proposed is a method in Sword that will 
>> check any book of the Bible to see if it is empty or not. This will 
>> ultimately be very fast, as it may need to test a large number of verses?
>> This same method should be able to be adapted to live-test introductions for 
>> books &/or testaments? Then you could determine whether or not to allow such 
>> a preference/toggle? Also, then you could tell which introductions should be 
>> navigable to?
>> 
>> FYI, in PS I simply don't show options for modules that don't support a 
>> feature. Why show a greyed-out Strong's Numbers toggle in the NET, for 
>> example? Or Greek accents toggle for any English-language module? But, 
>> obviously, this is a design decision :) :)
>> 
>> BTW, I believe we're still waiting to hear whether or not an 
>> isEmpty(BookName) method is going to be incorporated into Sword? I'm 
>> interested in it, but I was just reminded that PS still doesn't support 
>> GenBooks & thought I might actually rectify that rather than look into an 
>> isEmpty() implementation... ;)
>> [yes, Karl, you requested it about 3.5 years ago, & I'm looking at the 
>> redesigns required to make this happen!]
>> 
>> Just my thoughts :)
>> ybic,
>> Nic :)
>> 
>> Sent from my phone, hence this email may be short...
>> 
>> On 03/06/2013, at 21:04, Chris Burrell  wrote:
>> 
>>> For cla

Re: [sword-devel] Bible book introductions

[DM Smith]

My reply to Chris L's post was a bit snide. Sorry. (I actually don't have a 
problem with NoParagraphs as a feature, but would rather discuss it here first.)

Regarding Scope. Most of our front-ends (SWORD and JSword) present modules that 
only contain the NT as if they have an OT as well. Fortunately, that is an easy 
check. If the OT files are missing then it is NT only. (And visa-versa).

But as we get more and more minority language modules that do not contain an 
entire testament because it is a long term work in progress, it'd be nice to 
handle that well.

The problem for a front-end and the engine is that there is no efficient way to 
verify the presence of a book but to check all of its verses. The reason for 
this is that the dat file contains the sequential data from the input file, 
which is allowed to be out of order. The append feature of our importers, which 
provides for a module to be constructed incrementally, allows for this to 
happen quite easily.

It might be best practice to have all the verses in the proper order in the dat 
file, but it is not at all required by SWORD engine and as such, the front-end 
and the engine cannot assume that it is the case. Worst case to determine that 
only Psalms is present in the OT, one has to check nearly every verse in the OT.

It is efficient to determine whether a book or chapter has content (just quit 
looking once a verse is found at the desired level) but it is quite hard to 
determine whether a book or chapter is entirely missing.

To do the check each time the answer is needed is not appropriate. Thus some 
kind of cache is needed. The conf (or augment conf) seems like the right place 
to do the caching.



On Jun 3, 2013, at 10:23 AM, "Troy A. Griffitts"  wrote:

> I don't recall ever hearing of "NoParagraphs".  But I am old now and quite 
> possibly could have forgotten.
> 
> The push back on my side of this is from the desire to:
> 
> a) keep the .conf generation only as complex as needed, and
> b) avoid the possibilities for inconsistencies.
> 
> SWORD accumulates toggleable features from all installed modules and presents 
> them from:
> SWMgr::getGlobalOptions()
> 
> This will only return a list of available options from installed modules, 
> even if the software supports more options.
> 
> In the frontends I have written, I call this method, and typically present an 
> application toolbar for global toggling of these features.  Many frontends 
> decide that their user might want to toggle these features on a per-module 
> basis, instead of globally, and while my preference is otherwise, I am happy 
> to have frontends which support both methodologies.
> 
> I am not happy to have computed values in the .conf file.  This makes 
> independent module publishing more difficult.  I've already reluctantly gone 
> down that road for "InstallSize", which if not present merely has the 
> side-effect of saying something like "Unknown" in the installer.  If we start 
> writing code which depends upon computed values and the publisher forgets to 
> add "Feature=Headings" in the .conf file-- making it inconsistent with what 
> actually is in the module, what are the results?
> 
> I am not sure I am convinced of a need to precompute the existence of all 
> possible OSIS tags within a document that a frontend might wish to expose 
> user features against-- which is the logical end to this request.
> 
> The Feature tags which exist were added for specific use cases.
> 
> Select your preferred Greek Lexicon: [ modules(@Feature=GreekDef) ]
> Select your preferred Hebrew Lexicon: [ modules(@Feature=HebrewDef) ]
> Select your preferred Chinese Glossary: [ modules(@Lang=zh,@Feature=Glossary ]
> 
> etc.
> 
> 
> The OptionFilter tags are used by a publisher to state that they would like a 
> user to be able to toggle certain features within their module.  These are 
> what register option for the getGlobalOptions mentioned above.
> 
> Troy
> 
> 
> 
> 
> 
> 
> 
> Troy
> 
> 
> On 06/03/2013 02:55 PM, DM Smith wrote:
>> I saw that Scope was yanked from the wiki with a comment that it had been 
>> rejected. I really don't remember it being rejected. I just remember that 
>> the discussion never went anywhere so it was dropped. I documented the 
>> desire of that discussion by putting an entry into the wiki. Even if engine 
>> support is given for determining this by examining a module, it will be far 
>> slower than having a declaration in the conf. On phones (low powered 
>> devices), such discovery is much too expensive and needs to be cached on a 
>> per module basis so that it is not recomputed.
>> 
>> I still think that it is very needed. I&#x

Re: [sword-devel] Bible book introductions

[DM Smith]

On Jun 3, 2013, at 11:44 AM, Greg Hellings  wrote:

> 
> 
> 
> On Mon, Jun 3, 2013 at 10:06 AM, DM Smith  wrote:
> 
> It is far more than 70. Every chapter can have an introduction. To see if a 
> module one would have to check every verse 0 for text content. It is not 
> sufficient to see if it has content. It may only have structural content. So 
> that means it will have to be parsed for text. 
> 
> Worst case is a module that does not have introductions. One would have to 
> check every verse 0. If all that is wanted is to know whether a module has at 
> least one introduction, the code can stop having found the first one.
> 
> Also, non-canonical, non-title content can appear anywhere. It is quite 
> possible for there to be section introductions. AFAIK, we just haven't had 
> any modules with that. (But I have paper study bibles with that feature.) So 
> that would mean that every verse would have to be checked to see if it has 
> pre-verse content with introductory material.
> 
> Then the scope of this thread has expanded from "Bible book introductions" to 
> "Any introduction or title or non-canonical text anywhere".
> 
> --Greg

My apologies for that. I have already hijacked it regarding scope. Probably 
should have started a separate thread for that.

If it is merely needed for book introductions, then it is lightweight.

However, I think his problem is actually bigger than just book introductions. I 
think he wants a user to be able to toggle canonical/non-canonical material in 
a fine grain manner (intros, colophons, titles).

In Him,
DM

___
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] Bible book introductions

[DM Smith]

Note, the colophons in the KJV are from the underlying Greek text.

In Him,
DM

On Jun 3, 2013, at 7:04 AM, Chris Burrell  wrote:

> For clarity, my use case is as follows. 
> 
> I have a menu displaying options such as Verse numbers, Headings, Verses on 
> New Lines, Red letters. I'd like to add an option called Introductions (and 
> perhaps one called Colophon).
> 
> The options in this menu are grayed out when the underlying module doesn't 
> support this. If the option is grayed out, I add an explanation as to why 
> that is (e.g. the module doesn't support it, or 1 option is not compatible 
> with another option that is already selected, etc.)
> 
> The availability of the options is uniquely dependant on which version of the 
> Bible or Commentary a user has selected. If a user selects a different 
> module, the options available to him are updated automatically. For example, 
> a user is clearly aware that most of the Old Testament doesn't have a Red 
> Letter option. He might however work mainly from the ESV and want his 
> frontend to show Jesus's words in red when they are in the text, so he sets 
> up the option once. 
> 
> At this stage, we don't care about what passage/text a user is going to 
> lookup. We can't guess what's in his mind! And we can certainly not guess 
> what he's going to lookup tomorrow, the day after tomorrow, next month, next 
> year.
> 
> This is the same for Introductions & Colophons. He might decide he's never 
> interested in seeing Introductions and Colophons and want to turn them off 
> completely. Or on the other hand he might want to turn them on all the time 
> because he is always interested in them. 
> 
> But a toggle button available to turn the introductions on/off is pretty 
> pointless if the module doesn't have any. In actual fact, it's pretty 
> annoying because it looks like there may be a bug, since in the ASV toggling 
> this option never makes a difference. In the same way a toggle button to turn 
> red letters on/off for the ASV is pretty useless as well.
> 
> It should be obvious by now that having Sword/JSword being able to tell a 
> frontend whether or not Introductions are contained within a module is a big 
> plus to what we have now.
> 
> Chris
> 
> 
> 
> On 3 June 2013 07:26, Chris Burrell  wrote:
> One could apply your reasoning for every option we have in the Conf file so 
> far.
> 
> Headings, notes, cross references, strongs, morphology... A verse or chapter 
> is not guaranteed to contain any of these. You still need to check for non 
> empty cross references for example if your frontend is displaying them in a 
> separate pane. Same as strong numbers if you're doing interlinears.
> 
> The option doesn't guarantee anything. It's there to indicate a module 
> supports a particular features. It's at least that was my understanding.
> 
> Isn't the whole point of the options to allow the user to set up his 
> preferred view for reading the Bible so that as he goes from one chapter to 
> another he doesn't need to click options on and off as they randomly appear.
> 
> Please do tell how I'm supposed to identify whether a Bible has introductions 
> without reading the whole Bible.
> 
> Chris
> 
> On 2 Jun 2013 22:48, "Chris Little"  wrote:
> On 6/2/2013 9:23 AM, Chris Burrell wrote:
> Hi
> 
> Some books have Bible introductions. Can I suggest adding a flag to the
> conf file to indicate this is the case? In the similar mindset as a
> previous post, I'd prefer being able to query the conf file for features
> of a particular module rather than having to read part of the module and
> hope for that particular book/chapter to have an introduction. A yes/no
> flag in the .conf file would be helpful.
> 
> (In particular, I have in mind the book introductions that are part of
> the ESV text). But no doubt other modules will also (or in the future
> will also) have the same aspects.
> 
> Chris
> 
> I would say no. This doesn't add anything.
> 
> Identifying that a module possesses introductions at some level does not 
> indicate that it possesses all of the introductions at that level. 
> Accordingly, knowing that a module possesses introductions still requires 
> checking for non-empty contents in order to know that a particular 
> introduction is non-empty.
> 
> This is along the lines of the request for a Scope .conf entry, which was 
> already rejected. Whatever solution is used for that case can also be used 
> for introductions.
> 
> --Chris
> 
> 
> ___
> 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

___
s

Re: [sword-devel] Scope/NoParagraphs (was: Re: Bible book introductions)

[DM Smith]

On Jun 3, 2013, at 3:53 PM, Chris Little  wrote:

> On 6/3/2013 5:55 AM, DM Smith wrote:
>> I saw that Scope was yanked from the wiki with a comment that it had
>> been rejected. I really don't remember it being rejected. I just
>> remember that the discussion never went anywhere so it was dropped. I
>> documented the desire of that discussion by putting an entry into the
>> wiki. Even if engine support is given for determining this by
>> examining a module, it will be far slower than having a declaration
>> in the conf. On phones (low powered devices), such discovery is much
>> too expensive and needs to be cached on a per module basis so that it
>> is not recomputed.
>> 
>> I still think that it is very needed. I'm getting tired of how such
>> discussions go.
> 
> This is the message in which I would say that scope gets rejected:
> http://www.crosswire.org/pipermail/sword-devel/2012-February/037148.html

I certainly didn't read it that way.

> 
> None of Troy's concerns are addressed,

Troy merely listed a few things and said he didn't like each. He didn't say why 
so there was no opportunity for further discussion.


> and the rest of the thread devolves into off-topic irrelevancy.

The rest of the thread was off topic for the question at hand, but not 
regarding Scope (called coverage there). It was quite on topic.


> Scope has certainly not risen to the level of being a part of our .conf spec.

Right. That's why the wiki had it marked as proposed. It had not been agreed 
to. It contained the last state of the proposal. It meant that at a later date 
the conversation could be continued.

> 
> If you feel that Scope should still be under consideration, I encourage you 
> to address Troy's objections.

Answer to all objections: It can be handled automatically just like 
InstallSize. If it is there great. If not assume the entire v11n.

He offered to whip up a speedy computation. There was concern expressed that it 
wouldn't be speedy enough for older iPhones. This has been recently discussed 
on another thread, with suggested API and a bump to get it in there. Once 
there, we'll empirically see whether it is fast enough. I'm working on similar 
for JSword.

> 
>> I'm not at all clear why NoParagraphs was added as a Feature for the
>> frontends to use. I don't remember any discussion of it here. I don't
>> see the need for it. A frontend can examine each and every verse to
>> see if there is paragraphing or other such structural elements that
>> imply paragraphing. I have no intention of using it for the KJV. At
>> least not without community discussion and buy-in.

This paragraph was mean. I should not have said it this way at all. I was upset 
that Scope was pulled from the wiki when it had been there for over a year and 
NoParagraphing was added (based on a discussion that was further back than I 
could remember).

Again my apologies.

>> 
>> How is NoParagraphs any different than NoIntroductions (or
>> Introductions) !
> 
> They're quite different. There are an order of magnitude more verses than 
> introductions. Knowing whether to render a particular chapter (or other view 
> scope) as VPL or paragraphed would require doing a substring search through 
> every single verse of the module in order to maintain consistent rendering 
> across chapters. So that would make it about a 3-4 orders of magnitude more 
> work than checking for introductions at run time. (Compare the number of 
> bytes per Bible times the number of paragraphing elements to the number of 
> chapters per Bible. That's the difference in the order of work.)

Chapter N, Verse 0 will have content in most new OSIS modules. Osis2mod retains 
pretty much everything. It will probably contain:

Genesis N
(Though it might not have the title.)

This has no introduction. It does have content: Markup and titles. The only way 
to tell that it doesn't have an introduction is to parse it. I mentioned this 
in an earlier post.

How is this any harder than parsing to see if there is are elements related to 
paragraphing?

> 
> 
> Feature=NoParagraphs was discussed in 2009. Literally no one disagreed with 
> the proposal to add *something*. David asked about a feature like this a few 
> weeks back, prompting me to add the discussed and generally approved-of 
> feature to the wiki. I went with NoParagraphs rather than Paragraphs because 
> it's clearly the marked case and the fallback behavior for existing content 
> will be the current behavior.
> 
> Original discussion thread here:
> http://www.crosswire.org/pipermail/sword-devel/2009-November/033058.html

I re-read the thread and there were objections. I don't think they were 
a

Re: [sword-devel] Scope/NoParagraphs

[DM Smith]

On Jun 5, 2013, at 4:07 AM, Chris Little  wrote:

> On 6/3/2013 2:20 PM, DM Smith wrote:
>> 
>> On Jun 3, 2013, at 3:53 PM, Chris Little 
>> wrote:
>> 
>>> This is the message in which I would say that scope gets rejected:
>>> http://www.crosswire.org/pipermail/sword-devel/2012-February/037148.html
>> 
>>> 
>> I certainly didn't read it that way.
>> 
>>> 
>>> None of Troy's concerns are addressed,
>> 
>> Troy merely listed a few things and said he didn't like each. He
>> didn't say why so there was no opportunity for further discussion.
> 
> Like Nic, I saw the gatekeeper's rejection of Scope as an end to the
> issue--given that no one countered his rejection or offered solutions.
> 
> If something programmatic can be done to populate Scope--either on the
> client side or the server--then I could conceive of the proposal becoming 
> viable once again.
> 
> I never had a dog in the Scope fight. I think my only two comments were that 
> I preferred Scope over Coverage as the name for the attribute and that I 
> truly hated the idea of using Scope to define ad hoc versification systems. I 
> don't object to a Scope attribute in general, but at this point in time, it's 
> not part of Sword and shouldn't be part of the .conf documentation. That 
> being said
> 
>>> Scope has certainly not risen to the level of being a part of our
>>> .conf spec.
>> 
>> Right. That's why the wiki had it marked as proposed. It had not been
>> agreed to. It contained the last state of the proposal. It meant that
>> at a later date the conversation could be continued.
> 
> I've brought the Scope documentation back to the .conf article's Talk page. 
> It can be archived there (or amended as necessary) until there's actually 
> some consensus on what, if anything, should be added to .confs to reflect 
> scope.

Thanks for putting it in the talk page. Often a topic that has been quite for a 
while will come back up. I think it is a good idea to capture state of the 
conversations in the wiki, perhaps with links to threads, so that we don't 
rehash old as new.

> 
>>>> I'm not at all clear why NoParagraphs was added as a Feature for
>>>> the frontends to use. I don't remember any discussion of it here.
>>>> I don't see the need for it. A frontend can examine each and
>>>> every verse to see if there is paragraphing or other such
>>>> structural elements that imply paragraphing. I have no intention
>>>> of using it for the KJV. At least not without community
>>>> discussion and buy-in.
>> 
>> This paragraph was mean. I should not have said it this way at all. I
>> was upset that Scope was pulled from the wiki when it had been there
>> for over a year and NoParagraphing was added (based on a discussion
>> that was further back than I could remember).
>> 
>> Again my apologies.
> 
> Not to worry, no offense was taken. I'm happy to discuss
> Feature=NoParagraphs to make sure everyone is happy, within reason.
> 
>>> They're quite different. There are an order of magnitude more
>>> verses than introductions. Knowing whether to render a particular
>>> chapter (or other view scope) as VPL or paragraphed would require
>>> doing a substring search through every single verse of the module
>>> in order to maintain consistent rendering across chapters. So that
>>> would make it about a 3-4 orders of magnitude more work than
>>> checking for introductions at run time. (Compare the number of
>>> bytes per Bible times the number of paragraphing elements to the
>>> number of chapters per Bible. That's the difference in the order of
>>> work.)
>> 
>> Chapter N, Verse 0 will have content in most new OSIS modules.
>> Osis2mod retains pretty much everything. It will probably contain:
>>  Genesis N (Though it might not
>> have the title.)
>> 
>> This has no introduction. It does have content: Markup and titles.
>> The only way to tell that it doesn't have an introduction is to parse
>> it. I mentioned this in an earlier post.
>> 
>> How is this any harder than parsing to see if there is are elements
>> related to paragraphing?
> 
> That seems like a reasonable argument, and I might be amenable to the 
> addition of a feature to indicate presence of actual introductory text. 
> That's not how I read the initial request, but it was somewhat vague.
> 
>>> Feature=NoParagraphs was discussed in 2009. Literally no one
>>&

[sword-devel] Per Module V11N (Was Re: Bible book introductions)

[DM Smith]

On Jun 5, 2013, at 5:43 AM, Костя Маслюк  wrote:

> 05.06.2013 5:32 пользователь "Nic Carter"  написал:
> > I guess we need to have some sort of implementation with which to try this 
> > out with. I remember that trying to create a cLucene search index on my old 
> > iPhone 3G was sufficiently silly that I removed that functionality in PS. 
> > But I needed to test it to confirm that it was a stupid idea to allow users 
> > to attempt it. (I would say the same for BibleTime mini & say that 2.5hrs 
> > is way too long to even suggest a user plug in their phone and run it 
> > overnight! But that's just my sanity shining through, and I'll resume my 
> > insanity in a moment)...
> >
> 
> This statement forced me to check: with BtMini i got nine minutes to create 
> clucene search index for KJV (iphone 3gs 6.1 firmware). Can't believe that 3g 
> to 3gs performance difference can be up to 16 times.
> 
> 
> 
> Coming back to conversation subject, there can be i didn't noticed too, 
> whether idea with module-supplied-v11n was rejected? Compared to Scope 
> feature it is more powerful flexible, do not increase load on frontend, and 
> finally simple to realize. I even consider ability to provide several v11n 
> schemes for one module, whether it is necessary for user to turn off 
> deuterocanonical content.
> 

The intention of Scope was to declare what was actually in the module. It was 
not meant to hide module content.

I don't know what thread it was. But my understanding is that every time this 
is brought up the answer is we aren't going to do that using the current module 
format but rather using a gen book format (and VerseTreeKey?).

I think that part of it may be the desire to have mappings from one v11n to 
another. Having "arbitrary" per module v11n make the task hard.

The problem of having multiple v11n per module is that is not how a v11n works. 
In the non-compressed module, there are two parts per testament: an index and a 
dat file. The v11n is used to convert a Bible reference into an index into the 
dat file. Basically, the structure of the v11n is given as counts of verses by 
chapters. If one v11n is missing content of the other, its index for every 
verse following will differ.

There are two basic solutions:
a) Build the module twice, such as is done with the KJV.
b) Change the frontends to turn off/on non-canonical material. This requires 
distinct knowledge of the v11n to get it right.

a) is a lot easier to do.

If the frontends will only display books, chapters and verses that are actually 
in a module (e.g. in a verse picker) then we may not need both KJV and KJVA, 
NRSV and NRSVA, ..., but only the one that contains the apocrypha. In fact we 
probably can use the NRSV(A) for the KJV and get rid of the KJV v11n. But that 
day is a long way off.

Hope this helps.

In Him,
DM Smith___
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] I implore you...

[DM Smith]

Osis2mod no longer does that. Mid verse titles are left as is where they occur. 

Cent from my fone so theer mite be tipos. ;)

On Jun 10, 2013, at 2:50 AM, Chris Little  wrote:

> I believe that the issue is simply that osis2mod identifies all titles as 
> pre-verse titles. Someone correct me if I'm wrong, but that's the only issue 
> I can really imagine.
> 
> --Chris
> 
> On 6/9/2013 11:46 PM, Troy A. Griffitts wrote:
>> I am unaware that SWORD does not support mid-verse section headings.
>> 
>> They are the easier case, as opposed to pre-verse section headings which
>> require special treatment.  I am simply looking for a known location in
>> existing module with a mid-verse heading to check and see.  If you know
>> of one, please, could you send the module name and verse location, or
>> better, simply check it out on swordweb yourself and report back:
>> 
>> http://crosswire.org/sword
>> 
>> 
>> 
>> 
>> On 06/10/2013 08:05 AM, David Haslam wrote:
>>> In the USFM files from the Translation Trust that we used for making the
>>> Turkish Bible module, there were 3 mid-verse section headings in Acts.
>>> 
>>> I recently resent these files to Chris Little, so that he could provide a
>>> fix for an unrelated  issue
>>>    in usfm2osis.py
>>> 
>>> The locations were in or near:
>>> 
>>> Acts 10:24
>>> Acts 12:20
>>> Acts 14:21
>>> 
>>> I have not yet looked at how usfm2osis.py now processes these.
>>> 
>>> For the released module, because mid-verse titles were so few and because
>>> SWORD couldn't deal with them back then, we went back to the Gen Sec
>>> of the
>>> Trust, and he granted us leeway as follows:
>>> 
>>> My suggestion is that the heading be placed at the beginning of verse
>>> 24 of
>>> Acts 14. It goes better there anyway since the Antakya to which the
>>> return
>>> is all about is the one in verse 26. Putting it in the middle of 21-22
>>> creates the confusion with the other Antakya in verse 22.
>>> 
>>> In Acts 10 the title can go at the beginning of verse 24.
>>> 
>>> In Acts 12 the title can go at the beginning of verse 20.
>>> 
>>> Hope this helps.
>>> Rod
>>> 
>>> -
>>> 
>>> David Haslam
>>> 
>>> PS.  It should be pointed out that module TurNTB still has an outstanding
>>> issue with regard to section titles placement. See
>>> http://www.crosswire.org/tracker/browse/MOD-189
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652452.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
> 
> 
> ___
> 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] I implore you...

[DM Smith]

A bit more on titles. In the old, old osis2mod (i.e. many versions ago) the 
expectation was that the only markup between verses would be titles and that 
titles would occur no where else.

At that time, the code pulled all titles out of the verse, no matter where they 
occurred and prefixed the verse with them, marking up each with pre-verse 
designation. Interverse, non-title markup was treated as verse markup, coming 
after all the titles.

But when we started getting richly marked up modules, this caused all kinds of 
confusion and lots of questions on how to markup titles to make osis2mod and 
SWORD work together.

osis2mod was changed so that it did not reorder any supplied markup. And all 
pre-verse content was put between preverse start/end markers.

It is this release that will have proper handling of the preverse start/end 
markers.

Hope this clarifies,
DM

On Jun 10, 2013, at 7:53 AM, DM Smith  wrote:

> Osis2mod no longer does that. Mid verse titles are left as is where they 
> occur. 
> 
> Cent from my fone so theer mite be tipos. ;)
> 
> On Jun 10, 2013, at 2:50 AM, Chris Little  wrote:
> 
>> I believe that the issue is simply that osis2mod identifies all titles as 
>> pre-verse titles. Someone correct me if I'm wrong, but that's the only issue 
>> I can really imagine.
>> 
>> --Chris
>> 
>> On 6/9/2013 11:46 PM, Troy A. Griffitts wrote:
>>> I am unaware that SWORD does not support mid-verse section headings.
>>> 
>>> They are the easier case, as opposed to pre-verse section headings which
>>> require special treatment.  I am simply looking for a known location in
>>> existing module with a mid-verse heading to check and see.  If you know
>>> of one, please, could you send the module name and verse location, or
>>> better, simply check it out on swordweb yourself and report back:
>>> 
>>> http://crosswire.org/sword
>>> 
>>> 
>>> 
>>> 
>>> On 06/10/2013 08:05 AM, David Haslam wrote:
>>>> In the USFM files from the Translation Trust that we used for making the
>>>> Turkish Bible module, there were 3 mid-verse section headings in Acts.
>>>> 
>>>> I recently resent these files to Chris Little, so that he could provide a
>>>> fix for an unrelated  issue
>>>> <http://www.crosswire.org/tracker/browse/MODTOOLS-42>   in usfm2osis.py
>>>> 
>>>> The locations were in or near:
>>>> 
>>>> Acts 10:24
>>>> Acts 12:20
>>>> Acts 14:21
>>>> 
>>>> I have not yet looked at how usfm2osis.py now processes these.
>>>> 
>>>> For the released module, because mid-verse titles were so few and because
>>>> SWORD couldn't deal with them back then, we went back to the Gen Sec
>>>> of the
>>>> Trust, and he granted us leeway as follows:
>>>> 
>>>> My suggestion is that the heading be placed at the beginning of verse
>>>> 24 of
>>>> Acts 14. It goes better there anyway since the Antakya to which the
>>>> return
>>>> is all about is the one in verse 26. Putting it in the middle of 21-22
>>>> creates the confusion with the other Antakya in verse 22.
>>>> 
>>>> In Acts 10 the title can go at the beginning of verse 24.
>>>> 
>>>> In Acts 12 the title can go at the beginning of verse 20.
>>>> 
>>>> Hope this helps.
>>>> Rod
>>>> 
>>>> -
>>>> 
>>>> David Haslam
>>>> 
>>>> PS.  It should be pointed out that module TurNTB still has an outstanding
>>>> issue with regard to section titles placement. See
>>>> http://www.crosswire.org/tracker/browse/MOD-189
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> View this message in context:
>>>> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652452.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
>> 
>> 
>> ___
>> 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] I implore you...

[DM Smith]

Fortunately, usfm2osis.py is not tied to a release. It is a separate standalone 
piece of software, not using the SWORD engine.

IMHO, regarding module development, the only potential blocker for a release is 
the handling of pre-verse divs and whitespace issues related to it within the 
SWORD library. Lots has been done here. I think at some point these can be 
declared good enough. Maybe that is now.

In Him,
DM


On Jun 10, 2013, at 3:45 PM, David Haslam  wrote:

> DM's message clarifies where the new release is heading, 
> but it doesn't alter the fact that usfm2osis.py places section titles
> before the eID milestone of the previous verse (when there is one).
> 
> With the new release therefore, the new osis2mod (even after recompiling for
> version 1.7),
> would surely not find such titles or other content where it expects to find
> them.
> 
> A better bird's eye view is required.
> 
> Of course, I'm merely the Go Bible leader, so I shouldn't really be expected
> to have any views at all. 
> (wink, wink, etc).
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652473.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] What is a mid-verse title?

[DM Smith]

Only responding to the last part below.

On Jun 10, 2013, at 3:58 PM, David Haslam  wrote:

> Just to ensure there is no misunderstanding...
> 
> Paratext permits but does not enforce sub-verses in the verse tag.
> 
> The USFM Reference does not document this feature.
> 
> We often see these explicit examples:
> 
> \v 3-5a Some verse text for three and a half verses
> \v 5v-7 Some verse text for three and a half verses
> 
> A section title between these two lines thus becomes a mid-verse title part
> way through verse 5.
> 
> --
> 
>> From translators we now encounter things like this:
> 
> \v 5 some verse text for part of a verse
> \s A suitable section title
> \p the remaining text for verse five
> \v 6 the text for verse six
> 
> So what does usfm2osis.py do with these implicit examples?
> It doesn't first convert them to using sub-verses.
> 
> It has no brief to do that. 
> And even the code to handle explicit sub-verses is still only a roadmap
> intention.
> 
> What should the OSIS output look like here?

Probably something like:
some verse text for part of a 
verseA suitable section titlethe remaining text for verse 
five
the text for verse six

It is fine for the title element to have a type and even subType attributes. It 
will not affect osis2mod's processing. Still have to have a look in SwordWEB to 
the ESV example.

There may or may not be spacing before or after the title. It is entirely 
unnecessary.

> And how will osis2mod handle the OSIS made using usfm2osis ?


If this is the output, it will be stored as (showing one line per verse in the 
uncompressed data file.):
some verse text for part of a verseA suitable section titlethe 
remainint text for verse five
the text for verse six

Note, the module does not have the verse elements.

> 
> David
> 
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/What-is-a-mid-verse-title-tp4652476.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] I implore you...

[DM Smith]

Yay!!!

In Him,
DM

On Jun 10, 2013, at 8:05 AM, Troy A. Griffitts  wrote:

> Thanks Ben,
> 
> This is exactly what I was looking for.  Here's the link which forces the 
> module to ESV:
> 
> http://crosswire.org/study/passagestudy.jsp?mod=ESV&key=Song+of+Solomon+4%3A16#cv
> 
> And yeah, they do look a little weird, but at least they are showing up.
> 
> Thanks again,
> 
> Troy
> 
> 
> 
> On 06/10/2013 08:51 AM, Ben Morgan wrote:
>> They are supported. E.g. Song of Solomon in the ESV has them. E.g. 4:16:
>> http://crosswire.org/study/passagestudy.jsp?key=Song+of+Solomon+4%3A16#cv
>> 
>> Note that some of the titles here do look weird, but they are supported.
>> 
>> God Bless,
>> Ben
>> -
>> For I have no pleasure in the death of anyone, 
>> declares the Lord God; so turn, and live.”
>> Ezekiel 18:32 (ESV)
>> 
>> 
>> 
>> On Mon, Jun 10, 2013 at 4:46 PM, Troy A. Griffitts  
>> wrote:
>> I am unaware that SWORD does not support mid-verse section headings.
>> 
>> They are the easier case, as opposed to pre-verse section headings which 
>> require special treatment.  I am simply looking for a known location in 
>> existing module with a mid-verse heading to check and see.  If you know of 
>> one, please, could you send the module name and verse location, or better, 
>> simply check it out on swordweb yourself and report back:
>> 
>> http://crosswire.org/sword
>> 
>> 
>> 
>> 
>> 
>> On 06/10/2013 08:05 AM, David Haslam wrote:
>> In the USFM files from the Translation Trust that we used for making the
>> Turkish Bible module, there were 3 mid-verse section headings in Acts.
>> 
>> I recently resent these files to Chris Little, so that he could provide a
>> fix for an unrelated  issue
>>    in usfm2osis.py
>> 
>> The locations were in or near:
>> 
>> Acts 10:24
>> Acts 12:20
>> Acts 14:21
>> 
>> I have not yet looked at how usfm2osis.py now processes these.
>> 
>> For the released module, because mid-verse titles were so few and because
>> SWORD couldn't deal with them back then, we went back to the Gen Sec of the
>> Trust, and he granted us leeway as follows:
>> 
>> My suggestion is that the heading be placed at the beginning of verse 24 of
>> Acts 14. It goes better there anyway since the Antakya to which the return
>> is all about is the one in verse 26. Putting it in the middle of 21-22
>> creates the confusion with the other Antakya in verse 22.
>> 
>> In Acts 10 the title can go at the beginning of verse 24.
>> 
>> In Acts 12 the title can go at the beginning of verse 20.
>> 
>> Hope this helps.
>> Rod
>> 
>> -
>> 
>> David Haslam
>> 
>> PS.  It should be pointed out that module TurNTB still has an outstanding
>> issue with regard to section titles placement. See
>> http://www.crosswire.org/tracker/browse/MOD-189
>> 
>> 
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652452.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
>> 
>> 
>> 
>> ___
>> 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] What is a mid-verse title?

[DM Smith]

On Jun 10, 2013, at 4:53 PM, David Haslam  wrote:

> DM wrote, "There may or may not be spacing before or after the title. It is
> entirely unnecessary. "
> 
> Objection: A title as inline text wouldn't look right in a front-end.
> 
> so did you mean "additional spacing" ?

There is a difference between an OSIS xml file and its rendering.

WRT rendering: A title is a block element, not an inline element. A block 
element always starts "on the next line" and stuff after a block element always 
starts "on the next line." Some block elements, such as titles, are rendered 
with additional vertical space before and after.

WRT source xml, vertical spacing (new lines) around a block element are 
meaningless.

Note, that if the element is removed (i.e. a filter hides titles) something 
reasonable needs to happen to prevent the before and after from fusing words.

In Him,
DM


___
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] Posts to CrossWire's Facebook page

[DM Smith]

We've had quite a few postings in Farsi (I think). It appears that it is an 
attempt to do a link exchange. Can someone take a look who can read it and 
provide advice?

https://www.facebook.com/crosswirebiblesociety/posts/321948371272135

Thanks.

In Him,
DM
___
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] What is a mid-verse title?

[DM Smith]

On Jun 10, 2013, at 5:20 PM, David Haslam  wrote:

> OK - so that must surely mean that *Xiphos 3.1.5* is malfunctional.

I think they merely use the SWORD OSISxhtmlhref render filter.

When I looked at SwordWeb today, it surrounded it with , which is an HTML 
block element.

> 
> It didn't provide the new line before a pre-verse title, so it cannot be
> treating a title as a block element.
> 
> The title text had the right text style, but appeared at the end of the
> verse text.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/What-is-a-mid-verse-title-tp4652476p4652485.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] I implore you...

[DM Smith]

I saw that it didn't go to the ESV too. I had to pick it on the left.

Maybe you have headings turned off. If on, you should see one immediately 
before verse 16 and one in it.

In Him,
DM

On Jun 10, 2013, at 5:28 PM, David Haslam  wrote:

> Hang on a mo!
> 
> Where is the mid-verse title in Song 4?  I can't see one there.
> 
> The only title that URL presented me is the one above verse 1.
> 
> And why is the verse 1 tag widowed?
> 
> NB.  The URL didn't force navigation to the ESV at all, despite that module
> name being in the passed parameters.
> When I clicked the URL, swordweb remained showing the NASB.
> 
> btw.  I've noticed this behaviour before, and am somewhat mystified.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652487.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] Posts to CrossWire's Facebook page

[DM Smith]

Do the postings differ one from another?
-- DM

On Jun 10, 2013, at 5:34 PM, David Haslam  wrote:

> Though I can't read Farsi, the user's  own page
>    has many posts with English
> pictorial content that show he's a keen advocate for studying the Bible.
> 
> I had no good reason to hide his posts.
> 
> Hope that helps.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Posts-to-CrossWire-s-Facebook-page-tp4652484p4652489.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] I implore you...

[DM Smith]

I tried both Firefox and Safari.

I don't think it has to do with the browser.

-- DM

On Jun 10, 2013, at 5:38 PM, David Haslam  wrote:

> Got it.
> 
> *Together in the Garden of Love*
> 
> but the URL behaviour is still baffling.  I was using Firefox. 
> Which browser were you using?
> 
> David
> 
> PS. Headings were already "turned on".
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652492.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] I implore you...

[DM Smith]

You are looking at the NASB. There was a problem with the link that was 
provided. You'll need to select the ESV on the left to get to it.

-- DM

On Jun 11, 2013, at 7:23 AM, David Instone-Brewer  
wrote:

> Perhaps there are still some problems here. The Crosswire link shows me at 
> http://crosswire.org/study/passagestudy.jsp?key=Song+of+Solomon+4%3A16#cv 
> (I tried both FF & Chrom in Windows 7)
> 16
> “Awake, O north wind,
> And come, wind of the south;
> Make my garden breathe out fragrance,
> Let its spices be wafted abroad.
> May my beloved come into his garden
> And eat its choice fruits!”
> whereas BibleGateway shows the 
> * mid-verse section headers
> * Speaker headers (which only appear in Song of Songs)
> * differentiates between A-lines and indented B-lines
> 16
> Awake, O north wind,
> and come, O south wind!
> Blow upon my garden,
> let its spices flow.
> 
> 
> Together in the Garden of Love
> 
> 
> 
> She
> 
> Let my beloved come to his garden,
> and eat its choicest fruits.
> These sections headers are recorded in the OSIS ESV text, but they don't 
> display when they occur in the middle of verses. 
> 
> David IB
> 
> 
> 
> At 13:05 10/06/2013, Troy A. Griffitts wrote:
>> Thanks Ben,
>> 
>> This is exactly what I was looking for.  Here's the link which forces the 
>> module to ESV:
>> 
>> http://crosswire.org/study/passagestudy.jsp?mod=ESV&key=Song+of+Solomon+4%3A16#cv
>>  
>> 
>> And yeah, they do look a little weird, but at least they are showing up.
>> 
>> Thanks again,
>> 
>> Troy
>> 
>> 
>> 
>> On 06/10/2013 08:51 AM, Ben Morgan wrote:
>>> They are supported. E.g. Song of Solomon in the ESV has them. E.g. 4:16: 
>>> http://crosswire.org/study/passagestudy.jsp?key=Song+of+Solomon+4%3A16#cv 
>>> 
>>> Note that some of the titles here do look weird, but they are supported.
>>> 
>>> God Bless,
>>> Ben
>>> -
>>> For I have no pleasure in the death of anyone, 
>>> declares the Lord God; so turn, and live.”
>>> Ezekiel 18:32 (ESV)
>>> 
>>> 
>>> 
>>> On Mon, Jun 10, 2013 at 4:46 PM, Troy A. Griffitts  
>>> wrote:
>>> I am unaware that SWORD does not support mid-verse section headings.
>>> They are the easier case, as opposed to pre-verse section headings which 
>>> require special treatment.  I am simply looking for a known location in 
>>> existing module with a mid-verse heading to check and see.  If you know of 
>>> one, please, could you send the module name and verse location, or better, 
>>> simply check it out on swordweb yourself and report back:
>>> 
>>> http://crosswire.org/sword 
>>> 
>>> 
>>> 
>>> 
>>> On 06/10/2013 08:05 AM, David Haslam wrote:
>>> In the USFM files from the Translation Trust that we used for making the
>>> Turkish Bible module, there were 3 mid-verse section headings in Acts.
>>> I recently resent these files to Chris Little, so that he could provide a
>>> fix for an unrelated  issue
>>> < http://www.crosswire.org/tracker/browse/MODTOOLS-42>   in usfm2osis.py
>>> The locations were in or near:
>>> Acts 10:24
>>> Acts 12:20
>>> Acts 14:21
>>> I have not yet looked at how usfm2osis.py now processes these.
>>> For the released module, because mid-verse titles were so few and because
>>> SWORD couldn't deal with them back then, we went back to the Gen Sec of the
>>> Trust, and he granted us leeway as follows:
>>> My suggestion is that the heading be placed at the beginning of verse 24 of
>>> Acts 14. It goes better there anyway since the Antakya to which the return
>>> is all about is the one in verse 26. Putting it in the middle of 21-22
>>> creates the confusion with the other Antakya in verse 22.
>>> In Acts 10 the title can go at the beginning of verse 24.
>>> In Acts 12 the title can go at the beginning of verse 20.
>>> Hope this helps.
>>> Rod
>>> -
>>> David Haslam
>>> PS.  It should be pointed out that module TurNTB still has an outstanding
>>> issue with regard to section titles placement. See
>>> http://www.crosswire.org/tracker/browse/MOD-189
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652452.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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> sword-devel mailing list:
>>> sword-devel@crosswire.org
>>> 
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above
>

Re: [sword-devel] Changing #include structure (was: I implore you...)

[DM Smith]

I've got no skin in the game, but I'm not short on opinions. ;)

Jaak, the change you've requested is a good, right and proper one. But it 
really needs to wait until after the release.

In Him,
DM

On Jun 13, 2013, at 4:47 AM, Jaak Ristioja  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Troy,
> 
> Imho there are already header files which clash, namely the zlib ones:
> 
> $ `echo -n 'ls -ld '; find include/ -name '*.h' | sed -e
> 's_^include/_/usr/include/_'` 2>/dev/null
> - -rw-r--r-- 1 root root 15292 sept  24  2012 /usr/include/zconf.h
> - -rw-r--r-- 1 root root 87011 sept  24  2012 /usr/include/zlib.h
> 
> Jaak
> 
> 
> On 13.06.2013 11:32, Troy A. Griffitts wrote:
>> Jaak,
>> 
>> On 06/13/2013 10:12 AM, Jaak Ristioja wrote: Troy,
>> 
>> It still seems that you missed one thing. Namely, the #includes
>> with <> still include a prefix, i.e. sound/ and omniORB4/. The
>> Sword #includes do not, and this by itself is a big problem which
>> makes header filename clashes a lot more probable, especially if
>> other libraries would follow suit and have the same #include
>> convention as Sword does.
>>> Jaak,  I didn't miss this.
>> 
>>> As I said in my last email, I'm not saying your wrong.  I'm just
>>> saying:
>> 
>>> a) the headers I looked at include things DIFFERENTLY than your
>>> patch, so I'm not sure your fix is the most standard. b) things
>>> work right now on a ton of platforms and compilers and build 
>>> projects, and I don't want to change this just before a release,
>>> which could potential break all of these-- especially if there
>>> are no known problems with this right now.  There is no reason to
>>> push a potentially disruptive patch just before a release.
>> 
>>> Also, if you use pkg-config to get the compile and link
>>> directives, you shouldn't need to care about what to pass to the
>>> compiler.
>> 
>>> .cpp: g++ `pkg-config --cflags sword` $< -o $@ `pkg-config --libs
>>> sword`
>> 
>> 
>>> Thanks for being concerned.  I understand your concern and value
>>> your input, Troy
>> 
>> 
>> 
>> Regarding <> and "", the latter provides a better safeguard
>> against including the wrong headers in some situations, especially
>> when dealing with multiple versions of the headers being installed
>> at the same time. More commonly, using "" instead of <> can also
>> help to simplify the build system for libraries such as Sword.
>> 
>> I don't consider using <> instead of "" a bug. But what I think is 
>> very inconvenient is that one has to explicitly use 
>> -I/usr/include/sword/ instead of just using #include
>>  in the source files.
>> 
>> This is cause for confusion for developers, who might think (as I
>> did and do): 1) Do I need to #include  // Sword header ? 
>> 2) If I #include  then why do I need to pass an
>> extra -I argument to the compiler?
>> 
>> What I'm asking is that even if you don't want "" instead of <>, 
>> please use a sword/ prefix for all respective #includes in all
>> header files of Sword.
>> 
>> Blessings, Jaak
>> 
>> 
>> On 13.06.2013 09:47, Troy A. Griffitts wrote:
> Jaak,
> 
> I'm of the same mind as Greg.  Our include syntax has been
> working as is for 20 years on a number of compilers and
> platforms.  I hesitate to wholesale change this now because
> of 'in principle' arguments without any actual problems being
> seen.  I don't have time to compile your changes on all the
> platforms we support to test them.  I know what we have now
> works.
> 
> I'm not saying that you're not right, but I also don't see
> your changes as standard.  Just a brief look on my box, 
> /usr/include/sound/sfnt_info.h includes 
> /usr/include/sound/asound.h with: #include 
> 
> /usr/include/omniORB4/anyStream.h includes 
> /usr/include/omniORB4/omniTypedefs.hh with: #include 
> 
> 
> Just the first 2 I looked at.
> 
> I'd like more time to investigate this before making a
> change,
> 
> Troy
> 
> 
> 
> 
> On 06/12/2013 10:28 PM, Jaak Ristioja wrote:
>> Well, using -I/usr/include/sword is just an ugly
>> workaround. It doesn't change the fact that Sword headers
>> include each other in a wrong manner (using <> instead of
>> ""). Because it would only be a workaround, we do not want
>> to stick to it forever. We want this fixed.
>> 
>> Secondly, headers in the Sword include directory have a
>> greater chance of colluding with other headers in
>> /usr/include/ and elsewhere. Hence the Sword headers
>> themselves might include wrong header files if that
>> happens. That's why using "" instead of <> is important so
>> that relative paths would be searched before any locations
>> specified by -I arguments to the compiler.
>> 
>> I don't believe my patch broke anything, the main changes
>> were substituting <> with "" when #including Sword headers.
>> However, if it did break anyth

Re: [sword-devel] Glosses vs Ruby

[DM Smith]

The other thing that is needed is a minimum sword version of 1.7 in the module 
conf for OSISGlosses.

Use OSISRuby for earlier versions of SWORD front-ends.

-- DM

On Jun 13, 2013, at 8:36 PM, Nic Carter  wrote:

> 
> On 13/06/2013, at 9:15 PM, ad...@bible.salterrae.net wrote:
> 
>>> Are the Japanese modules (in beta) going to be updated to reflect this?
>> 
>> What should I do to relect that?
> 
> Moving forward, if you are using "Ruby" or "Glosses", you should have the 
> line:
> GlobalOptionFilter=OSISGlosses
> to signify that the front-end should have the ability to be able to toggle 
> glosses on and off.
> 
> I believe that glosses/ruby isn't supported in modules that aren't marked up 
> in OSIS.  :)
> 
> I hope that helps?  Thanks, ybic
>   nic...  :)
> 
> ps: The previous way was to have "=OSISRuby", but that has been deprecated 
> and support for that may be removed "at any point in the future" from the 
> API, according to the definition of "deprecated"...  ;)
> ___
> 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] I implore you...

[DM Smith]

On Jun 15, 2013, at 2:53 AM, David Haslam  wrote:

> Not only should we be looking for a real example of a mid-verse title within
> a prose passage,
> we should also be looking for a mid-verse section title /per se/.
> 
> If we fail to consider such possibilities, we are merely kidding ourselves.
> 
> The example in *Song 4:16* worked in swordweb (etc) because it was within a
> poetry passage.
> The poetry markup supplied the line breaks.

If you're talking about the ESV, that's a wrong guess. If you select the text 
and then view the source for the selection you'll see that the title is marked 
up w/  in SwordWeb. This is a block element, not an inline element.

> 
> Moreover, the speaker identity "She" was the section title in that passage.
> Tracing back to USFM, speaker identity would use the tag *\sp* rather than
> *\s*
> 
> This implies that the OSIS source for the ESV module may have depended on a
> workaround.
> Should an *\sp* tag in USFM really be transformed into a SECTION title in
> the first place?
> 
> 
> IMHO, "the hunt continues".  Comments please.
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/I-implore-you-tp4652437p4652563.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] SWORD 1.7.0 final stretch

[DM Smith]

As long as we follow the advice to have subsequent releases that fix bugs and 
minor details, I don't see any reason to wait. But I haven't had time to test 
the new KJV and ESV with it.

I'll add my voice to a long list requesting branching for the release. Greg has 
volunteered to manage such. I suggest we take him up on that. Two parts to 
this: Tagging the release as we always have done and creating a branch before 
making changes that shouldn't be part of 1.7.x.

In the next month or so, I'll be moving the JSword git repository to the 
CrossWire server as the master copy. We'll still use github until we figure out 
collaboration on the CrossWire server.

I suggest seriously considering using git for SWORD. I was leery at first that 
it was YASCC (Yet another source code control) offering no real advantage over 
SVN. At this time, I won't go into why I'm sold on it. It really isn't part of 
this discussion. But suffice it to say: it makes branching and using branches 
easy.

The only thing that I've noted in the last month is the notion that the module 
version number is a 3 part number where the third part is updated for conf 
changes and as such does not require the module to be downloaded again. Does 
the engine offer support for knowing this or is this a front-end responsibility?

In Him,
DM

On Jun 19, 2013, at 4:45 AM, "Troy A. Griffitts"  wrote:

> Things have been quiet for a bit. I have all the patches in that are on my 
> todo list. Anyone else have outstanding issues? Now is the time to speak up.
> 
> Chris, any feedback on my Ralfs suggestion?
> 
> Peter, still binding troubles? Can you give me your exact commands executed 
> and I'll try them here.
> 
> David, are you still worried about a mid-verse heading? Did you find one? I 
> know there were a couple in the NASB, as that was the context for the 
> conversation between Karl and I when it came up a while back, but can't 
> remember where.
> 
> Anything else? Let's push this to completion. I need your help.
> 
> Troy
> -- 
> Sent from my Android phone 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

[sword-devel] Rahlfs LXX v11n (was Re: Current SVN)

[DM Smith]

I'd like more info on the LXX v11n. As I need to modify JSword for it.

If I'm following, Rahlfs has separate books for some OT books? The question is 
whether we have them separate in the v11n or aliases?

Does this implementation have any bearing on what is known to be 
deuterocanonical? That is, if they are separate books are JoshA and JoshB 
deuterocanonical while Josh is canonical? If they are aliases, how is it 
determined what is deuterocanonical?

There has been some talk about issuing a module 2x: once with DC and once w/o. 
Knowing what is DC can prevent this.

In Him,
DM

On Jun 19, 2013, at 9:40 AM, Chris Little  wrote:

> On 6/13/2013 2:58 PM, Troy A. Griffitts wrote:
>> Have projects had a chance to test against the latest SVN HEAD?
>> I believe I still have a patch from Greg to find and we still have
>> something outstanding for Peter to fix. Is anything else outstanding?
> 
> I've had success building on Win32 in MSVC and on Ubuntu 13.04 via autotools. 
> I'll fire up an OS X box and try it out there as well, but don't anticipate 
> any problems.
> 
> If you care about having up to date Borland C++ Builder projects, those are 
> probably quite out of date.
> 
>> Chris, I'd like to finish our discussion about the LXX v12n. What do you
>> think about having a 4 pattern book naming scheme for the double books:
>> A, B, without a suffix, and Alt. The without a suffix book name would
>> map to the primary column in Ralfs, as you have it, and either A or B
>> would map to the other, as you have it, but we would also include
>> abbrevs which would map the explicit A and B always, and then have an
>> Alt abbrev which would map to the non-primary reading. Thoughts?
> 
> Resolution of this issue should be treated as a release blocker. I really 
> don't want to have to do any sort of modification to the v11n definition 
> after release, should such modification be necessary.
> 
> At present, the Rahlfs v11n system has the following books (among others):
> 
> Josh
> JoshA
> JudgB
> Judg
> Tob
> TobS
> Sus
> SusTh
> Dan
> DanTh
> Bel
> BelTh
> 
> If I understand correctly, you'd like most of these to have name aliases:
> 
> Josh/JoshB
> JoshA/JoshAlt
> JudgB/JudgAlt
> Judg/JudgA
> Tob
> TobS/TobAlt
> Sus
> SusTh/SusAlt
> Dan
> DanTh/DanAlt
> Bel
> BelTh/BelAlt
> 
> Or maybe you'd exclude Theodotion's Daniel from the set.
> 
> 
> I'm not sure what this gains us, but I don't see any real problem with it. Do 
> you envision simply adding the additional names to the canon_abbrevs.h list 
> of abbreviations? It's a quick & simple way of implementing this, but would 
> result in every Bible with an OT returning results for keys like JoshB.1.1.
> 
> --Chris
> 
> 
> ___
> 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] plain filters

[DM Smith]

Do we have any plain text modules any more? Have any of the former plain text 
module been withdrawn w/o being replaced with another format? That is are there 
any legacy reasons to support that module format?

I'm asking as JSword provides limited support (newlines are retained in the 
display, but that's it) for the format. The code is trivial and I don't see any 
reason to remove it if there are legacy modules that might benefit.

In Him,
DM

On Jun 23, 2013, at 7:18 AM, Chris Little  wrote:

> Does anyone have an objection to the complete removal of the plain filters 
> (PLAINHTML and PLAINFOOTNOTES)?
> 
> These are all kinds of bad. They essentially serve to style plaintext modules 
> and toggle footnotes in plaintext modules, and they achieve this by making 
> big assumptions that are unlikely to be correct today (though they might have 
> been in 1999, when these were written).
> 
> For example, if you find {curly braces} in a plaintext module in 2013, it's 
> unlikely to represent footnotes. We long ago move all such pseudo-markup 
> systems to real markup formats.
> 
> The one useful feature (maybe?) is that <, >, and & are escaped by the 
> PLAINHTML filter. But I'm fairly certain no one actually uses this filter in 
> any front end, so even that is of no use in 2013.
> 
> --Chris
> 
> ___
> 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] RTFHTML filter

[DM Smith]

What does SwordWEB use to display About from the conf? Does SWORD have any 
other code that translates the RTF unicode markup that is in some confs? How 
would any frontend handle the 4 RTF codes?

How do other frontends handle the RTF in the About?

Is there a plan for the conf to go to a different format for About? (HTML? or 
OSIS?) 

Again the same legacy question if there is no longer going to be support for 
RTF in conf files.

My interest is from a JSword perspective.

In Him,
DM

On Jun 24, 2013, at 7:12 AM, Chris Little  wrote:

> Similar to my question about the Plain filters:
> Is anyone using the RTFHTML filter?
> 
> It supports only four RTF tags. I believe this was used by BibleTime to 
> convert RTF in .conf About values to HTML. Is it still used by BibleTime? Is 
> it used elsewhere?
> 
> --Chris
> 
> ___
> 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] plain filters

[DM Smith]

On Jun 24, 2013, at 8:18 AM, Chris Little  wrote:

> On 6/24/2013 5:05 AM, David Haslam wrote:
>> Someone could easily count how many by creating a script to find out how many
>> modules have
>> *SourceType=PlainText*
>> in the conf file.
>> 
>> Such a script is probably a one liner in Perl.
>> 
>> A bit more ingenuity would output a counted list of all the source types
>> found in each repository.
> 
> No, that would be pretty useless since Plaintext is the default SourceType 
> and it's virtually never specified explicitly. There are still Plaintext 
> modules, but that's not relevant to the question I asked.
> 
> I'm not proposing dropping support for Plaintext modules, just querying 
> whether anyone uses the PLAINHTML and PLAINFootnotes filters and would mind 
> their removal.
> 
> Are there any modules for which these filters would function correctly? I 
> don't know, but it seems doubtful. We don't even offer a PLAINFootnotes 
> option filter option in SWMgr, nor is PLAINHTML exposed the way that other 
> render filters are.

Thanks for the clarification. Just what I needed.

In Him,
DM


___
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.org HTTPS certificate problems

[DM Smith]

Aside from the certificate issue, you can use http instead of https for SVN. To 
change your working copy from the one URL to the other, you can use the 
command: svn relocate. 

In Him,
DM 

On Jun 25, 2013, at 5:08 AM, David Haslam  wrote:

> We still have an expired certificate!
> 
> Browsers such as Firefox warn or prevent users thus:
> 
> crosswire.org uses an invalid security certificate.
> 
> The certificate is not trusted because it is self-signed.
> The certificate is only valid for www.crosswire.org
> The certificate expired on 2013-05-05 00:03. The current time is 2013-06-25
> 09:59.
> 
> (Error code: sec_error_expired_issuer_certificate)
> 
> I was trying to access sub-directories under 
> https://crosswire.org/svn/sword-tools/trunk/modules/
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/crosswire-org-HTTPS-certificate-problems-tp4652438p4652629.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.org HTTPS certificate problems

[DM Smith]

I'm taking care of it. May take a bit of time. If it works as planned it'll be 
a StartSSL class 2. 

Cent from my fone so theer mite be tipos. ;)

On Jun 9, 2013, at 3:00 PM, Jaak Ristioja  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello!
> 
> Is it just me or does HTTPS on crosswire.org present an invalid
> certificate?
> 
> Blessings,
> Jaak
> 
> 
> $ git svn rebase
> Error validating server certificate for 'https://crosswire.org:443':
> - The certificate is not issued by a trusted authority. Use the
>   fingerprint to validate the certificate manually!
> - The certificate hostname does not match.
> - The certificate has expired.
> Certificate information:
> - Hostname: www.crosswire.org
> - Valid: from Fri, 04 May 2012 23:03:07 GMT until Sat, 04 May 2013
> 23:03:07 GMT
> - Issuer: SomeOrganizationalUnit, SomeOrganization, SomeCity,
> SomeState, --
> - Fingerprint:
> 60:d4:77:54:37:d3:37:ed:42:92:7b:eb:1a:f0:25:f7:50:ff:c2:57
> Certificate problem.
> (R)eject, accept (t)emporarily or accept (p)ermanently?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.19 (GNU/Linux)
> 
> iQgcBAEBAgAGBQJRtNDTAAoJEEqsYmEt1rCOFOhAAIb9vVabagpIhK3uOF9WtBq+
> A7oqwFKjQO9dLVDQw4OU4wJlV8v5dANjEd99uELaZC9Atv97psINqW6er9jIL5KR
> en3R6PT6gWO3hON33gZY/pedDuRGdpZbRPAhfu8Eg+e3zYLPMrm6K4h/D9V0Zwad
> YY356QBkH10Kqc631ikxcQznO/fO/cTCaLxCt2DUUx1S++3ppQcIVTPe40/Dju6/
> dH+IuA+/H4gsrMxN5asftRk2lCPs3KXMGANJW7q4lJlfXiXdAJ5Bl9zNne4LXXRL
> AQWCUwqY3vg148WpRqu0fhcxtkfjbZn2trehBqNvdLsqxRblLhiiHREBdapvcOxN
> K3Ua5VwPquISz37jQwPJDKMpWXAeEsFsY/PCA2jAvPpV1WSG9oh09xYUk99GuDgh
> wHdDcpaPLciTFkU7X/ABGSeL3/yU0q1MfuZo0amPMjBypct3m1gZCO5W1zuzCN7I
> jpZiBWKieMhDTCEYHDoS9xark9JZtPf8Fa0DqzLA5KAL1HRFk3M0tl1ml1xCD8SG
> m1dNSNGvPkmo0X5EL3OOcvXvdVZSb/edWNOBazuDq2BXY5shBr8CxdfC96Sg2oU5
> h3s1u72Ys9tuoX9dZNLu4YqSjuDND7N60RYiXicGrcSuN8l3b9rzGFd5y2JVKpm/
> E2qvn1vY7/vc0yUKn45nSp/wdGnh0X/huig+Xq4+ZDxDWi6jC8sSpW6nBe7Coh5L
> AEw8RxdHyIezGXE7LHtBlB3VpXzAGp0BTPd7oyiYDmCw+MyHKE6WCxoO5jvpN3LA
> JZ+y41aOK80dam0x8jRD+ycGgTyG5ittPWiOaR4qxNkip71j5vLIPrJqI1af9S5Z
> 3jxUrA5HZYPHfg4+ZOHKxKc0JWGpxfLv4F/0w35BRHRn7mP0KsEaO0Wo6EvJt4MN
> LA5qOvsOnI2wYIW0UI1i3mg1/vnxuXs+RVIwQG+9aWQ+j9YO9+aZewzMVL6d3qVS
> F+CGz0iHvUHT8V7WUEMbSSF0jZsz9l9JL0TLSY2VNLXxnSRT5bs7C1odY2+LRo2+
> wPy9ZLTAyTX35Q1r/7aDqRY7TjlbAm+GrE1o7LqxpTZWQEMJ2z7ZxNiGLBsptqis
> uxDeWQIculprj4aYIKPSFm0lJk3zccGeFeQVl1hV040W1mlEzCvBY5UJBKZaWmNM
> jeGkN78keSRA6oKKbQ2vKVzgo2qLnJEPWF3q4tCEvXu3Ok43RQsJpgUyUVdmdqvl
> QWHX3zKf+fZ/aQMgZqwyN22qGE5UtOoONHLtieWRQ/08iYRwoL/dk2LeBBuyok8f
> E9KI0TmT5ucOU4wMQBxlDaufhCztWoSmy3Mvo5M6GFvlbeeq/33ckDFj3uVipFRP
> MHHHeu67ulKokArUO2xdnxt2KE+0ds3lVC+G564k6cy5aNPyS9/SW/oM71eUj5vX
> LlcQDBgWxxCbZ5vDC/+8kk1Dj4pvNSSV9n7fqcrMBsFDToa/j5yVyT716gzyrCvQ
> UMgMTMaLaUU0L4QZHvEDd87VRSdqd5KSnGb+xucCGzcBeODgIb8lAZxYXtTz21lx
> kORdnnSj1m8M5QG+ekJJMmLwp5TJ6ngZupprKYigjRNELj4N3SQ++sffTwuXjH2K
> T7BRh5UHdAL1Rg6fjNRynt8++zv5E0UUHSwbOn0n/ACZjey7+Pq7QSBHWgws9+S9
> djDccyI9DEJbEQ7TEbXeoAMcWPMtVNST73MD4aNEUJ/Ktx6L8fLww+d+wKW8KznW
> 5+luzfU1/Kk/dg5dtldqsx60fuhzgMEZRZH0OjY+EbW0ljVg/Y38LCaztF1AQW9x
> uq7IRyRayFGbaSD6WqTbWqTZhTVwMfQa2zIGDz5jb4WPBVUQoBm0t3MjmknVgKzE
> tfykgAhXlW2UPYvnwPOhAB8ftFQFBkLpsiDR4UTzQcU0x8tkrTusNBQ1IKD8l8oq
> rPqOQvNFvOGDddka3lhyazRx9Dp9WmlzTLIxc74+T2RFGiBzP9GIKG8ir1E7SJ8Q
> MMukbYkyWWaEOOSXe7KSLD7Y5ViUxihRhgnu1nInNxVRsdS7RXHQ35sJTEBId+aV
> gxLcnDmI3Xn7ngCz0oCQFv9mOlrDzStYtOTt9DaQdb/3C5A0ZUaukNnI+nhENYlV
> ZBPVzjhfXGoGMv+TSoB3N71JKlTzXZMelz4sZx3uqHrLy5cgzzflZjOCWTEWaBEG
> 87Vhmd0cRM6tUYOnOni4usXXMBoYzvsNehJV7O1aZxetwFAdh7MBRq5/mP+6dD0M
> DK5Vuil12WlKERwr1o7a6mX/PjVLuTNMGxaIKMNALk5RuLkw2pyCF0y3C8tOdtuB
> FpY4sElRLH0m/ZAHvCPFdtZPQjTAdicmpYQKXbMVddRUt5/hlcvV4HhJ4FOnKEgm
> W/uX7pgSWJLcebLuTLkEyYUTFP8DH6FQjk7c/alSvEuHrNKyKxi9IcXIXa2KUyVF
> PsUqIInz/Hihp753FwadvcZWQ7tvciXlC9cdfDkf+XFuU4sD8WZxp7eXHK6YsmAs
> AVo3fw8qdPcP+LNiIGC6jt4Uj946TD8N06t/I/ec5XZbbmMbgxe01N0iirrrBvYD
> eQFLahWuw4FJg0kuRQus1VBqJa8Behy1Zv6L0JXAecLJ5CbGlcJE/OV+7l5Oa3YG
> BRxekh1fnhP4CYWa+CIw2Nd/cC0QhXvQHtBA6xMts19isxI8AXcmS1FjxgG4cUQM
> bZOe7cqZyHRbt2v4nLZl
> =CEF1
> -END PGP SIGNATURE-
> 
> ___
> 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] Parallel Display of Differing V11n Systems

[DM Smith]

On Jul 4, 2013, at 12:01 PM, Troy A. Griffitts  wrote:

> We have a design in place which allows for the code example I previously 
> mentioned:
> 
> lxx->setKey(nasb->getKey())

What Chris might not realize in this simple statement: In SWORD a module has 
the notion of current key. The module and the key each know their own 
versification.

> 
> The engine recognized that the versifications are different and calls a 
> facility to do the translation.

If I understand this correctly, the lxx.setKey will see that the v11n of the 
argument is different and needing translation by lookup. That lookup will get 
the equivalent for that verse. In most cases, there is no difference. In a made 
up example, Ps 14.1 in the NASB might be Ps 14.2 in the LXX. (Looking at the 
code, it always does the lookup.)

The front-end then has two current keys (verses) that it can display side by 
side. It can display the verse reference differences if desired.

>   We have not finalized on this facility yet. As also mentioned, Костя has 
> submitted an implementation (long long ago) available here (not sure if this 
> is his latest version, as he is using it now in Bibletime Mobile):
> 
> http://crosswire.org/~kalemas/work/v11nmapping/
> 
> I am happy for his submission.  We would like to include it or something 
> based off of it, but before we finalize something in the engine for everyone 
> to use, I want to be sure we handle the basic issues mentioned in my 
> preceding email on this.  I am not convinced I have mentioned all issues with 
> implementing a parallel display frontend because I have not yet tried to 
> implement a parallel display frontend which tries to implement the 'superset' 
> view described in my previous email.
> 
> Chris, you are in an ideal position to give feedback on this-- though it 
> won't be as helpful for me or the solution within the SWORD engine, because 
> I'm sure JSword has a completely different facility for versification classes 
> internally.  But regardless, your experience and feedback are invaluable as 
> you drudge through this task.  Let us know what you decide.

The implementation in JSword differs from that in SWORD with regard to the 
tables that are used for versification. SWORD reads in its tables and then 
optimizes them in core. JSword starts with different tables and then optimizes 
them in core. These optimized tables are substantially the same.

The problem with having different implementations is what is done when a bug is 
found in the v11n data. If the tables were the same then it would be trivial.

I think AndBible is using the tables from Костя with minor changes. STEP is 
using a different algorithm and tables.

In Him,
DM

> 
> Troy
> 
> 
> 
> 
> 
> On 07/04/2013 05:29 PM, Chris Burrell wrote:
>> I'm guess I've misunderstood as Ps.51 shows the wrong alignment between 
>> Hebrew and English for the first two verses... What are these "translation 
>> facilities currently designed in the engine"?
>> Chris
>> 
>> 
>> 
>> On 4 July 2013 16:24, Chris Burrell  wrote:
>> I'm afraid, I'm not sure I follow. The screenshot looks ok, but then I don't 
>> read Greek or Hebrew so I don't really know.
>> 
>> Are you saying Sword already has translation from 1 versification to another 
>> transparently, by " the v11n translation facilities currently designed in 
>> the engine"? From previous threads, I thought that was one major thing that 
>> was still being worked on. So you already do have all the mappings to 
>> convert from one versification to another?
>> 
>> I'm confused!
>> 
>> Chris
>> 
>> 
>> 
>> On 4 July 2013 16:02, Troy A. Griffitts  wrote:
>> Hi guys. The questions that need answers in this thread are logically 
>> complex and are one of the reasons we haven't finalized any additions to the 
>>   core SWORD library to support this-- though I greatly 
>> appreciate the contributions made by Костя.
>> 
>> Take, for example our standard 4 Bible web display preset for "OT Scholar", 
>> at Daniel chapter 3, around veres 23:
>> 
>> http://crosswire.org/study/parallelstudy.jsp?del=all&add=NASB&add=WLC&add=KJV&add=LXX&key=Dan.3.23#cv
>> 
>> How should this look?
>> 
>> The problem, for the uninitiated, is that The Prayer of Azariah and the Song 
>> of the Three Jews in the LXX is inserted between what we traditionally think 
>> of as verses 23 and 24. This makes verse 24 in the KJV very different 
>> content than what should be verse 24 in the LXX (our current LXX displayed 
>> from the link above does not include Apocryphal content)-- verse 24 in the 
>> LXX being the first part of the Apocryphal content, thus verse 91 in the LXX 
>> picking back up where verse 24, in say the NASB (without the apocryphal 
>> insertion), continues.
>> 
>> The web interface above always displays in windows of 1 chapter. Thus the 
>> user has asked for Chapter 3 of Daniel, centered on verse 23.
>> 
>> There are a few questions to answer.
>> 
>> What if they had asked f

Re: [sword-devel] Versifications and verse order

[DM Smith]

As noted by Troy, this is not an issue once the mapping facility is baked into 
SWORD. It will cope with books having different ordering of keys.

When showing parallel content, one translation is picked as the master. Those 
verses are shown in order. Corresponding verses from the other translations are 
shown in parallel. It might be a good idea to show the reference for each as 
they might be different.

I think the confusion is that a given module cannot have verses out of order 
with respect to its v11n. As Greg pointed out, the module builders (e.g. 
osis2mod) store the verses according to their reference, not their order. So if 
you had a module input with:
b.c.2, b.c.5, b.c.1, b.c.3, b.c.4
it would be stored as:
b.c.1, b.c.2, b.c.3, b.c.4, b.c.5
(The tricky part is that the interverse content might not wind up where 
expected.)

Same is true with the order of books and the order of chapters. As far as the 
module builders go, it is fine for the books to be in any order, even 
alphabetical.

In Him,
DM

On Jul 4, 2013, at 5:17 AM, Chris Burrell  wrote:

> So, my understanding from all the previous emails, is No we don't cope for 
> books with different orders of keys. However these do happen. Moreover, the 
> more general case of content from 1 verse switched with the content of 
> another is more prevalent.
> 
> So it's quite feasible to have a system that maps to the KJV as follows:
> a -> a
> b-> c
> c-> b
> 
> where a, b, c is the normal order in each of the books. As a result, we can't 
> simply iterate through them sequentially downwards.
> 
> (yes, the example is simplified as keys can map to multiple other keys, etc.)
> Chris
> 
> 
> 
> 
> 
> On 3 July 2013 21:36, Chris Burrell  wrote:
> Response from Michael below. 
> 
> 
> On 3 July 2013 21:25, Kahunapule Michael Johnson  wrote:
> On 07/03/2013 10:07 AM, Chris Burrell wrote:
> >
> > In your example about the Psalms, within the versification itself you still 
> > have the verses in the same order, so that wouldn't be a problem. But I 
> > think you're saying you might have the content of verse 1 and the content 
> > of verse 2 swapped around... Is that right? Would the numbering be swapped 
> > around too? Presumably not...
> >
> 
> I have seen a versification where the numbers were swapped around, too... but 
> I don't remember exactly where that was. It is fairly rare. Normally, the 
> content would be left in place and the verses renumbered to make a Sword 
> 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

___
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