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 <niccar...@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 <benpmor...@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 <niccar...@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@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
