[sword-devel] Small problem with section headers in an OSIS module

Daniel Owens dhowens at pmbx.net
Sun Nov 30 02:20:06 MST 2008



Chris Little wrote:
> 
> Daniel Owens wrote:
>> Chris Little wrote:
>>> Tom Cornell wrote:
> 
>> I've had this problem with the VietNVB in the beta repository. Not sure 
>> what was done to make the ESV look so pretty, but I haven't been able to 
>> reliably reproduce it with the NVB myself. Look at Genesis 1.
>> - BT 1.6.5.1 (Sword 1.5.11) displays all headings, but v. 26 has the 
>> verse number on it's own line, just like what you describe. It think 
>> this is unique to BT, though I have seen it in the past in BibleDesktop.
>> - BibleDesktop 1.6 doesn't display any headings as headings in that 
>> chapter, though the heading for v. 26 appears as verse text.
>> - GnomeSword 2.4.0 does fairly well with all the headings, though the 
>> first one is appended to the end of the book introduction.
> 
> I think the appended title is not due the filters/frontend (GS). I think 
> osis2mod has physically appended the first title to the intro section 
> because of what I would class as an encoding error (in the imported 
> OSIS). Looking at the text, the first section and title begin before the 
> Gen.1 chapter marker. I think the importer is acting correctly here by 
> including everything before the first chapter marker within the intro 
> section, and I would guess that if you moved the chapter marker up by 
> two lines, it would render as you desire in GS. As it is, it's not 
> getting the special "pre-verse" treatment.
> 

Thanks, I will go back over the source text and try to fix that problem. 
I realized that my VB1926 posted on biblevietnam.org didn't have the 
same problem, so I was about to go compare the two.

>> - BPBible misses the first heading but gets the one in v. 26.
>> - Not sure what BibleCS does...
> 
> BibleCS renders everything correctly, which is to say that the v.1 title 
> gets rendered within the intro but the v.26 title is rendered above the 
> v.26 marker, and v.26 itself follows on the same line as the marker.
> 
> Most features like this were developed on/for BibleCS first, so it's not 
> a great surprise to find it working there.
> 
> However, in Matt.1, there are two titles on Matt.1.18, which is 
> confusing something (probably the importer). It's resulting in rendering of:
> (Lu 2:1-7)
> 18
> Câu Chuyện Giáng Sinh Của Chúa Cứu Thế Giê-su
>   Sự giáng sinh của Chúa Cứu Thế Giê-su đã xảy ra như sau: ....
> 
> Here, we would expect, instead, to see the third line (the section 
> title) first, followed by the first line (the parallel section) on its 
> own line, followed by lines 2 and 4 together on a third line.

Yes, I noticed this problem. All parallel passages in the Gospels 
display improperly. Any ideas for a solution (on the encoding side), or 
is this just an OSIS support issue?

> 
>>> When I committed a new version of osis2mod 3-4 years ago that did all of 
>>> this (in a way that neither harmed existing nor future data) it was 
>>> roundly rejected and reverted. I'm still convinced that preservation, 
>>> including storing <verse>, is the only solution to certain of our 
>>> problems. And I'm hoping that DM and I can convince the naysayers of the 
>>> merits of that position.
>> I hope you do. Is it a programming or performance issue? Aside from 
>> momentum, what's holding this back? It makes perfect sense to me, and it 
>> would make it easer to go from osis to mod to osis and back to mod with 
>> little lost, I would think.
> 
> I think it was a lack of providing a convincing argument issue and an 
> issue of failing to demonstrate that the new paradigm wouldn't need to 
> break existing data and implementations. I also included an argument 
> that it would provide a different way of providing verse numbers not 
> supported by Sword (outside the KJV versification), which I think 
> distracted from the issue.
> 
> Implementation is easy. Performance difference would be trivial. The 
> greatest issue was simply accepting a second paradigm of OSIS module 
> encoding, which would require that we know somehow whether a module was 
> including <verse> elements or not. But I think we could probably deal 
> with that somehow.
> 
> --Chris
> 
> _______________________________________________
> 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

-- 
PMBX license 1502



More information about the sword-devel mailing list