[sword-devel] Poetry, verse 0, setIntros() and the state of things thus.

Tue Feb 5 05:23:31 MST 2013

A bit more on osis2mod and <lg>.

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 <verse> 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 <lg> as it is transformed from it's container form to its milestoned form. The <l> elements, whether milestoned or not are not allowed anywhere but in an <lg> element. This is a bug in the OSIS spec. Either the <lg> element has to change to not be milestoned or the container elements for <lg> have to be modified to allow <l> (as has been done with <lb/>. I think the latter.

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

So the ESV, when presented to osis2mod was valid BSP OSIS. Note that in a few instances, the <lg> 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 <div type="section"> 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 <niccarter at mac.com> 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 <benpmorgan at gmail.com> 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 <lg>s and infer them from the <l> (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 <q> - Words of Jesus, <lg>, 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 <lg> 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 <niccarter at mac.com> 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 <l>s outside of <lg>s. This then simply makes things look messy and so I have had to write more code to work around this, but I've done this in Objective-C as I couldn't figure out how to save state between subsequent calls to renderText().
>> 
>> Note that I now also always retrieve verse 0 for each and every chapter in order to gather any required formatting that is missing from verse 1, but as verse 0 often is simply "<br />", I check for this and simply discard verse 0 if that's what it is. :)
>> 
>> As it appears that the ESV is going to be ready soon, perhaps an option is for us to add checking of <l> inside <lg>s as part of our OSIS validation and hold off incorporating any poetry code into SWORD until we know our modules are good enough?
>> 
>> However, what is the "proper" way of encoding these indented lines in OSIS? The WEB module opens its <l> tags at the end of each verse for the line starting in the next verse. This seems weird to me, and I would have thought that it would make more sense to start the verse with the <l> as that is where the text corresponding to that <l> is located?
>> 
>> So, yes, for me this is revealing more inconsistencies between modules and how they have been constructed. And as I don't particularly know what is the "correct" way of forming the OSIS, I don't know which is the "correct" way to be coding this.
>> 
>> 
>> Thanks, ybic
>>         nic...  :)
>> 
>> _______________________________________________
>> sword-devel mailing list: sword-devel at 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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130205/9a071c75/attachment.html>