Re: [sword-devel] Odd character in KJV

[Ben Morgan]

Hi DM,

That's an ampersand i.e. &
https://en.wiktionary.org/wiki/%26c.

Thanks,
Ben

On Wed, Feb 3, 2016 at 3:34 PM DM Smith  wrote:

> Does anyone know what the attached glyph is called? It is used with a
> following c. to mean etc. I’d like to see if it is in Unicode.
>
> ___
> sword-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 Python bindings for Windows

[Ben Morgan]

I think those items are all the data definitions.

I've run into errors like that before. If you are buildings Sword itself as
a DLL, you need to define the macro SWUSINGDLL while compiling the C++
bindings code for it all to work. I forget exactly how you change setup.py
to make it do that, though, but have a look here:
https://docs.python.org/2/extending/building.html

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, Oct 7, 2014 at 11:02 AM, R Johnson 
ps16thypresenceisfullnessof...@gmail.com wrote:

 I also tried changing the command in step 3 (setup.py build) to use
 libsword.lib rather than sword.lib by replacing the lines in the setup.py
 file:

 setup(name='sword',version='1.7.3',
 libraries=[('sword')],

 with:

 setup(name='libsword',version='1.7.3',
 libraries=[('libsword')],

 but I got the same errors that I did when I tried renaming sword.lib to
 libsword.lib.

 I have attached the output from setup.py containing the errors, and would
 appreciate any ideas as to what is causing them. I'm a SWIG newbie, but
 could the errors mean that the SWIG interface (.i) files are missing the
 definitions of certain functions/attributes? (I really don't know what
 unresolved external symbols are, so this stuff is over my head.)

 -- Timothy

 ___
 sword-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] Building Python binding to Sword on Windows returns exit code 1

[Ben Morgan]

This probably doesn't directly help your issues here, but the SWIG 3.0
issue seems to have been fixed in SWIG 3.0.1 which was released yesterday.
http://sourceforge.net/p/swig/news/2014/05/swig-301-released/

   - A few notable regressions introduced in 3.0.0 have been fixed - in
   Lua, nested classes and parsing of operator .

As for this one here, I would try the sword_static, ignore the errors
building the samples, and copy the sword.lib like you found you had to.
That might work, but probably won't either.

Greg, is it possible the non-static one doesn't define SWUSINGDLL when
compiling the swig generated code? If I remember rightly, that causes
issues.
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 Sat, May 17, 2014 at 11:36 AM, R Johnson 
ps16thypresenceisfullnessof...@gmail.com wrote:

 I now have gotten closer to being able to do what I want, but still not
 quite there yet (sigh).

 I tried to build the 'libsword' solution without the 'sword_static'
 project, but then I actually got more errors than before. I have attached
 the output I got.

 I then tried building only the 'sword' project, which is (I think) the
 only project that must be built as a prerequisite to the 'swordswig'
 project. This worked OK without any errors.

 I then tried building the 'swordswig' project, which is of course
 necessary in order to build the Python bindings. Before doing so, I
 downgraded my version of SWIG to 2.0.12, so that I would not run into the
 SWIG 3.0.0 bug we discovered. The 'swordswig' build is getting farther now
 than it had before, but it still gives some errors. First it gave an error
 about not being able to open 'sword.lib'. Through a bit of experimenting, I
 found out that this was because it was looking for it in the 'sword-build'
 directory rather than its 'Release' subdirectory. I think this may be a bug
 that needs be fixed in the CMake file. I worked around it, however, by
 copying 'sword.lib' from the 'Release' subdirectory to the 'sword-build'
 directory. Since I did that, however, it is giving me other errors that I
 am not knowledgeable enough to solve. I have attached the output I got from
 building 'swordswig', first before I copied the 'sword.lib' file, and
 secondly afterwards. In the second build log, SWIG complains that there are
 35 unresolved externals.

 Thank you again for your help.

 -- Timothy

 ___
 sword-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] Building Python binding to Sword on Windows returns exit code 1

[Ben Morgan]

I think  the key is here in your first email:
  1..\..\..\include\swbuf.h(362): error : Syntax error in input(3).
What is on the line it mentions? You may be missing a #define which matters.

It's possible no one has tested it with Swig 3.0 (I haven't built for a
while, but I used SWIG 1.3.31 last time I did), and it could have changed

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 Sat, May 10, 2014 at 9:59 AM, R Johnson 
ps16thypresenceisfullnessof...@gmail.com wrote:

 I just tried building this again with the new version of Sword (1.7.3) and
 it still doesn't work.

 I forgot to mention in my previous e-mail that I have added SWIG to my
 PATH environment variable and set the PYTHON_INCLUDE and PYTHON_LIB
 environment variables as required.

 I have also attached the upgrade log that VS2010 created after it
 converted libsword_pythonsword.vcproj from the old format to the new one,
 in case it is of any use.

 Does anyone have any idea what I am doing wrong? Thank you.

 -- Timothy

 ___
 sword-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...

[Ben Morgan]

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 scr...@crosswire.orgwrote:

 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-42http://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-189http://www.crosswire.org/tracker/browse/MOD-189





 --
 View this message in context: http://sword-dev.350566.n4.**
 nabble.com/I-implore-you-**tp4652437p4652452.htmlhttp://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-develhttp://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-develhttp://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?

[Ben Morgan]

BPBible already has code which (attempts) to check if a chapter is present.
https://code.google.com/p/bpbible/source/browse/trunk/backend/book.py?spec=svn1419r=1414#716

Note this isn't yet av11n compliant, but the general principle should be
much the same. It's in Python but should be pretty much the same in C++

Basically, this takes advantage of hasEntry and also of module.
setSkipConsecutiveLinks(True) and module.increment()

(similar code is also used in the rendering loop so that it can detect
linked verses to give verse numbers like 3-5, see the somewhat messy code
here
https://code.google.com/p/bpbible/source/browse/trunk/backend/book.py?spec=svn1419r=1414#231
)

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, May 13, 2013 at 6:57 PM, John Austin gpl.programs.i...@gmail.comwrote:



 On 05/13/2013 10:30 AM, Troy A. Griffitts wrote:

 We have the first part already in the API:

 SWModule::hasEntry(const SWKey *)

 What sort of use cases do we have to build further API calls on this?

 vectorstring getBooksPresent()

 ???

 Yes- or even just:

 bool isBookPresent(aBook)

 and there also probably needs to be something like:

 int lastChapterPresent(aBook)

 An example of why this would be useful is seen in v11n Synodal, the book
 of Daniel. The last two chapters (13-14) are Apocryphal material which many
 translations purposefully exclude. Psalms 151 in Synodal is the same. So
 something like lastChapterPresent(aBook) allows correct building of chapter
 lists etc.

 and then something like:

 int lastVersePresent(aBook, aChapter)

 An example for its usefulness would again be in Synodal, the book of
 Daniel. Daniel chapter 3 verses 34-100 are Apocryphal and will be excluded
 from many Synodal modules. Having lastVersePresent would allow verse lists
 etc. to be built according to the actual module's content.

 Usually these last-Present functions would simply check hasEntry on the
 last unit and quickly return. Only in rare cases would they actually need
 to iterate to find the answer.

 This API has the advantage over the Scope .conf param in that it allows
 module content to be fully queried even if the module makers failed to
 supply a Scope param. On the other hand, it requires installation of the
 module before scope can be determined, whereas having Scope in the .conf
 allows pre-install knowledge of what's in a given module. But if this
 becomes the Scope param's only usefulness, maybe Scope should then be
 simplified substantially to indicate only the included books within the
 module, and not chapters and verses too, which can get hairy.

 John








 On 05/12/2013 07:11 PM, DM Smith wrote:

 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 dmsm...@crosswire.org 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 niccar...@mac.com wrote:

  Hi DM,

 On 12/05/2013, at 7:40 AM, DM Smith dmsm...@crosswire.org 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-develhttp://www.crosswire.org/mailman/listinfo/sword-devel
 Instructions to unsubscribe/change your settings at above page


 __**_
 sword-devel mailing 

Re: [sword-devel] Hebrew font

[Ben Morgan]

That's UTF8 encoded text - decoded it reads בְּרֵאשִׁ֖ית

On Fri, Mar 1, 2013 at 1:42 PM, Philip K wegetourm...@gmail.com wrote:

 ×‘Ö¼Ö°×¨Öµ× ×©× Ö´Ö–×™×ª


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)
___
sword-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

[Ben Morgan]

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?).
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?)
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 q contains the paragraph marker:
q marker= who=Jesusmilestone marker=¶ type=x-p/

Was this a deliberate change? This doesn't work with BPBibles code as-is
(though I could probably get it to work with a little more hacking). In
general, BPBible:
1) turns pilcrows into paragraphs
2) floats whitespace before verse numbers

At the moment, the paragraph tag doesn't float out before the verse number
due to the q 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.

Also, in BPBible at least words of Christ are done with span tags, and
having the p 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 chapter tag
which now shows up in v0. e.g.

chapter chapterTitle=CHAPTER 1. osisID=Rom.1 sID=gen1730/
title type=chapterCHAPTER 1./title

Is there any expectation this will be used? Does it need to be retained
here (seeing as title is there too)?

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 dmsm...@crosswire.org 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

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

[Ben Morgan]

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
lgs 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 ls outside of lgs. 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 lgs 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

Re: [sword-devel] poetry formatting (was Re: Vertical whitespace)

[Ben Morgan]

Some of it is going to require CSS support anyway to do the layout.
If there's just a div with a CSS class, frontends can handle that as they
require, and the indenting support shouldn't cause an issue.

BTW, with the Proverbs 28 issue, my guess is the opening lg is a few
chapters earlier.

In the l handling code, I have these lines:
if not self.in_lg:
 dprint(WARNING, l outside lg??? (or block doesn't contain lg))
self.start_lg(None)

In other words, we always have an implicit lg if there wasn't one in the
current chapter and we got to an l.
This seems to work very well.

Looking forward to seeing poetry support in PocketSword...

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, Feb 4, 2013 at 12:25 AM, Nic Carter niccar...@mac.com wrote:


 Thanks heaps for this, Ben :)

 Appears I had a little bug in the previous patch I emailed around. When
 closing the div on line 379 of osishtmlhref.cpp I had added a br /
 which shouldn't be there!

 I like how you have BPBible displaying this stuff, and so it's inspired me
 to fix up some of the formatting in PS. :) I've even rewritten how I do
 highlighting to do it properly  not break the HTML badly so that this
 will work :P
 I've had to have different css stuff for PS based on whether it's on a
 small iPhone screen or a larger iPad screen  after hacking this myself, I
 saw your 500px versions  incorporated them as well :)

 All this to say, perhaps in the SWORD API we should have apps be able to
 flag whether they want poetry indenting on or off, cause it is quite
 possible that it will break formatting that the different front-ends do,
 and so if we have it off by default, front-ends will have to accommodate it
 and then manually switch it on, thereby not breaking how things
 look/work...?  ;)
 [or, at least, I've spent much more time fixing PS to work with the
 changes I made to SWORD than I did implementing the poetry indentation in
 SWORD!]

 Thanks heaps, ybic
 nic...  :)


 On 02/02/2013, at 10:14 PM, Ben Morgan benpmor...@gmail.com wrote:

 Hi Nic,

 Structural content in verse 0 is another good example why you shouldn't
 turn introductions off - I think they should always be on, just the
 headings inside them (when non-canonical) should be able to be turned off.

 As for floating the whitespace around, this is a post-process and mostly
 done using regular expressions.
 See SmartBody here:
 https://code.google.com/p/bpbible/source/browse/trunk/backend/verse_template.py#49

 This allows the verse number to be put in at a logical point in the
 whitespace flow (e.g. If a paragraph starts at the start of a verse, you
 want the verse number to be inside the paragraph).

 As to the floating the verse number in poetry it uses this CSS to put it
 in the left margin of the lg:

 https://code.google.com/p/bpbible/source/browse/trunk/css/bpbible_chapter_view.css
 .chapterview blockquote.lg  a.versenumber,
 .chapterview blockquote.lg  span.had_highlight  a.versenumber
 {
 position: relative;
  float: left;
 left: -4em;
 width: 3em;
  text-align: center;
 line-height: inherit;
 }

 .chapterview blockquote.lg a.chapternumber
 {
 width: 1.5em;
 text-align: center;
 -moz-margin-start: -2em;
  line-height: 100%;
 font-size: 150%;
 }

 Disclaimer on my CSS:
 I put in what made it work - no guarantees that it is nice/efficient. It
 does appear to be mostly functional
 It's specifically mozilla oriented, and may not work elsewhere.

 That said, it can work elsewhere - I've got the poetry layout with verse
 numbers etc. working on my Kindle. I haven't checked in the code yet which
 generates the epub to be transformed for Kindle, but some of the CSS
 changes I made for that make it less mozilla oriented.

 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 Sat, Feb 2, 2013 at 4:49 PM, Nic Carter niccar...@mac.com wrote:


 Thanks heaps for this :)
 I'm getting there, but have encountered a few interesting bits. I'm using
 the ESV and something I just realised was that Psalm 1 only had a closing
 lg tag at the end of verse 6  no opening tag:
  lg eID=w106/
 I couldn't find the opening one anywhere in the chapter.

 Until I looked at Psalm 1:0
  then I found it!

 Anyway, I have it mostly working (besides for cases like the above, where
 you _need_ to have the Introductions switched on for the formatting to work
 correctly).

 However, the tricky thing for this to then work with PS is the verse
 numbers, where you talk about doing some floating block whitespace to
 make it work more nicely. I'm gonna try to look at what BPBible does in
 regards to that, cause I'm a novice when it comes to HTML now-a-days...


 Thanks, ybic
 nic...  :)

 On 02/02/2013, at 12:02 AM, Ben Morgan benpmor

Re: [sword-devel] poetry formatting (was Re: Vertical whitespace)

[Ben Morgan]

Hi Nic,

Structural content in verse 0 is another good example why you shouldn't
turn introductions off - I think they should always be on, just the
headings inside them (when non-canonical) should be able to be turned off.

As for floating the whitespace around, this is a post-process and mostly
done using regular expressions.
See SmartBody here:
https://code.google.com/p/bpbible/source/browse/trunk/backend/verse_template.py#49

This allows the verse number to be put in at a logical point in the
whitespace flow (e.g. If a paragraph starts at the start of a verse, you
want the verse number to be inside the paragraph).

As to the floating the verse number in poetry it uses this CSS to put it in
the left margin of the lg:
https://code.google.com/p/bpbible/source/browse/trunk/css/bpbible_chapter_view.css
.chapterview blockquote.lg  a.versenumber,
.chapterview blockquote.lg  span.had_highlight  a.versenumber
{
position: relative;
 float: left;
left: -4em;
width: 3em;
 text-align: center;
line-height: inherit;
}

.chapterview blockquote.lg a.chapternumber
{
width: 1.5em;
text-align: center;
-moz-margin-start: -2em;
 line-height: 100%;
font-size: 150%;
}

Disclaimer on my CSS:
I put in what made it work - no guarantees that it is nice/efficient. It
does appear to be mostly functional
It's specifically mozilla oriented, and may not work elsewhere.

That said, it can work elsewhere - I've got the poetry layout with verse
numbers etc. working on my Kindle. I haven't checked in the code yet which
generates the epub to be transformed for Kindle, but some of the CSS
changes I made for that make it less mozilla oriented.

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 Sat, Feb 2, 2013 at 4:49 PM, Nic Carter niccar...@mac.com wrote:


 Thanks heaps for this :)
 I'm getting there, but have encountered a few interesting bits. I'm using
 the ESV and something I just realised was that Psalm 1 only had a closing
 lg tag at the end of verse 6  no opening tag:
  lg eID=w106/
 I couldn't find the opening one anywhere in the chapter.

 Until I looked at Psalm 1:0
  then I found it!

 Anyway, I have it mostly working (besides for cases like the above, where
 you _need_ to have the Introductions switched on for the formatting to work
 correctly).

 However, the tricky thing for this to then work with PS is the verse
 numbers, where you talk about doing some floating block whitespace to
 make it work more nicely. I'm gonna try to look at what BPBible does in
 regards to that, cause I'm a novice when it comes to HTML now-a-days...


 Thanks, ybic
 nic...  :)

 On 02/02/2013, at 12:02 AM, Ben Morgan benpmor...@gmail.com wrote:

 I've found vertical whitespace can be problematic, and it's often around
 verse boundaries.

 osis2mod often seems to put some of the whitespace in the previous
 verse/chapter, which I think I reported a long time ago and should be
 fixed. I remember we had trouble finding the right combination of when to
 start a verse. I have a vague feeling I had suggested some fixes which
 weren't ever put in - but I can't be sure, and it's possible there might
 have been some which caused other issues.

 BPBible does some things like floating block whitespace before verse
 numbers etc. to make this work more nicely.

 As for the two-level poetry layout (or 3 level - e.g. ESV 1 Tim 3:16),
 BPBible has done this for ages (e.g. try opening ESV in psalms). It's not
 particularly straightforward to implement well though. A brief overview of
 how it is done:

 The start tag l gets handled something like so:
 mapping = {
 # usual poetry indent in ESV
  x-indent: 2,

 # extra indent - 1 Tim 3:16 (ESV) for example
  x-indent-2: 4,

 # declares lines - Declares the Lord, Says the Lord, etc.
  x-declares: 6,
  # doxology - Amen and Amen - Psalms 41:13, 72:19, 89:52 in ESV
  x-psalm-doxology: 6,

 # usual poetry indent in WEB
  x-secondary: 2,
 }

 level = xmltag.getAttribute(level)
  if level:
 # the level defaults to 1 - i.e. no indent
 indent = 2 * (int(level) - 1)
  else:
 indent = mapping.get(xmltag.getAttribute(type), 0)

  #if indent:
 if self.in_indent:
 dprint(WARNING, Nested indented l's, self.u.key.getText())

 self.in_indent = True
 if not self.in_copy_verses_mode:
 self.buf += 'div class=indentedline width-%d source=l' % indent
  self.blocklevel_start()

 and end tag like so:
 def end_l(self, xmltag):
  if self.in_indent:
 self.blocklevel_end()
  self.buf += br if self.in_copy_verses_mode else /div

 lg elements are also handled, turning them into blockquotes.

 This is matched up with CSS like so (note, there's a lot more in it than
 this to handle floating verse numbers outside of poetry etc):
 /* Poetry */
 blockquote.lg
 {
 margin: 0.5em 0em 0.5em 3em;
 }

 /* We want our indented lines to behave nicely - wrapped lines should be
  * indented further. text-indent undoes

Re: [sword-devel] Small Fix for Mark 9:43 in KJV module

[Ben Morgan]

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 dfh...@googlemail.com 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

Re: [sword-devel] Vertical whitespace

[Ben Morgan]

I've found vertical whitespace can be problematic, and it's often around
verse boundaries.

osis2mod often seems to put some of the whitespace in the previous
verse/chapter, which I think I reported a long time ago and should be
fixed. I remember we had trouble finding the right combination of when to
start a verse. I have a vague feeling I had suggested some fixes which
weren't ever put in - but I can't be sure, and it's possible there might
have been some which caused other issues.

BPBible does some things like floating block whitespace before verse
numbers etc. to make this work more nicely.

As for the two-level poetry layout (or 3 level - e.g. ESV 1 Tim 3:16),
BPBible has done this for ages (e.g. try opening ESV in psalms). It's not
particularly straightforward to implement well though. A brief overview of
how it is done:

The start tag l gets handled something like so:
mapping = {
# usual poetry indent in ESV
 x-indent: 2,

# extra indent - 1 Tim 3:16 (ESV) for example
 x-indent-2: 4,

# declares lines - Declares the Lord, Says the Lord, etc.
 x-declares: 6,
 # doxology - Amen and Amen - Psalms 41:13, 72:19, 89:52 in ESV
 x-psalm-doxology: 6,

# usual poetry indent in WEB
 x-secondary: 2,
}

level = xmltag.getAttribute(level)
 if level:
# the level defaults to 1 - i.e. no indent
indent = 2 * (int(level) - 1)
 else:
indent = mapping.get(xmltag.getAttribute(type), 0)

 #if indent:
if self.in_indent:
dprint(WARNING, Nested indented l's, self.u.key.getText())

self.in_indent = True
if not self.in_copy_verses_mode:
self.buf += 'div class=indentedline width-%d source=l' % indent
 self.blocklevel_start()

and end tag like so:
def end_l(self, xmltag):
 if self.in_indent:
self.blocklevel_end()
 self.buf += br if self.in_copy_verses_mode else /div

lg elements are also handled, turning them into blockquotes.

This is matched up with CSS like so (note, there's a lot more in it than
this to handle floating verse numbers outside of poetry etc):
/* Poetry */
blockquote.lg
{
margin: 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 niccar...@mac.com wrote:


 Is this caused by improperly formed modules that have fun with l poetry
  lb ?
 [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 dmsm...@crosswire.org 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, div,
 chapter, p, lb/, lg, l, title, table and row 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 div.
 
  In HTML, an empty div occupies no vertical space. A nested div does
 not cause additional vertical space.
 
  In HTML, a p has semantics as to whether it is preceded or followed by
 whitespace. A p at the beginning of a document is not preceded by a blank
 line. Nor is a /p at the end of a document. This is also true after a
 heading element.
 
  I think that the SWORD renderers always cause a div to occupy vertical
 whitespace.
 
  The other issue with div is that we now have a pre-verse div, which
 is a great way of marking off what stands before a verse, but this div
 really shouldn't have any div semantic. It probably would have been
 better if we used milestone instead.
 
  I seem to remember that there is a swollow flag for whitespace (I
 think it might be for horizontal whitespace.) I think 

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

[Ben Morgan]

If I remember correctly BPBible's headings option turns off non-canonical
headings.

When rendering text, vk.Headings()/setIntros() would always be on. There's
no way to turn off prechapter content, just like there's no way to turn off
every verse 5 [?]

(if it doesn't work this way in some situations, I think it should as I
believe this is the desired mode of operation)

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, Jan 22, 2013 at 8:42 AM, Karl Kleinpaste k...@kleinpaste.orgwrote:

 Xiphos displays 0:0 and n:0 intro material based on the user's single
 per-module setting for headings.  It's not because of the engine; it's
 because that's how the handling of getting the boundary verse before the
 current chapter is handled.

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

330.gif___
sword-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] Method Name Normalization

[Ben Morgan]

Hi Greg,

On Mon, Jan 21, 2013 at 6:28 AM, Greg Hellings greg.helli...@gmail.comwrote:




 SWIG bindings now up-to-date.

 Bindings users, please holler if I removed things overzealously.

 I haven't tried it, but I believe that this will break BPBible for example.

As the bindings are part of SWORD, I believe it makes sense to mirror the
deprecations in the bindings somehow if possible, rather than ignoring the
deprecated definitions.
I know that's what e.g. wxPython does, but I'm not sure how it does it.

Doing this will make it easier to support both SWORD 1.6 and SVN, which I
think is desirable until a couple of versions down the road.

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)
___
sword-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] filter !P patch

[Ben Morgan]

On Fri, Dec 14, 2012 at 11:58 PM, Karl Kleinpaste k...@kleinpaste.orgwrote:

 Ben Morgan benpmor...@gmail.com writes:
  Look back at the conversations on ' div type=paragraph ' from
 September.
  Troy said he was happy to remove !P if Xiphos didn't use it. Someone
  needs to work out why it's in there, and whether it is really needed,
 then
  probably adapt the filters to remove it altogether if possible (possibly
  replacing it with something else).

 I already mentioned back on 17 Sep that Xiphos' very old (pre-me) code
 which detects !P is there only to substitute para; into the stream
 afterward.  It's used exclusively for KJV (hardcoded), and I wondered
 aloud then (and still now) whether this is something that properly
 belongs in the filter to begin with, and to apply to KJV-related
 modules, to which no one had any reaction.

 Take !P out.  Optionally put para; in, and make it specific to
 KJV-ish modules.


!P and !/P get generated by TEIHTMLHREF and OSISHTMLHREF for
paragraphs, and if anything, should be changed into open/closing p tags.

It looks like one of the markers which gets processed in this way (but only
one) are the

milestone marker=¶ type=x-p/

tags in the KJV which also get turned into this construct. BPBible
generates a paragraph break here too, which I think is desirable, though it
may not match a print KJV.

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)
___
sword-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] filter !P patch

[Ben Morgan]

G'day Ben,

From the viewpoint of a frontend developer, I don't really want this change
committed.

If this change is committed, it will break existing frontends which look
for !P, and it produces little or no benefit - !P may be invalid, but I
think it will just get ignored.
We already don't really have a good way to generate completely validated
HTML as it is as too many of the existing modules have markup issues (I've
been running across these recently...)

If it is ever a problem for anyone, I think it's easy enough to instruct
them to do the replacement just like everyone already does.

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, Dec 14, 2012 at 12:45 PM, crick...@gmail.com wrote:

 Hello,

 I came across the following output in various filters: !P. A comment
 in the code talks about this being a silent html comment that the
 front-ends can replace if desired. However, that tag is not valid
 (x)html (I guess it used to be a valid comment).

 I'm attaching a patch that replaces !P with !--p--, so that it's
 valid html or xhtml output, in all the filters where I found !P.

 If anyone would be willing to commit this, that would be great. Or, if
 there are changes/improvements/problems with the patch, please let me
 know.

 Thanks,
 -Ben

 ___
 sword-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] filter !P patch

[Ben Morgan]

 Hi Greg,

On Fri, Dec 14, 2012 at 2:15 PM, Greg Hellings greg.helli...@gmail.comwrote:

 ...
 As to the matter of breaking front-ends, library upgrades are going to
 do that anyway. The current development head of BibleTime does not
 even compile against the current development head of SWORD because the
 API has changed - so we have to maintain a compatibility branch that
 includes changes which are going to be in the next release of SWORD
 (*whenever that might be). If this behavior changes, it will be
 another thing that we have to keep abreast of and update. I don't
 think that changing the behavior of the library and documenting that
 output has changed from !P to !--p-- will be such a hardship on
 applications, especially if it puts us in line with our documentation.

 So it really comes down to: what do we claim to produce, and does our
 library produce it? If not, then this is a bug that needs to be
 addressed by changing the library or changing our claims.

 I don't mind the idea of it changing, it's just I don't think this is an
important enough change (or perhaps not the right change).
The fact that !P is there suggests that it is meant to mean something, so
frontends really should be processing it, rather than hiding it as a
comment.
In BPBible we just change that to /pp I believe.
data.replace(!P, /pp)

I'd prefer to only have one thing to look for than two, though it wouldn't
be tragic to change it to accept both.

Look back at the conversations on ' div type=paragraph ' from September.
Troy said he was happy to remove !P if Xiphos didn't use it. Someone
needs to work out why it's in there, and whether it is really needed, then
probably adapt the filters to remove it altogether if possible (possibly
replacing it with something else).

Ben
-
 For I have no pleasure in the death of anyone,
declares the Lord God; so turn, and live.”
Ezekiel 18:32 (ESV)
___
sword-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 - epub ?

[Ben Morgan]

I've been working a little on a converter based on the BPBible code to put
e.g. the KJV on my kindle (after conversion from epub through Calibre). It
looks like it's not to difficult to do.

At the moment I've got basic Bible text showing up in Calibre, but as
Calibre uses webkit in its epub viewer, I expect lots of the CSS which I
borrowed from BPBible's CSS won't work in other epub viewers.
I still have a few features I want to put in like xrefs, notes, and extra
modules (e.g. generate a KJV + strongs + ISBE + ... in one epub file, with
some smartish linkage between the content)

On my Kindle I have the ESV student study Bible, and it works pretty well -
you can go directly to a verse through the index feature, or you use the
menu to get to a book, and the book introduction page has a link to the
chapters in the book (which is how I mostly navigate). x-refs, footnotes
and study notes are hyperlinks to sections at the end of each book. Random
access works pretty well, though not quite as well as in a paper Bible.
I'll probably use it as a model for navigation (not sure about the index
items side of it, but the rest of it)

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 Wed, Dec 5, 2012 at 6:08 AM, Joachim Ansorg 
nospam+sword-de...@joachim-ansorg.de wrote:

 Hi all,
 is there a solution to convert a sword Bible into a readable epub file?
 Would be cool to have it my preferred Sword modules on my ebook reader.

 Regards,
 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] multiple languages in modules

[Ben Morgan]

G'day Karl,

On Fri, Oct 12, 2012 at 2:11 PM, Karl Kleinpaste k...@kleinpaste.orgwrote:


  Is the foreign element passed through the engine? If so, do I need
  to file bugs with front-ends to encourage support of foreign?

 Having just looked, the string foreign does not appear in Sword's
 source tree in src/modules/filters/*.cpp.  So it's not supported right
 now after all.  I don't know how BPBible supports it; I had understood
 that BPBible uses the regular filter sets.  Does BPBible actually
 subclass the filters and extend them for foreign?

BPBible doesn't support foreign. It only looks like it does.
What BPBible does support is automatically detecting Greek and Hebrew text
and marking it to be used with the configured Greek/Hebrew fonts.

Just for the record, BPBible does subclass the regular filters quite
substantially.
It uses it for things like:
poetic text display
strongs headwords instead of numbers (if option is on)
quote colouring by speaker in ESV (if option is on)
cross-reference expansion (if option is on)

as well as some HTML+class code so CSS can be applied
Probably some of the new XHTML filter will overlap with what BPBible is
doing with some of the basic html + classes it is writing out.

God bless,
Ben.
___
sword-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] Weird Module Behavior

[Ben Morgan]

Is you module .conf file right? does it specify RawVerse4?

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, Mar 5, 2012 at 1:52 PM, Greg Hellings greg.helli...@gmail.comwrote:

 So I'm importing a basic module. It's in imp format with ThML markup
 sprinkled throughout. The module starts off with the following text
 http://pastebin.com/NFJ4sNim and I'm importing it with the command
 imp2vs KJV4W/SL_KJV4W.thml -4 -o KJV4W. However, when I try to read
 the module with a front end I get output that is represented by this
 odd behavior with Diatheke: http://pastebin.com/67z9aWZx.

 As you can see, the output of diatheke (and Xiphos and BibleTime
 behave this way as well) gives blank content for Genesis 1:1, 2, 4, 6
 while the text of 1:1 is found, badly mangled, in 1:3. The text of 1:3
 is found stripped of all markup in 1:5, and the combined text of
 verses 1-5 is found in 1:7.

 Anyone have any idea what is going on here? The output from imp2vs
 appears straightforward enough to me, it finds each entry, adds it to
 the module and moves along to the next verse. None of those empty
 verses are indicating empty or near empty verse sizes in the output.

 Uhhh... what?

 --Greg

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

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

Re: [sword-devel] Av11n and coverage

[Ben Morgan]

By having things in the .conf file, frontends can potentially show those
details in install manager. That's about the only advantage I can see in
having it in the .conf file (excluding any speed issues, which you say are
negligible).

I'd say that any precomputed module scope would have to be to chapter
granularity at its finest, and possibly only book granularity.

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, Feb 13, 2012 at 3:07 AM, scribe...@gmail.com
scr...@crosswire.orgwrote:

 Right, this opens up all kinds of discussion, as you point out.

 * if we have scope= in the .conf, what does this mean?
 Author intent?
  What does that mean?
A checksum for their actual content (I don't like this)
An entire sub- v11n definition (I don't like this)
 Simply a cache of the derived actual module content (I don't like this)

 So, I think it's safe to say that I don't like anything about having it in
 the .conf

 * if we provide a method in the engine to get the actual scope, what does
 this mean?

 Frontend are strongly advised to only display navigation for actual
 content?
  As Jonathan pointed out, if the ESV doesn't include 1 verse which is in
 the KJV v11n scheme, do we really want to limit the user from selecting
 this verse?

 Maybe only suggest using for book display?
 ... only for book and chapter display?

 Dunno. I can whip up a very optimized method to return the actual module
 scope, so I'd rather not simply cache it in the .conf file with scripts
 which are yet another requirement for repository maintainers to run.

 Troy

 Jonathan Morgan jonmmor...@gmail.com wrote:

 Hi Troy,
 
 On Sat, Feb 11, 2012 at 7:39 AM, Troy A. Griffitts
 scr...@crosswire.orgwrote:
 
  Hey guys.  I'm remember this thread from a while back am to lazy to
 go
  back and look.
 
  Please remind me why we want a .conf entry and not a call like:
 
  SWMgr library;
  SWModule *kjv = kjv = library.getModule(KJV);
  VerseKey testKey = jn.3.16;
 
  // --**--
  ListKey range = kjv.getModuleScope();
  // --**--
 
  range = testKey;
 
  if (range.Error()) cerr  testKey   is not within the range:  
  range.getRangeText()  endl;
 
 
  The only thing missing is the SWModule::getModuleScope() method which
  could easily be written to scan the module and produce an appropriate
  ListKey.
 
 
  The .conf file is an opportunity for inconsistency.  It can be a
 useful
  checksum or a pain in the butt maintenance nightmare and I'm thinking
 the
  latter.
 
 
 As I would see it, a principle difference would be author intention.
 If we
 have a conf file, then we know that (at some point) the author intended
 to
 limit the range in this way.  However, if we have a module we do not
 know
 that the author deliberately intended particular parts to be excluded,
 or
 whether they left them out by accident.  This is particularly
 problematic
 if it is just individual verses left out.  Does that mean in any
 navigation
 we have we should explicitly not display those verses?  For example,
 consider Mark 9:46 in the ESV.  It is not present in the text (though
 the
 gap is there because it was present in the KJV, and the same
 versification
 is being used), but arguably you don't want the application to tell you
 this verse isn't present in the ESV or to not allow you to select
 Mark
 9:46 or link to it or anything like that.
 
 Thoughts?
 
 Jon
 
 
  On 02/10/2012 04:35 PM, David Haslam wrote:
 
  Let's not forget that some modules are for a work in progress by the
  translators.
 
  e.g. A New Testament only module may have plenty of cross-references
 to OT
  passages, in anticipation that the translation would one day
 eventually be
  completed.
 
  And - yes - as DM noted, xrefs for modules that are scope-restricted
  should
  be linkable for parallel modules that contain the missing books,
 etc.
 
  David
 
  --
  View this message in context: http://sword-dev.350566.n4.**
 
 nabble.com/Av11n-and-coverage-**tp4265350p4376618.html
 http://sword-dev.350566.n4.nabble.com/Av11n-and-coverage-tp4265350p4376618.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
 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
 http://www.crosswire.org/mailman/listinfo/sword-devel
  Instructions to unsubscribe/change your settings at above page
 
 ___
 sword-devel mailing list: 

Re: [sword-devel] Av11n and coverage

[Ben Morgan]

On Mon, Feb 13, 2012 at 8:58 AM, DM Smith dmsm...@crosswire.org wrote:

 In the case of synodal it has 100 verses in Daniel 3. Protestant synodal
 would be 33 (IIRC). It might need to be at the verse level.

I think frontends should handle missing verses properly themselves,
regardless of the scope field (BPBible does I believe).

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)
___
sword-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] proposed patch: adding n=X marker content to footnotes and xrefs

[Ben Morgan]

I figured that the colour was just a little extra indication (they also
vary on the type of footnote e.g. insight, translation, etc.)

I think you'll find in most versions (e.g. NASB, ESV) that the type of note
is clearly distinguishable by the letter/number assigned to it. i.e.
numbers for footnotes, letters for xrefs. If the worst comes to the worst,
 hovering over them makes it really clear which it is.

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 Thu, Feb 9, 2012 at 5:05 PM, Jonathan Morgan jonmmor...@gmail.comwrote:

 Hi Karl/Ben,


 On Thu, Feb 9, 2012 at 11:32 AM, Karl Kleinpaste k...@kleinpaste.orgwrote:

 scribe...@gmail.com scr...@crosswire.org writes:
  My thought on this is similar to strongs. Don't show the numbers. They
  are left overs from the era of print-only.

 I disagree about that.  Footnote/xref markers are obligatory in a very
 large variety of publications, regardless of print or electronic form,
 exactly because of the point Brian made: Reference markers are the
 common language by which to identify their content.  If someone writes
 commentary on a document to argue against the observation made in
 footnote #37, then everyone in the world reading the same document knows
 exactly what he's talking about.  We don't expect people to count
 anonymous markers until they find #37, nor do we expect the commentary
 author to identify the footnote preceding 'word' in verse X.

 In any event, not displaying those markers represents a loss to the user
 of the author's or publisher's information.

  The exception use case is possibly our NET module which has a
  commentary accompaniment module which might refer to footnotes by
  label.  If I remember correctly.

 NETnotes contains numbered footnote content, and NETtextfree is the
 version of NET whose footnotes refer only to the numbered footnotes.
 (And my own spins of NET are similar though hugely enhanced.)

 Greg Hellings greg.helli...@gmail.com writes:
  SWModule::RenderText(bool includeNumbers=false)
  Would that do the trick?

 scribe...@gmail.com scr...@crosswire.org writes:
  Greg's idea for a flag is a good alternative to the span. I believe we
  have some other class statics in the filters for configuration. We
  could add the flag there. Thoughts?

 This would suit me fine.

 Ben Morgan benpmor...@gmail.com writes:
  Personally, I've never liked the *x/*n style and I think that in
  particular *xA/*xB looks very ugly.
  BPBible just outputs the letter/number, but colour-codes the
  note/cross-reference to distinguish between the two. This in my
  opinion gives a much cleaner look.

 The display of *n/*x is from considerably farther back in time than when
 I got involved with Sword, 6 years ago.  When I added n=X post-process,
 I simply appended X to what was already there.  I'm open to other ideas,
 neutral about the exact form that it takes.

 With one exception, that is: Color-coding becomes a progressively harder
 problem because we already offer a lot of color configuration and usage
 in Xiphos.  We have basic fg/bg (b/w), high-contrast highlight fg/bg
 (navy blue/yellow), verse# (light blue), link (default grey; I use
 orange), and current verse colors (green).  Then there is Red Words, and
 finally Xiphos complicates it all by providing color pair inversion as
 an option for normal text (to get night mode easily) and highlight.
 By this time, finding another sufficiently distinct color from all the
 other stuff happening becomes difficult.  The search for colors that
 look good enough in both black-on-white and white-on-black is hard, and
 we've recently tweaked some of our default colors expressly to deal
 better with visibility in both cases.


 Standard accessibility guidelines say that making important differences
 solely on the basis of colour is not a good idea.  However, if the colour
 differences provide a little extra that's fine.

 The funny thing with BPBible is that I'm sure the colour differences for
 notes and cross-references worked for Ben, because he wrote it.  However, I
 could not figure out why different numbers were different colours, and
 eventually read the source to figure out why.  My point (I guess) is that
 the important thing is that the differences have a meaning to your users,
 not just you (though I guess it doesn't make *that* much difference in
 the long run if the user wants to read the note whether it is a note or a
 cross-reference).

 Jon

 ___
 sword-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

Re: [sword-devel] proposed patch: adding n=X marker content to footnotes and xrefs

[Ben Morgan]

BPBible uses its own filters for notes to put the note number/letter in, so
it shouldn't affect BPBible at all.

Personally, I've never liked the *x/*n style and I think that in particular
*xA/*xB looks very ugly.
 BPBible just outputs the letter/number, but colour-codes the
note/cross-reference to distinguish between the two. This in my opinion
gives a much cleaner look.

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 Wed, Feb 8, 2012 at 2:38 PM, Karl Kleinpaste k...@kleinpaste.org wrote:

 To date, we have DM in support of n=X content in *n/*x, as well as Brian
 noting that consistency should be supported in that note numbers provide
 the common language of note reference.

 No one has suggested that such an update is a bad idea, though Troy
 wondered aloud the other night in #xiphos about choice being taken away.
 Considering that no other frontend (to my knowledge) makes any effort to
 do Xiphos-style post-processing in order to get n=X content into place,
 personally I think the question of choice is moot: All other frontends
 simply take the null choice, that is, whatever the engine gives them,
 n=X-less.

 My inclination remains to commit the patch, but I'm concerned that so
 little feedback has been seen.

 ___
 sword-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] Development, SWIG Bindings, etc...

[Ben Morgan]

On Tue, Jan 10, 2012 at 6:59 AM, Greg Hellings greg.helli...@gmail.comwrote:

 On Sat, Jan 7, 2012 at 4:59 PM, brian brianlovesje...@perffection.com
 wrote:
 To get SWIG to work on the SVN branch (This is to get it to compile,
 and
  it allows it to work but I still haven't gone over all the warnings which
  seem mostly due to operator overloading) , the problem lies in that
  SWBuf::append(wchar_t) which is new is not yet fully supported by SWIG.
 We
  can remove its usage by editing swbuf.i and adding at line 29:
 
  %ignore sword::SWBuf::append(wchar_t);

 I added this and confirmed it allows the library to compile. The fix
 is now in SVN. Thanks for locating it.

 I'm not sure how useful adding support for wchar_t directly to the
 bindings is, since Python already has a dead-simple method for
 combining strings and converting encodings. It might not even be
 desired by the people who use the bindings. Until I hear from those
 people on this matter, I would be wary of including that extra
 functionality.


Yep, that patch looks fine and I don't think we could even pass in a
wchar_t easily from python. SWBuf isn't really that necessary to work with
that much anyway, and when you do, UTF-8 is usually used (or cp1252,
depending on the module).

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)
___
sword-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 support in Xiphos?

[Ben Morgan]

If I remember from last time we went through this, Xiphos may indent a
whole block of poetry, but the individual line indentation on every second
line (or sometimes second and third lines) which really indicates the
poetical structure, like you see in BPBible, is missing. I think this is an
example of why a checklist of features is not as useful as could be hoped
for.

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 Wed, Dec 28, 2011 at 7:54 PM, David Haslam dfh...@googlemail.com wrote:

 Therefore, the complete absence of poetry indents in Xiphos for my setup
 must
 be due to deficiencies in gtkhtml3 in Xiphos 3.1.4 for Windows.

 I look forward to seeing the improvement when 3.1.5 gets released.

 David

 --
 View this message in context:
 http://sword-dev.350566.n4.nabble.com/Poetry-support-in-Xiphos-tp4206018p4239372.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] Poetry support in Xiphos?

[Ben Morgan]

On Wed, Dec 28, 2011 at 10:45 PM, Peter von Kaehne ref...@gmx.net wrote:


  Von: Ben Morgan benpmor...@gmail.com
  I think this is
  an
  example of why a checklist of features is not as useful as could be hoped
  for.

 I think this is a bit off tangent and also not correct. The checklist of
 featurese we maintain in the wiki is editable - if a feature needs more
 detail - e.g. 1 level vs 2 level indentation this can be easily added.

 Yes, it is editable. But I also think that is off the point. Personally, I
don't edit it because I don't see much point.

Basically, any checklist like this is interesting in one sense, but doesn't
give a big picture. Some programs can have paid special attention to
features so that they are useful and discoverable, others may just have
shoe-horned a feature in and it is hard to use. Last time I looked, some of
the unique features of BPBible could technically be claimed by other
programs depending on exactly how I phrased it - but only BPBible did the
feature in a really useful way (I'm just choosing BPBible because it's what
I've worked on, though for various reasons I haven't touched it for a while
- no doubt other programs have similar things). Also last time I looked the
checklist was much too long and didn't always concentrate on what I
consider the important things.

In the open source world (and it's not just open source), sometimes it just
ends up a battle for how many checkboxes you can claim you ticked. I don't
think that is useful to the user quite a lot of the time - they care about
the general experience, and if the program doesn't provide a given
feature/option/etc., but does provide a good experience, they may not even
know/care, and that's fine.

Mind you, I understand that opinions differ and some people like the
checklist, so I'm not against it per se for those people - I won't be
updating it for BPBible 0.5 though anytime soon.

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)
___
sword-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] Marking pre-verse titles?

[Ben Morgan]

On Fri, Oct 21, 2011 at 1:40 AM, David Haslam dfh...@googlemail.com wrote:

 Evidently some folk could not read the original message, part of which
 read:


This seems to happen because fixed width text doesn't get through Nabble
into the email list (it's been observable with your emails for a while). Is
there a reason you don't use it as an email list rather than using Nabble?

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)
___
sword-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] Per Project news: - was Re: CrossWire news

[Ben Morgan]

Vary the following:
http://www.crosswire.org/pages/crossnewstest.jsp?project='class=2percat=3maxRes=6

org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544569. Dynamic SQL
Error SQL error code = -104 Unexpected end of command - line 1, column 379

Other than that (and a number of variations on it), it seems to work (i.e.
for validly constructed URLs it works).

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Feb 15, 2011 at 12:23 AM, Peter von Kaehne ref...@gmx.net wrote:

 I have now in a test file added the code to have a project parametre.

 You can see it here in action:


 http://www.crosswire.org/pages/crossnewstest.jsp?project=8class=2percat=3maxRes=6

 Please test it and if you manage to crash it, tell me what i did wrong. The
 underlying sql statement is pasted to the bottom of the page underneath.

 The idea is that you can combine news from your particular project and news
 from e.g the module factory, which I guess is nice to advertise your
 particular frontend and the modules you can display (which obviously won't
 work if your frontend has display or logic deficiencies)

 There are a few half or totally abandoned projects strewn across the site
 and i will add it there to show how it would look for them. Others can then
 see if they want to make use of the facility.

 I will also in the next few days  try and make the production of tailored
 rss feeds similarly straight forward and then throw a bunch of such feeds in
 a well accessible place - particularly also for externally hosted projects
 this might be of use.

 Peter




 --
 GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
 gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

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

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

Re: [sword-devel] Module Display Names

[Ben Morgan]

There is the Description field for long names and Abbreviation for an
abbreviated form (an alternative to using the module name in theory). Not
sure what frontends if any support Abbreviation though.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Thu, Jan 20, 2011 at 8:18 AM, Greg Hellings greg.helli...@gmail.comwrote:

 This is just a query/brain dump as an exposition on an issue which I
 believe came up on bt-devel (maybe it was here).

 The title of a work, as displayed by both Xiphos and BibleTime
 (still the only two SWORD applications I've used, so forgive me if I
 have left out others in my brain dump as I don't know their behaviors)
 in their list of works for download or open, is the title, verbatim,
 as it appears within the brackets on the first line of a module's
 .conf file.  As we know from the other thread, this title is very
 limited.  To quote the wiki page on conf files, It can only contain
 A-Z, a-z, 0-9 and _.

 Now this is a very strict limitation and, to me, rather limits the
 usefulness of the title to internal representations within an
 application or engine.  For some modules, there is a natural choice
 for this field which is relatively unambiguous: ESV, KJV, YLT, NASB,
 Webster.  For others, there might be a slightly more abiguous choice:
 does Luther mean his commentaries, his collected works or his
 German-language translation?

 But for my own situation, there are possibly some very ambiguous
 titles that I am stuck with.  For instance, I have a few different
 works which are commentaries on the same book.  The titles might all
 be The Book of John and just be by different authors.  In the
 current status I am somewhat stuck with calling them things like
 The_Book_of_John_AuthorA and The_Book_of_John_AuthorB.  As I said
 above, these represent great internal/developer names for these two
 works, but they aren't so user friendly.  Is there a better recourse
 for me, where I can specify a different conf value?  Something along
 the lines of
 [INTERNAL_NAME]
 DisplayName=Not so restrictive on characterset

 This would greatly help me, as we have both names already in place for
 the modules I'm working with so we can have manageable conf files
 names.  Of course, then I'm violating the [NAME] = name.conf directive
 of the conf files.  A real example from the set is
 SL_CM_GAL_NIG.conf:
 [The Epistle to the Galatians]
 Well, I sure don't want the user to need to figure out what
 SL_CM_GAL_NIG stands for, but according to the official standards
 The Epistle to the Galatians is not a valid conf file name.  But
 currently The Epistle to the Galatians is what both BibleTime and
 Xiphos display, despite the invalidity of the conf file.

 Is there a conf file entry akin to DisplayName that we already have
 and I'm just missing it? Or can we get one, even if it is optional and
 defaults to the value of [XYZ] in its absence?

 Anyway, that is my brain dump for the afternoon.

 --Greg

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

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

Re: [sword-devel] Module Display Names

[Ben Morgan]

What I've used in BPBible in a few places is Name - Description (i.e. ESV -
English Standard Version). The abbreviation at the start (hopefully) means
that if the rest is cut of it shouldn't matter too much.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Thu, Jan 20, 2011 at 9:38 AM, Karl Kleinpaste k...@kleinpaste.orgwrote:

 Actually, there's a module with an even longer Description.  Practice
 has:

 The Practice of the Presence of God: The Best Rule of Holy Life by Brother
 Lawrence (Nicholas Herman, 1605-1691)

 Gosh, that's annoyingly long.

 Greg Hellings greg.helli...@gmail.com writes:
  One of my modules is [CONNOT] which is a decent abbreviation
  and it fits in the limits of SWORD.  Currently I have the About field
  set toConsultant Notes and the About field set to pConsultant
  Notes for Translators./p.

 About and About?  I think you meant Description and About.

 Contents of About aren't supposed to contain HTML, notwithstanding that
 it happens to work.  That content is formally RTF.  You'll see a lot of
 \par and so forth in *.conf About fields.

  Perhaps you can shed some light on why you use the
  value of the name instead of the Description in your widget?

 Because that's the way it's been since The Dawn Of Net.Time, which was
 way back when Terry first did it. :-D

 Seriously, no one's ever asked about it before.

 It could certainly be reasonable to update module selection widgets to
 use Description instead of the [BracketedName]; but I wonder about
 possible confusion because [BracketedName] is guaranteed to be unique
 but Description is not, and considering the selection of Description
 used at e.g. bible.org...

   Free version of NET Bible Footnotes with limited notes
   Free version of New English Translation with limited notes
   NET Bible Footnotes presented in the form of a commentary.
   New English Translation text only with footnote markers
New English Translation with over 60,000 translator, study and text
 critical notes

 ...with so much similarity from one to another, I worry that the user
 won't get the connection, and especially that he won't grasp the
 difference when tabs have [BracketedNames] (for minimal length purposes)
 that would then be seen pretty much nowhere else.  Also, at the moment,
 I've got DM's (old) beta NASB and Troy's (new) beta NASBnew...

   New American Standard Bible
   New American Standard Bible (NEW)

 ...whose minor change is almost unnoticeable and could lose the (NEW)
 the next time Troy puts out an update.

 I'm open to opinion about the problem, of course.

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

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

Re: [sword-devel] Module Display Names

[Ben Morgan]

On Thu, Jan 20, 2011 at 11:31 AM, Greg Hellings greg.helli...@gmail.comwrote:

 On Wed, Jan 19, 2011 at 4:41 PM, Ben Morgan benpmor...@gmail.com wrote:
  What I've used in BPBible in a few places is Name - Description (i.e. ESV
 -
  English Standard Version). The abbreviation at the start (hopefully)
 means
  that if the rest is cut of it shouldn't matter too much.

 I think this is a good pattern, though I might have switched their
 order myself, or only given the abbreviation if the two Descriptions
 are identical.  I was thinking of a precedence like:
 1) Description, if present
 1.1) If Description is not unique, combine with one of the below
 2) Abbreviation, otherwise
 3) Name, otherwise

 I know that Description is listed as a Required element, but if it
 were absent, having fallbacks is a good idea.

I think putting abbreviation first always is nice because it is easier to
scan for (i.e. ESV is much more recognizable than English Standard
Version).  Putting the Abbreviation on the front makes it possible to scan
through a list for it, whereas if the description was first and the
abbreviation at the end it would be much more difficult.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Module Display Names

[Ben Morgan]

On Thu, Jan 20, 2011 at 1:42 PM, Greg Hellings greg.helli...@gmail.comwrote:


 Since we have an abbreviation field already designated for the conf,
 perhaps we should make it required?  Or perhaps applications could
 use, first, the Abbreviation field if present and only fall back to
 the module name if an Abbreviation is lacking? That way the module
 creator of GerThis or GerThat could display THIS instead of GerThis if
 they wanted in well-behaved applications?

 Otherwise, what is the purpose of the Abbreviation field?

It's probably best not to make it required (most existing modules won't have
it), but trying using the Abbreviation first then the Name as a replacement
if necessary was the use case it was specifically put in for.

When this last came up was when it was decided to put the Abbreviation field
in the .conf files, but I don't know that
a) it was done in any of the conf files
b) any frontend authors added support for it

If a) happens, b) is likely to follow.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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 links

[Ben Morgan]

On Wed, Jan 19, 2011 at 10:13 AM, DM Smith dmsm...@crosswire.org wrote:


 On Jan 18, 2011, at 6:08 PM, Peter von Kaehne wrote:

  On 18/01/11 21:24, Peter von Kaehne wrote:
  Do they work?
 No. There is no support in the engine.

There is support in the OSIS html href filters (look under reference in
https://crosswire.org/svn/sword/trunk/src/modules/filters/osishtmlhref.cpp)
Looks like the following would work, where Work is the genbook name, and key
is the key (not sure about how well it works with encoding).
reference osisRef=Work:KeyA link/reference

There is a special Bible: work target; otherwise it generates a
sword://Work/Key link which is handled by Xiphos and BPBible at least I
think. I don't think self as a work id is supported as such.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] [jsword-devel] Missing short bible book names for most languages

[Ben Morgan]

There are two types of abbreviations for booknames:
1) abbreviations that are recognized when parsing user input (i.e. we can
parse Isa 3:5).
2) abbreviations of a bookname that are shown to the user when an
abbreviated form is used (i.e. for Isaiah 3:5, we show Isa 3:5).

Peter is talking about 1), but Martin is talking about 2).

BPBible has some of the abbreviations you were looking for that aren't in
jsword: fr, hu, and pt
as well as hi (hindi) and ne (nepali)
http://code.google.com/p/bpbible/source/browse/#svn%2Ftrunk%2Flocales%2Flocales.d

Incidentally, I disagree with David that we should remain faithful to the
abbreviated booknames used by the translators of each translation -
consistency in the application is I believe more important than being
perfectly faithful to the printed text. I don't mind the idea of having
options for switching between different booknames/abbreviated booknames in
one locale, though.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Jan 11, 2011 at 7:28 PM, Peter von Kaehne ref...@gmx.net wrote:

 On 10/01/11 23:37, Martin Denham wrote:

  I did wonder if there might be an alternative source of short names,
  possibly from another sword project like Xiphos, that we could use to
  insert the correct short names in our properties files.

 I think the problem is - the locale abbreviations are only meant to be
 there if the abbreviations are non-obvious, i.e. not deductable for the
 software.

 First Corinthians
 1Cor

 but not:

 Isaiah

 Isa

 So, even those languages you listed as will not by necessity have the
 proper short names. If they have, this is - strictly - redundant for
 the purpose of the locale files (at least in their current incarnation).

 I copy this into sword-devel as there are more readers there.

 Peter


 ___
 jsword-devel mailing list
 jsword-de...@crosswire.org
 http://www.crosswire.org/mailman/listinfo/jsword-devel

___
sword-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] [jsword-devel] Missing short bible book names for most languages

[Ben Morgan]

On Tue, Jan 11, 2011 at 10:41 PM, DM Smith dmsm...@crosswire.org wrote:


 On Jan 11, 2011, at 6:06 AM, Ben Morgan wrote:

 BPBible has some of the abbreviations you were looking for that aren't in
 jsword: fr, hu, and pt
 as well as hi (hindi) and ne (nepali)

 http://code.google.com/p/bpbible/source/browse/#svn%2Ftrunk%2Flocales%2Flocales.dhttp://code.google.com/p/bpbible/source/browse/#svn/trunk/locales/locales.d


 Thanks for the info! We'll use it to improve JSword.

 I'm curious how/why this differs from SWORD's locales.d? Any thought to
 submitting the differences to the SWORD project?

 It's mostly got extras because that's what we had submitted. Most of the
locales we have are the same; in a couple of cases BPBible has added some
extra BPBible specific niceties (0-9 in the other language for example). I
haven't really got time to submit them at the moment; I'm quite happy for
someone to put these in the SWORD project (that said, it is easier to
control them if they are just in BPBible...)

We also have a BPBible specific english locale that attempts to display
better booknames (i.e. no roman numerals and reduce the 3 word book names)

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Markup Options

[Ben Morgan]

Hi Greg,

On Thu, Dec 2, 2010 at 3:32 PM, Greg Hellings greg.helli...@gmail.comwrote:

 User-specified stylesheets would not help me much at all.  Since each
 module has its own look and feel that it needs to maintain.  Yes,
 there is a certain uniformity to them, since they largely all come
 through the same publisher, but there are differences - differences it
 would be ridiculous to ask the user to try and specify out of the blue
 (our target audience with these modules are people who are largely
 without technology at all except for when they sit in front of the
 Bible app we provide them with).  Instead, each module came with its
 own layout and styling and should maintain it.

I wasn't suggesting that each user maintain a stylesheet, but if the
application lets users supply their own, such a stylesheet could be created
and distributed (it could even potentially target individual modules).


 Your print analogy is perfect here, but I think you draw the backwards
 conclusion from it.  Every print Bible has its own style, layout,
 formatting, etc.  In the same way, every module should have its own
 styling, layout and formatting.  When a publisher creates a 4-in-1 or
 8-in-1 print, then they hold the prerogative to determine a basic
 formatting for all of them.  Likewise, every SWORD module should have
 its own styling unless the user is viewing it in parallel with other
 modules.  By forcing the styling to be placed inline, you are
 surrendering that ability.  Now, I just place my styling inline and it
 gets foisted on the parallel display and individual displays alike.
 It looks great in the individual display but messes up the parallel
 display.  With external stylesheets you avoid that by simply opting to
 exclude it from parallel displays and inserting it during solo
 viewing.

You come at this from a different viewpoint. My viewpoint is that the texts
in a piece of Bible software should be as consistent as possible. The fact
one publisher likes a particular font, or has verse numbers 1pt smaller, or
like dull beige tones on the verse number or footnotes is to me largely
irrelevant. Print bibles can define their own styling because they stand
entirely alone - completely different books. Within one user interface (e.g.
BPBible), switching between Bibles, I want to see consistency. I suspect we
aren't going to agree on this one though...

As to you using inline styling, I don't think you should be doing that (not
necessarily you in particular, but modules we generally have for
distribution). I'd agree a per-module external stylesheet would be
preferable to that.

  I'm all for giving the application and user more control; I'm just not
  convinced we should give module creators this level of control. I fear
  per-module stylesheets would be somewhat brittle, liable to be targeted
 at a
  particular frontend (which is what Jon was saying above), and likely to
  reduce the consistency in the interface. That said, I can see there could
 be
  a few cases where it might be necessary - say if a publisher insisted
 that
  their Bible look the way their print one does - but I would prefer
  consistency to each Bible looking like their print counterpart.

 This is exactly the scenario I am in.  The publisher is insisting that
 these modules look the same way in BibleTime and Xiphos as they do in
 Logos.  So I force the style inline and take away control of the
 display from both the application and user.  What I am offering is a
 way to make my job easier (I only have to produce an external
 stylesheet which can easily be adapted to an OSIS source later when
 these modules go that direction) AND it returns control back to the
 user and application by allowing them to opt-out of the stylesheet
 when it is inappropriate - the same way web browsers opt out of screen
 stylesheets when printing.

I'd like to say this is a special case, and I'd much prefer if it stayed
that way. I guess some of this is because I like to have control over the
way things are in BPBible (which is also why I mostly would prefer people to
use OSIS if possible - it is easier to work for a lot of things than ThML).

By the way, what is the types of styling you are doing (color, font,
layout)?

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Markup Options

[Ben Morgan]

Hi Greg,

On Thu, Dec 2, 2010 at 1:51 AM, Greg Hellings greg.helli...@gmail.comwrote:

 I believe the phrase would mean the SWORD library would produce a well
 defined set of HTML elements with classes attached to help preserve
 the semantic meaning.  It would then be up to the consumer of that
 HTML - the application - to provide its own CSS.  Adding extra CSS
 classes as per an application's specific desires ought to be as easy
 as extending the filter and just adding a few extra lines of code for
 each particular case.  Extraneous CSS classes can readily be ignored
 simply by not having a corresponding definition in the app's CSS.

That's well and good, and would cover a good chunk of customizability needs
- but it only works up to the limit of CSS.


 BPBible does lots of customization, BibleTime does as well, and
 certainly other apps do customize to some extent.  If the filters were
 good and easily extensible (and any of the XML processing technologies
 would work in that regard), BPBible's customizations could either be
 readily incorporated to the engine to benefit others who desire them
 or maintained in BPBible directly without having to throw out the base
 filters.  And, of course, BPBible would continue to maintain its own
 stylesheets.

BPBible's customizations are somewhat complicated and rely heavily on other
parts of the SWORD API or other data (e.g. showing two xrefs in an xref
block and putting the rest in a separate link, producing user friendly xref
text, colorcoding quotes in the ESV by speaker (experimental in 0.5),
replacing strongs numbers with greek lemma/transliterated). This is best
suited to the current way things work I feel. BPBible's filters inherit from
SWORD's ones, so the base filters are not thrown out as such.


  2. Some of the application specific styles and user choices may conflict
  with the module styles.  For example, I know Bibletime has themes, which
 can
  change colour of foreground text, background, ...  I have thought about
  doing a similar thing for BPBible.  However, this isn't going to work in
  cases like: our poor user has a dark background, and the module developer
  has decided to mark a particular text feature in a dark purple which is
  nearly illegible.
 ...
 That way the application provides the default appearances, the module
 can provide overrides to the default if it desires, and the user can
 provide overrides which take the highest priority.  Yes, if a module
 specifies Black background and the user has said they want all text to
 be in dark grey, that would be difficult to read.  But this can happen
 easily on the web already and somehow we are all able to manage.
 Since we are using identical technology, why can't we use its full
 power?

I agree the mechanism is simple enough; the ramifications are potentially
not. Personally, I would mostly prefer that modules cannot provide their own
stylesheets. On the web, every site has its own style; in print, each Bible
has its own style. But when different Bibles are gathered together (say a
print 4-version Bible) they all use the same formatting. Just so with our
software - a consistent look throughout different Bibles is important, and
having each module specifying what font it wants and size and colour has too
much potential to lose consistency throughout the application.

Your particular problem, Greg, where you wanted to duplicate the look and
feel for modules as compared to existing systems, would be better
addressed I feel by allowing the user to specify their own stylesheet,
rather than per-module styling. This would still maintain a consistent look
and feel across all modules.


  3. As well as the single verse search results Karl mentions, the parallel
  case comes to mind.  If I have multiple books using different style
 sheets,
  how do I manage that?  Do the parallel Bibles end up in different and
  clashing styles?  In BPBible I think we even generate different HTML for
  these different places, so there's not even a guarantee that these styles
  will apply cleanly and work.  However, if any modules are created that
 rely
  on these custom styles to look OK, then we will need to have some way of
  making them work in all these different contexts.

Adding support for external stylesheets actually gives the application
 and user MORE control, not less, and still allows the module creator a
 sane way of specifying styles without having to resort to inserting
 their styles as style attributes on every single ThML element they
 want stylized (and would also allow the creation of OSIS modules where
 the style is influenced by the module creator instead of only by the
 engine and user agent, provided the applications can agree on
 well-defined mapping between OSIS and HTML).

I'm all for giving the application and user more control; I'm just not
convinced we should give module creators this level of control. I fear
per-module stylesheets would be somewhat brittle, liable to be targeted at 

Re: [sword-devel] XSLT vs. C++

[Ben Morgan]

Hi Greg,

On Thu, Dec 2, 2010 at 2:19 AM, Greg Hellings greg.helli...@gmail.comwrote:

 On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan jonmmor...@gmail.com
 wrote:
  Speaking as a BPBible developer, I would tend to prefer C++ filters to
  XSLT.  Here are some reasons why:
  1. It works now (well, OK, it doesn't always work as well as one might
 like,
  but it does work).

 It works for our historical collection of modules, but the current
 implementations of some of the filters are rigid and very difficult to
 update or modify.  But yes, it more or less works now.

I agree it can be very fiddly and fragile - that's mostly the filters like
the headings filters which are run before render; the OSISHtmlHref filters
are simple enough to work with. Extending it in python once it is set up is
very easy as well (basically defining a start_tag and end_tag handler -
for our handling of poetic lines, for example, see
http://code.google.com/p/bpbible/source/browse/branches/webconnect/backend/osisparser.py#475
)


  2. It is (fairly) readily able to be customised by application developers
  using the magic of inheritance.  BPBible at least takes advantage of
 this,
  and 0.4.7 contained about 800 lines of Python in our filter code.  For
 0.5
  the OSIS filter has doubled in size.  By contrast, if we were to maintain
 an
  app-specific XSLT file, we would probably need to duplicate the whole
 file
  and then make changes to it, and any changes made to the base XSLT file
  would have to be manually merged in.  Bye-bye to the idea of having only
 one
  lot of library source to maintain.

 XSLT is easily extensible.  SAX is easily extensible.

Basically what is used already is a SAX-like model, just implemented by
Sword. Customizability is just the same as you describe.

I do not believe XSLT is a good option; for a start, it requires (AFAIK)
valid XML fragments, which we do not have within a verse in much of existing
content (or even at all necessarily). JSword I believe has fallbacks to
extract the text if not valid xml, but I would far prefer not to use such
hacks; SWORD can handle this quite well (as probably SAX could if
non-validating). Also, due to the structure of OSIS with multiple
hierarchies, however you process it it will be complicated and this loses
much of the benefits of XSLT. (Disclaimer - never used XSLT)

Also, on a personal level, due to having never used XSLT, I feel comfortable
using Python/C++ whereas XSLT is scary.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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/Commentary headings

[Ben Morgan]

Maybe swapping the order of chapter and verse around may help? The code I
remember does some special handling of zeroes, but I can't check it at the
moment.
e.g.
   vkey-Verse(0);
   vkey-Chapter(0);
to
   vkey-Chapter(0);
   vkey-Verse(0);

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Thu, Dec 2, 2010 at 9:48 AM, Greg Hellings greg.helli...@gmail.comwrote:

 One of the commentaries I have has a book header (in this instance it
 is for 1 Peter) which is held in the module in the key 1 Peter 0:0.
 Behavior concerning that introduction varies with different
 applications.

 1) example/cmdline/lookup 'A Commentary on I Peter' '1 Peter 0:0'
 This works perfectly.
 2) diatheke -b 'A Commentary on I Peter' -k 1pet.0.0
 This autonormalizes to James 4:17 or something similar. 1pet.1.0
 autonormalizes to James 5:22 or thereabouts.  Diatheke seems to lack a
 call to AutoNormalize(0), so this behavior - while suboptimal IMHO -
 is expected.  Perhaps one of the diatheke options disables
 autonormalizing and turns on Headings, not sure.
 3) Bibletime, opening the module to 1 Peter 1:1
 This displays the heading plus the contents of the verse 1:1, and
 autoscrolls the display to where the 1:1 text begins.  This is
 Bibletime's expected behavior and is good.
 4) Xiphos, opening the module to 1 Peter 1:1
 This displays the text of 1 Peter 1:1 and is good.  I then right click
 on the commentary panel and select Dispaly Book Heading.  This brings
 up a blank panel.  The same with Display Chapter Heading.  I was
 hashing this over on IRC before Karl had to leave and we were
 comparing Bibletime and Xiphos' code.  The relevant portion of
 Bibletime's code appears to be here:

 http://gitorious.org/bibletime/bibletime/blobs/master/src/backend/rendering/centrydisplay.cpp#line42
 .
  It doesn't seem terribly different from Xiphos' code which begins
 around line 114 of src/main/sword.cc in terms of how it actually uses
 the engine.

 Xiphos' code reads thus at that point:

VerseKey *vkey;
SWMgr *mgr = backend-get_mgr();

backend-display_mod = mgr-Modules[mod_name];
vkey = (VerseKey*)(SWKey*)(*backend-display_mod);
vkey-Headings(1);
vkey-AutoNormalize(0);
vkey-Verse(0);
vkey-Chapter(0);
backend-display_mod-Display();

 which doesn't seem to work properly.  When I change that code to this

   VerseKey *vkey;
SWMgr *mgr = backend-get_mgr();

backend-display_mod = mgr-Modules[mod_name];
vkey = (VerseKey*)(SWKey*)(*backend-display_mod);
vkey-Headings(1);
vkey-AutoNormalize(0);
SWBuf ll = SWBuf(vkey-getOSISBookName());
ll +=  0:0;
vkey-setText(ll.c_str());
backend-display_mod-Display();

 it behaves as expected.  I discovered this workaround when I was
 working on mod2osis and just tried it on Xiphos on a whim.

 What might be going wrong here when Xiphos seems to be doing what I
 would understand should display the heading?

 --Greg

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

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

Re: [sword-devel] SWIG Bindings (Was: Re: What is a Sword module?)

[Ben Morgan]

Hi Greg,

On Sat, Nov 6, 2010 at 12:24 PM, Greg Hellings greg.helli...@gmail.comwrote:

 But the nature of multimap is different - and I'm confused as to how
 it is used at all.  What you are showing above I would call a
 multi-dimensional associative array/dictionary.  I make them all the
 time in Python and PHP.  But a multimap is defined as a
 generalization of a map or associative array abstract data type in
 which more than one value may be associated with and returned for a
 given key.  I don't think we are actually using multimap
 functionality but rather just a multidimensional array.

If I remember rightly, a multimap is just like a dictionary in python that
can have multiple values for a given key (conceptually I guess it is like a
dictionary of lists of something).
The getEntryAttributes stuff is not a multimap - just nested maps.

Multimaps are seen in SWConfig, where it is possible to have multiple
entries for a given key (e.g. in modules, multiple GlobalOptionFilter's).

This allows you to iterate through them like this:
(annoyingly long fragment adapted from C++, untouched for a year
probably...)

# look first in the map
sourcesSection = installConf.getSections().find(Sword.SWBuf(Sources)) if
sourcesSection != installConf.getSections().end(): ftp_source =
Sword.SWBuf(FTPSource) ss = sourcesSection.value()[1]
# this is where we start iterating over the multimap sourceBegin =
ss.lower_bound(ftp_source) sourceEnd = ss.upper_bound(ftp_source) while
sourceBegin != sourceEnd: install_source = InstallSource(FTP,
sourceBegin.value()[1].c_str()) print privatePath + / +
install_source.source
sourceBegin += 1



 SWIG gives us multimap support in Python for free and I found a
 version we include with the library to get Perl working.  However,
 SWIG does not have an implementation of stl::multimap for us, so we
 either need to write one, or refactor our multimap usage to be nested
 associative arrays.

 Most people wouldn't need to touch multimap - I think it's only used  in
SWConfig, where mostly you can just use get and set on the SWConfig if
needed (only if you need to iterate over multiple key values). So I don't
think this should worry us too much. To some extent, if an area of the API
isn't supported for a given language, there's no point in supporting it
until someone needs it.


 
  But this interface doesn't translate well to other languages.  I have
  had to implement a different interface for my custom language binding
  for Java-jni (used by SWORD C++ on Android) and CORBA (used by SWORDWeb).
 
  The binding interface I usually implement is described in simple IDL
  here and is a fairly concise set of methods that give access to most all
  of functionality of the engine:
 
  http://crosswire.org/svn/sword/trunk/bindings/corba/swordorb.idl
 
  You'll notice the method for obtaining entry attributes:
 
  StringList SWModule.getEntryAttribute(in string level1, in string
  level2, in string level3, in boolean filtered);
 
  This less exotic interface maps much easier to other languages, but
  implies you know what attribute you'd like to obtain (discovery by
  iteration is not supported, but really, what frontend does that anyway?)

That might be a better way of doing it, and would be very easy to add.
In BPBible we don't exactly iterate over it, but we do get values at
different levels and check whether subvalues exist (look at:
http://code.google.com/p/bpbible/source/browse/trunk/backend/book.py#415
). This we could replace with a simpler interface in getEntryAttribute
(which could return None if key not found).

I can imagine a situation where someone wanted to do iteration, but we don't
seem to do that in BPBible at the moment...


  So, in summary, maybe we should add this to swmodule.i

 That is one possibility.  However, I think there are other places
 within the bindings that should be addressed first.  As you saw
 yourself, SWBuf plays great in C++ but SWIG doesn't seem to pick up
 any ability to auto-cast it back to a Python string/unicode object.
 At the very least, that functionality should be as easy as an explicit
 cast of unicode(myswbuf) and better yet it would be transparent.

I tried doing that with a simple SWIG typemap, but it didn't play well with
the STL stuff. Almost everything worked as expected, but when a SWBuf was a
key in a std::map for example, it didn't transparently convert that, and
there was no way to create SWBuf's then.
Occasionally it is useful not to transparently convert them but to look at
the length or something like that for efficiency (not very common I
think...)

Depending on how smart you want to try to make it, SWBuf's have to end up as
byte strings as well quite a bit of the time. There's no universal way from
the API to tell whether something is utf-8 or cp1252. You could do it for a
number of key interfaces, though - RenderText, getKeyText, get config entry
from module.

Ideally, someone would write extra Python code so that the SWIG
 bindings 

Re: [sword-devel] 1.6.2 final call

[Ben Morgan]

Hi Troy,

I sent you a while ago this patch, attached (to patc...@crosswire).

This was what I said about it:

 Just looking back over my checked out sword repository, I found this
 versekey patch.


 This I seem to remember was to fix the problem where having f's in
 booknames would cause the f and ff suffix code to run, making a bounded
 versekey. I can't remember whether there were any problems with this patch,
 but I believe I've been running with it on my local computer for ages and
 haven't noticed any problems. (Sorry I haven't got time to look into this
 more closely - but IIRC, what this patch does is quite important to include
 as otherwise Revelation of John 1:1 is parsed to Revelation of John 1:1-2,
 which causes problems in BPBible at least)


God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Fri, Oct 15, 2010 at 3:41 AM, Troy A. Griffitts scr...@crosswire.orgwrote:

 We've been tying up loose ends and are about ready to release 1.6.2.

 I believe I have taken care of all submissions sent to me personally.

 Please have a look and if you know of something still outstanding,
 please shout out.  Nothing personal, it was probably just buried deeper
 than I dug.

 If you have outstanding work you are planning to commit for 1.6.2,
 please also say something.

 Hope everyone is well,

 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



versekey.diff
Description: Binary data
___
sword-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 - phil 4:4

[Ben Morgan]

Quickly checking in my KJV 1611 edition and my KJV 1769 edition shows that
alway is correct. It's an archaic form of always.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Oct 5, 2010 at 5:34 PM, Nic Carter niccar...@mac.com wrote:


 Heya team.  I'm wondering where we get our KJV source from?  A user
 recently picked up the below typo:


 Begin forwarded message:

 *
 *
 In the KJV version, Phil 4:4 has the word 'always' misspelled.

 4Rejoice in the Lord alway: *and *again I say, Rejoice.


 testing myself seems to confirm  also our online version:
 http://www.crosswire.org/study/passagestudy.jsp?key=phil+4%3A4mod=KJV


 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

Re: [sword-devel] Hyphens in book names

[Ben Morgan]

On Thu, Sep 30, 2010 at 8:42 AM, Troy A. Griffitts scr...@crosswire.orgwrote:

 :)

 In principle I agree with Chris, but I can't decide what people do with
 names.  One of my colleagues in this country (England) is named
 Instone-Brewer (sorry to use you as an example David).

 We've been wanting to internationalize the numerals and action symbols
 in our verse parser for a while now (and the display format, e.g., %BOOK
 %CH:%VS, %VS   or   %BOOK %CH,%VS.%VS ).  It's not a huge task but it's
 on the list with everything else.  It sounds like the BPBible guys
 already have a good start at this.  I'd love to see the patch or if one
 of you guys would like to head up this item, please speak up.

What we do in BPBible is:
1) for reading user input, we run a few regexes over it. One of them removes
dashes in between alphabetical characters. This will break the case of
Acts-Romans, but will not break say Acts - Romans (because of the spaces),
or Romans 3:1-2 (as it is numbers not letters).
(out of interest, the others regexes are:
1) replace a single 'v' in between numbers with a ':'
This allows references like Mat 5v6.
2) replace spaces between numbers with a :
This allows Mat 5 6, which would otherwise be interpreted as Matt 56
3) remove spaces between a ':' and a number
Otherwise Matt 5: 6 is interpreted as Matt 56)

We also go through and replace 0-9 in the input language with 0-9 in
english.

When outputting text to the user, we glue it together using an algorithm
intended to give the best range text (so that we get Genesis 1:6-9 not
Genesis 1:6-Genesis 1:9, also handles outputting say Jude 2-8 instead of
Jude 1:2-Jude 1:8). The bookname in english is run through the translate
twice; once to localize it and the next time to turn the localized variety
into localized-with-dashes. A regexp turns 0-9 in english into 0-9 in the
target language.

In BPBible text displayed to user/inputted by user is carefully separated
from internal, english text. Internal text doesn't need all this special
processing.

What would be nice I think would be to be able to glue all our locales
together into one big locale (with an emphasis e.g. on English, when in
English, or on German when in German) so that if the user enters Nepali
references when in English they still work (it would usually work vice-versa
- entering English in Nepali should work)

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] CMake

[Ben Morgan]

Ok, that seems to work with BPBible now. However, it also seems to hard code
the path to libsword's dylib to be in the build directory, which could be a
problem (though I don't know too much about this linking stuff on MacOSX):

otool -L _Sword.so

_Sword.so (architecture i386):
/Users/benm/builds/sword/trunk/build/libsword.1.6.1.dylib (compatibility
version 1.6.1, current version 0.0.0)
 /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.0)
_Sword.so (architecture ppc7400):
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.0)


God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)



On Fri, Oct 1, 2010 at 6:32 AM, Greg Hellings greg.helli...@gmail.comwrote:

 Robert just pointed out to me some issues with building the CMake
 bindings which may have been affecting those of you who reported
 errors to me over the past few weeks.  The fix is now at the top of
 SVN head, if those who have had problems would like to update to the
 latest HEAD and try building again.

 I know an error had been reported with the Python bindings as well as
 some trouble building on OS X.  I believe this fix may solve some of
 those problems, so if those who had problems before could try again
 and let me know what you find, I would be appreciative.  Thanks!

 --Greg

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

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

Re: [sword-devel] Hyphens in book names

[Ben Morgan]

 On Thu, Sep 30, 2010 at 7:17 AM, Greg Hellings greg.helli...@gmail.comwrote:

 Perhaps allowing each locale to define its own numerals and hyphen-like
 character would be a good solution?

This is exactly what BPBible allows. Numerals are defined in the text
section with the identifier 0123456789

e.g. for hindi/nepali
0123456789=०१२३४५६७८९

It also allow hyphens in book names using a workaround.
For example, in vietnamese there will be these two lines for 2 peter (the
first being standard SWORD line, the second mapping from that to a
with-hyphens version).
II Peter=II Phierơ
II Phierơ=II Phi-e-rơ

It's not the neatest solution but it does work.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)


  On Sep 29, 2010 4:08 PM, Daniel Owens dhow...@pmbx.net wrote:
 
  On 09/29/2010 03:55 PM, Robert Hunt wrote:
  New Zealand.
 
  Hello all,
 
  I am spending today studying the documentation on the Crosswire
  Sword wiki so I'm likely to have a few questions. Please let me know
  if this is not the right forum to ask questions.
 
  I see in http://www.crosswire.org/wiki/DevTools:SWORD that
  localised book names are not allowed hyphens in them (because the
  hyphen is used for verse ranges). In the Philippine language that we
  worked with as Bible translators, the hyphen is a letter in the
  alphabet and appears in several book names!
 
  Is this still a current limitation? If so, what is the suggested
  work-around.
 
  Thanks,
  Robert.
 
  This problem came up with Vietnamese, and I was just told to drop the
  hyphens. The result was not ideal, but in the end it is still
  comprehensible in Vietnamese. I think the hyphen was needed because
  Vietnamese is monosyllabic, but more recent transliterations of
  foreign names have simply dropped the hyphens. Would the names still be
  comprehensible without the hyphen?
 
  Daniel
 
  ___
  sword-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] Sword 1.6.2 NOW!

[Ben Morgan]

 On Wed, Sep 15, 2010 at 10:55 AM, Greg Hellings greg.helli...@gmail.comwrote:


 IMO, it would be the other way.  If people see a CMake system they
 will probably think it's exactly like the autotools, which is not easy
 to guarantee.  I would think CMake should be held off for a feature
 update release and the bindings fixes should be included.  My
 alterations in the bindings directory aren't adding new functionality
 - it's fixes for functionality which was there but long broken.  I
 would hesitate to include those changes though, until we've heard from
 the BPBible team.  I've asked a few times since I made the changes and
 haven't seen any comments from them on here.  Either they don't use
 SVN HEAD in their development, or they haven't noticed any breakage.

 --Greg


I did try building sword with cmake on OS X and it seemed to work, as did
the bindings. But I didn't ever get round to running with it. I'm doing that
now, and it appears that  there are problems with it with some of the
VerseKey added methods like bookName
(i.e.
 vk = Sword.VerseKey()
 vk.bookName(2, 2)
b is null for 4536913?!?
)

Could this be because the python version is linking against a libsword 1.6.1
dylib (which was already there from a previous compilation without cmake)
and there have been changes in the .h files which it was including when
building the swig which break things (i.e. no ABI compatibility with 1.6.1)?
That's all I can think of. I haven't got any time to look at it at the
moment really.

Currently trying to use the cmake checked into sword's trunk gives this
error:
[  3%] Building CXX object CMakeFiles/buildtest.dir/buildtest.cpp.o
Linking CXX executable buildtest
[  3%] Built target buildtest
make[2]: *** No rule to make target `../sword', needed by
`CMakeFiles/pythonswig'.  Stop.
make[1]: *** [CMakeFiles/pythonswig.dir/all] Error 2
make: *** [all] Error 2

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Non-Anglophone Bible references

[Ben Morgan]

The source code for the reference parser lives mostly in
src/keys/versekey.cpp:ParseVerseList in the sword source code.

Though it does work quite well, it has a number of problems and is very hard
to maintain/add new features to.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Sat, Jun 19, 2010 at 5:15 AM, Weston Ruter westonru...@gmail.com wrote:

 Troy, This is great! Where's the source code for the reference parser?

 As part of the Open Scriptures osis.py module for representing OSIS
 identifier objects (osisID, osisRef, osisWork, etc), the next step is to
 have a pluggable/extensible system for converting human-formatted references
 into their OSIS equivalents, and also to go in the reverse: converting any
 OSIS object into a localized human-friendly representation. Collaboration
 between SWORD and Open Scriptures would obviously be a win. That being said,
 hopefully I haven't duplicated too much of what SWORD has already for
 handling OSIS identifiers.

 I've got OsisWork, OsisPassage, and OsisID classes assembled so far:
 http://github.com/openscriptures/api
 See tests for how the objects can be used:
 http://github.com/openscriptures/api/blob/a73bdd7d267b70a9e1303a3205c4241f52d3a83e/osis.py#L763

 Weston


 On Fri, Jun 18, 2010 at 11:58 AM, Troy A. Griffitts 
 scr...@crosswire.orgwrote:

 Regarding what we accept currently, you can try experimenting with:

 http://crosswire.org/study/examples/parsevs.jsp


 We do have the ability to provide alternate versification schemes which
 include other books (e.g., apoc.), or completely different book names
 like a versification of Josephus or DSS, but this tool defaults to the
 Protestant KJV v11n.

 Troy



 Forwarded conversation
 Subject: [sword-devel] Non-Anglophone Bible references
 

 From: *David Haslam* d.has...@ukonline.co.uk
 Date: Thu, Jun 17, 2010 at 1:58 PM
 To: sword-devel@crosswire.org



 Tim Bulkeley has written a short item on this topic here.

 http://bigbible.org/sansblogue/bible/non-anglophone-bible-references/
 Non-Anglophonehttp://bigbible.org/sansblogue/bible/non-anglophone-bible-references/%0ANon-AnglophoneBible
  references

 The topic arises out of his frustration at having to perform a massive
 search and replace task to submit an article to a certain European
 theological journal.

 As many CrossWire developers are Anglophone, this may prompt some further
 thoughts that could benefit all our projects.

 David


 --
 View this message in context:
 http://sword-dev.350566.n4.nabble.com/Non-Anglophone-Bible-references-tp2259480p2259480.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

 --
 From: *David Instone-Brewer* techni...@tyndale.cam.ac.uk
 Date: Fri, Jun 18, 2010 at 2:42 AM
 To: sword-devel@crosswire.org


 Tim has over-simplified the situation.
 Other systems include different ways of abbreviating the books.
 In the following, Am is an abbreviation which does not include the end of
 the word,
 while Jas (ie James) does include the end of the word, so it shouldn't have
 a dot after it,
 which results in different systems:

 Am.7   and Jas 1
 Am.7   and Jas.1
 Am. 7   and Jas 1
 Am. 7   and Jas. 1

 Also, in numbering, the Dead Sea Scrolls have re-popularised the use of
 dots instead of colons, ie

 Am 7.1-3, 4-5

 And we haven't dealt with variations in listing other chapters

 Am 7.1-3; 8.1-2
 Am 7:1-3. 8:1-2
 etc

 And then we have the problem of references which span a chapter:

 Am 7.1--8.2   [or use an 'en' dash]
 Am 7.1-8.2
 Am 7.1 - 8.2
 etc

 There are so many 'standards' that it is best simply to pick the one which
 works best for you and stick to it.

 I'd suggest the following is the best compromise between humans and people.

 Amo 7.1-2; 8.1-2--9.2: Thus says the Lord
 Jos Ant 1.2.15: On this day...
 1QS 3.1
 4Q496 2.6.1
 4Qp.Is.a 1.1
 b.San 15.a-b  [this means folio 15, sides a and b]

 This uses:
 - no dots but a space after the abbreviation of the title of the work
 - preceding dot instead of superscript (the a at the end of 4Qp.Is is
 normally superscript)
 - normal numbers where possible (ie no Roman numerals but occasionally you
 need lower case letters)
 - no italics (Ant is normally in italic, as a non-Biblical book title)
 - 3-letter Bible book abbreviation (preferably the same as that used by
 BibleWorks and others)
 - dots dividing between verses, chapters, books and any other levels of
 division.
 - single hyphen for spans of verses
 - double hyphen for spans of chapters
 - semi-colon for separate references
 - colon used to 

Re: [sword-devel] 1.6.1 final call

[Ben Morgan]

 On Fri, Dec 25, 2009 at 9:53 AM, Greg Hellings greg.helli...@gmail.comwrote:

 Visual Studio 9 reporting in:

 I don't have our SWORD version of ICU on-hand, nor is it particularly
 important to those of us over here in the BibleTime community, since
 we use Qt for our transliteration.

 regex.c throws a number of warnings of the type:
 ..\..\..\src\utilfuns\regex.c(3877) : warning C4090: 'function' :
 different 'const' qualifiers

 I also get the following warning:
 inffast.c
 ..\..\..\src\utilfuns\zlib\inffast.c(109) : warning C4047: '=' :
 'unsigned long' differs in levels of indirection from 'Bytef *'

 And, on linking with my cURL build, in Debug, I get
 adler32.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to
 '/OPT:ICF' specification

 I believe those warnings have been there for a long time, so it won't hurt
having them for this version as well...

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Bible with dates in it?

[Ben Morgan]

I think that the TSK has dates in it, presumably Ussher's. These would be
very easy to pull out and make a commentary out of, for example.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Sat, Dec 19, 2009 at 1:34 AM, Barry Drake bdr...@crosswire.org wrote:

 Hi Jon ..

 re: dates in bible .

 Jonathan Morgan wrote:

 Do you have any
 particular Bible version in mind that does this?

 There was a very popular edition of the KJV which had the dates (the gospel
 according to Bishop Ussher) down the centre of the bible (RHS of left page,
 LHS of right page).  Wonderful for six-day creationists.  Ussher's
 Chronology is now sidelined because of the fundamendalist view that in early
 genesis, the chronology according to Ussher is exact.  Ussher himself never
 claimed that!  However, from Israel-in-Egypt onwards, Ussher is accurate
 (more or less) and archaeologically verifiably so, and thus the dates are
 useful - but only after Gen 37 or so (some would say only after the Exodus).

 Personally I'd love to have a module with Usser's chronology as footnotes
 in it.  Any version would do.  Anyone want to think about making it so?

 God bless,
 Barry

 -- From Barry Drake (The Revd) Health and Healing advisor to the East
 Midlands Synod of the United Reformed Church.  See
 http://www.urc5.org.uk/index for information about the synod, and
 http://www.urc5.org.uk/?q=node/703 for the Synod Healing pages.

 Replies - b.dr...@ntlworld.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] Make + configure problems

[Ben Morgan]

Hi,

I'm building SWORD on a mac.
Notes:
I'm running with Matthew's patch from yesterday.
1) libtoolize is called glibtoolize on a mac, so autogen.sh doesn't handle
it properly
2) make uninstall gives the error part of the way through
make[1]: *** No rule to make target `uninstall-info-am', needed by
`uninstall-am'.
3) I'm trying to build 32bit, so I configured with CC=~/gcc32 CXX=~/g++32
where gcc32 runs gcc -m32 and g++32 run g++ -m32.
/bin/sh ./libtool --tag=CXX   --mode=link /Users/benm/g++32 -O3
-DEXCLUDEZLIB -ftemplate-depth-25 -DCURLAVAILABLE -o buildtest
buildtest.o ./lib/libsword.la -lcurl -lssl -lcrypto -Wl,-weak-lldap -dynamic
-Os -pipe -g0 -Wno-system-headers -Wl,-search_paths_first
-Wl,-weak-lgssapi_krb5 -Wl,-weak-lkrb5 -Wl,-weak-lk5crypto
-Wl,-weak-lcom_err -Wl,-weak-lresolv -lssl -lcrypto -lz -lz
libtool: link: unsupported hardcode properties
libtool: link: See the libtool documentation for more information.
libtool: link: Fatal configuration error.

This goes away when I disable static and enabled shared.
As a side note, the CXX variable is not checked by configure, so it may not
even work as expected. I don't know if this is expected or not.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Make + configure problems

[Ben Morgan]

I'm just building in the Mac terminal. I'm not bothering with ICU at the
moment.
I have got it working well enough for now, I think.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Sat, Dec 19, 2009 at 11:12 AM, Manfred Bergmann bergman...@web.dewrote:

 Hi.

 Do you build for your build system or do you cross-compile?

 I'm cross-compiling with Fink's libtool version 1.5.26-3. Actually I never
 had luck with the system supplied libtoolize.
 In order to build with ICU support you need Fink's ICU dev package and a
 manually compiled ICU 3.6.

 export PATH=$PATH:/opt/icu-3.6/bin
 export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/opt/icu-3.6/lib
 ./autogen.sh
 export CC=gcc
 export CXX=g++
 export SDK=/Developer/SDKs/MacOSX10.5.sdk
 export CFLAGS=-O2 -g0 -arch i686 -mmacosx-version-min=10.5 -isysroot $SDK
 -I$SDK/usr/include -I/sw/include
 export CXXFLAGS=$CFLAGS
 export LDFLAGS=-isysroot $SDK -Wl,-syslibroot,$SDK
 ./configure --prefix=$INTELPREFIX --without-clucene --with-zlib --with-conf
 --with-icu --with-curl --enable-tests --disable-shared --enable-utilities
 make all install

 However configure in rev 2488 is broken. Haven't tried any patches though.



 Manfred


 Am 18.12.2009 um 22:04 schrieb Ben Morgan:

  Hi,
 
  I'm building SWORD on a mac.
  Notes:
  I'm running with Matthew's patch from yesterday.
  1) libtoolize is called glibtoolize on a mac, so autogen.sh doesn't
 handle it properly
  2) make uninstall gives the error part of the way through
  make[1]: *** No rule to make target `uninstall-info-am', needed by
 `uninstall-am'.
  3) I'm trying to build 32bit, so I configured with CC=~/gcc32 CXX=~/g++32
 where gcc32 runs gcc -m32 and g++32 run g++ -m32.
  /bin/sh ./libtool --tag=CXX   --mode=link /Users/benm/g++32 -O3
 -DEXCLUDEZLIB -ftemplate-depth-25 -DCURLAVAILABLE -o buildtest
 buildtest.o ./lib/libsword.la -lcurl -lssl -lcrypto -Wl,-weak-lldap
 -dynamic -Os -pipe -g0 -Wno-system-headers -Wl,-search_paths_first
 -Wl,-weak-lgssapi_krb5 -Wl,-weak-lkrb5 -Wl,-weak-lk5crypto
 -Wl,-weak-lcom_err -Wl,-weak-lresolv -lssl -lcrypto -lz -lz
  libtool: link: unsupported hardcode properties
  libtool: link: See the libtool documentation for more information.
  libtool: link: Fatal configuration error.
 
  This goes away when I disable static and enabled shared.
  As a side note, the CXX variable is not checked by configure, so it may
 not even work as expected. I don't know if this is expected or not.
 
  God Bless,
  Ben
 
 ---
  Multitudes, multitudes,
 in the valley of decision!
  For the day of the LORD is near
 in the valley of decision.
 
  Giôên 3:14 (ESV)
 
  ___
  sword-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] Microsoft Visual C++ (Express Edition) DLL and/or LIB?

[Ben Morgan]

 On Tue, Dec 8, 2009 at 10:04 AM, Rendezvous junk_and_m...@yahoo.comwrote:

 I could only get 1.5.9 to compile using those instructions; couldn't get
 1.5.11 or 1.6.0 to compile (didn't try 1.5.10).

If you want help compiling, you really need to give the errors you are
seeing. Without them, we can't tell what is wrong.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Microsoft Visual C++ (Express Edition) DLL and/or LIB?

[Ben Morgan]

I think you need to define SWUSINGDLL in the file/project that uses sword.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Dec 8, 2009 at 1:46 PM, Rendezvous junk_and_m...@yahoo.com wrote:

 They were mostly related to certain headers not being found. But i took
 another crack at the instructions listed on the BibleTime development wiki,
 with 1.6.0, and it compiled fine. However, when i try to compile my program
 with the generated libsword.lib, i get the following error:

 unresolved external symbol private: static char * sword::SWBuf::nullStr

 Having SWDLLEXPORT before that line in swbuf.cpp made no difference. I'll
 try again later, though.

 --- On Mon, 12/7/09, Ben Morgan benpmor...@gmail.com wrote:

  From: Ben Morgan benpmor...@gmail.com
  Subject: Re: [sword-devel] Microsoft Visual C++ (Express Edition) DLL
 and/or LIB?
  To: SWORD Developers' Collaboration Forum sword-devel@crosswire.org
  Date: Monday, December 7, 2009, 6:09 PM
 
  On Tue, Dec 8, 2009 at 10:04 AM,
  Rendezvous junk_and_m...@yahoo.com
  wrote:
 
 
  I could only get 1.5.9 to compile using those instructions;
  couldn't get 1.5.11 or 1.6.0 to compile (didn't try
  1.5.10).
  If you want help compiling, you really
  need to give the errors you are seeing. Without them, we
  can't tell what is wrong.
 
 
 
  God Bless,
  Ben
 
 ---
  Multitudes,
   multitudes,
  in the valley of decision!
  For the day of the
  LORD is near
  in the valley of decision.
 
  Giôên 3:14 (ESV)
 
 
 
  -Inline Attachment Follows-
 
  ___
  sword-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] Proposition concerning module names

[Ben Morgan]

On Wed, Dec 2, 2009 at 10:38 PM, Mark Trompell m...@foresightlinux.orgwrote:

 I wonder if it wouldn't make sense to always display the name of the
 bible/book in the language it is written in.
 You wouldn't read a chinese bible if you can't read it anyway.

We've been over this before  both for module names and the display of module
languages and the consensus is that there is no consensus. Some people like
to see the English name, others would rather see the native name.
Personally, I would want to see (or have the option to see) the English
name. Having an English handle on all the modules is good for developers, as
well..

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] [bt-devel] Unlock Keys and Frontends

[Ben Morgan]

The way I do this in BPBible for the font dialog is to display the current
key if it is there, otherwise look forward and back until a key is found.
http://code.google.com/p/bpbible/source/browse/trunk/fontchoice.py#166

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Mon, Nov 23, 2009 at 11:45 AM, Troy A. Griffitts scr...@crosswire.orgwrote:

 Well, how DO WE, or how SHOULD WE?

 Currently the code at:

 http://crosswire.org/svn/biblecs/trunk/apps/InstallMgr/

 in cipherfrm.cpp does this:

   mod-setKey(Ipet 2:12);
   tmpBuf = mod-StripText();
   mod-setKey(gen 1:10);
   tmpBuf += \r\n\r\n;
   tmpBuf += mod-StripText();
   Memo1-Text = tmpBuf.c_str();

 Maybe we should just:

 for (module == TOP; !module.Error()  !module.getEntrySize(); module++);




 DM Smith wrote:
  I'm curious as to how you select the excerpt? Do you spin across the
  possible keys until you find one w/ content? For example, consider a
  Greek text that's a fragment of a Pauline epistle. Or just the book of
  John in translation of a new lang.
 
  In Him, DM
 
 
 
  On Nov 22, 2009, at 1:05 PM, Troy A. Griffitts scr...@crosswire.org
  wrote:
 
  Sorry for the typos.
 
  I also wanted to say, if an example of how to change the .conf file to
  add the user supplied CipherKey is desired, I can supply a concise code
  snippet.
 
  As far as user flow specifically for entering a key...
  In BibleCS, we show an excerpt from the module, with an edit box for the
  user to type their unlock code, with a [Try] button next to it.  The try
  button sets the unlock code in the module and re-retrieves the excerpt.
  If the unlock code is correct, the user will see the unencrypted module
  excerpt, and they can proceed to hit an [Accept] button to continue.
  But again, obviously each frontend will creatively design their own
  mechanisms.  I would just like to be sure we have _some_ easy way on
  each frontend for our users to know where to obtain and then enter these
  unlock codes.
 
 -Troy.
 
 
 
  Troy A. Griffitts wrote:
  With the recent influx of interest from publisher to make material
  available for our software, I'd like to propose a new .conf entry, and
  encourage frontend developers to polish their facilities for users to
  supply unlock keys for a locked modules.
 
  The .conf entry I'd like to propose for all locked modules is:
 
  UnlockURL=
 
 
  This would be a URL where to begin the unlock process: Purchase form,
  CCAT user agreement form, whatever.
 
 
  Thus the flow in a frontend installer might be to show locked modules
  differently with a special lock icon next to each modules available for
  install, when the module is selected for install, a popup box
 explaining
  that a key is needed, and for obtaining the key to please visit the
  following URL..., possibly even prompting at this time for the unlock
  key.  Obviously each frontend with be creative, as usual, but I believe
  this is a missing, critical piece we need to supply to frontends, for
  them to build a smooth flow for the user.
 
 
 -Troy.
 
  ___
  bt-devel mailing list
  bt-de...@crosswire.org
  http://www.crosswire.org/mailman/listinfo/bt-devel
 
 
  ___
  sword-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] Python client

[Ben Morgan]

A pure-python zText reader was done here:
http://github.com/kcarnold/pysword

However, this has only a fraction of the module support Sword has, and is
also quite a bit slower. The bindings are superior (if available for use, of
course)

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Nov 3, 2009 at 10:35 PM, Mattias Põldaru
mattiaspold...@gmail.comwrote:

 Greetings

 I was wondering if anyone has implemented a pure python program for
 reading sword modules.

 Mattias


 ___
 sword-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] Understanding the structure of generic books and their relationship with TreeKey.

[Ben Morgan]

It's probably easier to create a new TreeKey along the way, otherwise it
won't work properly (going to the parent at the end will lose the place in
the sibling iteration).

void getSectionsList(TreeKey tk, list l)
{
  do {
l.append (tk-getText());
if (tk-hasChildren())
{
 TreeKey new_tk = tk.clone();
 new_tk-firstChild();
 getSectionsList(new_tk, l);
 delete new_tk;
}
   } while (tk-nextSibling())
}

Untested code, of course...

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)

On 03/11/2009, Matthew Talbert ransom1...@gmail.com wrote:

 This might be better. I'm probably still missing some logic.

 void getSectionsList(TreeKey tk, list l)
 {
   l.append (tk-getText());
   if tk-hasChildren()
   {
   tk-firstChild();
   getSectionsList(tk, l);
   }
  while tk-nextSibling()
  {
   getSectionsList(tk, l);
  }
  tk-parent();
 }

 Matthew

 ___
 sword-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] Submitting a Patch against 1.60svn

[Ben Morgan]

On Tue, Oct 20, 2009 at 8:36 AM, Troy A. Griffitts scr...@crosswire.orgwrote:

 Thanks for the patch Nathan,

 Is this really necessary?  This has been in the code for quite some time
 and BPBible has been working with swig bindings for quite some time with
 this in the code.  I don't believe this inner class should ever be
 exposed in the bindings, as it is a mechanism we use in the
 implementation of a specific derived class, and not a basic interface.

 This isn't necessary for me; SWIG will give warnings about nested classes,
but not errors (they just won't be wrapped).
It is actually possible to get round these restrictions, but here it isn't
worth it.

The place I'd actually be a little more worried about the nested classes is
in the av11n code, with VerseMgr::System, etc.


God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Submitting a Patch against 1.60svn

[Ben Morgan]

On Tue, Oct 20, 2009 at 10:02 AM, Nathan Anderson nat...@andersonsplace.net
 wrote:

 Troy,

Your welcome for the patch.  ;-)

Well, I might be the _new_ guy; but I don't typically waste my time
 trying to patch something and return it up-stream if it isn't broken.  So I
 would say yes it is necessary.  ;-)

 What version of SWIG are you using? are you using the swig sword bindings
from SVN?
This works for me.


I can also answer your question about BPBible.  According to their
 instructions you need to use v1.5.11 of Sword with the current version of
 BPBible.  The change to the VerseTreeKey (which exposes this class),
 according to SVN, changed in Rev 2178 on July 20th, 2008 by scribe and this
 change is _AFTER_ version 1.5.11 was released.  So, BPBible would be broke
 with 1.6 and 1.6-svn.  ;-)

Were does it say this? It needs to be changed.
BPBible currently expects/uses SWORD 1.6.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Submitting a Patch against 1.60svn

[Ben Morgan]

It looks like you need a newer version of SWIG.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Oct 20, 2009 at 12:05 PM, Nathan Anderson nat...@andersonsplace.net
 wrote:

  Ben,

 Ok, you got my attention g totally!

 I could not not find any way to compile the Sword.cxx module generated
 by swig in 1.60/1.60svn (I could do it fine in 1.5.11)   How exactly did you
 get past the VerseManager referencing the inner TreeView PositionListener
 class in 1.60?


  Is their some swig parameter that allows it to generate some of the inner
 classes.

  I just pulled a fresh trunk version.  This is compiled against Clucene
 0.9.21b and ICU 4.2.1.
 Here is the error messages from a fresh SVN trunk (w/o my patch) version :

 After compiling Sword with the following options:

 OPTIONS=--prefix=/usr $OPTIONS
 OPTIONS=--libdir=/usr/local/lib $OPTIONS
 OPTIONS=--sysconfdir=/etc $OPTIONS
 OPTIONS=--without-conf $OPTIONS
 OPTIONS=--enable-shared $OPTIONS
 OPTIONS=--disable-debug $OPTIONS
 OPTIONS=--with-icu $OPTIONS
 OPTIONS=--with-clucene $OPTIONS
 OPTIONS=--disable-tests $OPTIONS
 I type:
 cd bindings/swig/packages
 ./autogen.sh
 ./configure
 make pythonswig
 make python_make

 ---

 I get:

 Sword.cxx: In function `PyObject*
_wrap_TreeKey_setPositionChangeListener(PyObject*, PyObject*)':
 Sword.cxx:42224: error: `PositionChangeListener' undeclared (first use this
function)
 Sword.cxx:42224: error: (Each undeclared identifier is reported only once
 for
each function it appears in.)
 Sword.cxx:42224: error: `arg2' undeclared (first use this function)
 Sword.cxx:42224: error: parse error before `)' token
 Sword.cxx:42242: error: parse error before `*' token
 error: command '/scratchbox/compilers/host-gcc/bin/gcc' failed with exit
 status 1
 make: *** [python_make] Error 1
 

 Swig Version 1.3.29

 After applying my patch I can build it

 Nathan





  --
 *From:* Ben Morgan [mailto:benpmor...@gmail.com]
 *Sent:* Monday, October 19, 2009 5:10 PM
 *To:* SWORD Developers' Collaboration Forum
 *Subject:* Re: [sword-devel] Submitting a Patch against 1.60svn

  On Tue, Oct 20, 2009 at 8:36 AM, Troy A. Griffitts 
 scr...@crosswire.orgwrote:

 Thanks for the patch Nathan,

 Is this really necessary?  This has been in the code for quite some time
 and BPBible has been working with swig bindings for quite some time with
 this in the code.  I don't believe this inner class should ever be
 exposed in the bindings, as it is a mechanism we use in the
 implementation of a specific derived class, and not a basic interface.

 This isn't necessary for me; SWIG will give warnings about nested classes,
 but not errors (they just won't be wrapped).
 It is actually possible to get round these restrictions, but here it isn't
 worth it.

 The place I'd actually be a little more worried about the nested classes is
 in the av11n code, with VerseMgr::System, etc.


 God Bless,
 Ben

 ---
 Multitudes, multitudes,
in the valley of decision!
 For the day of the LORD is near
in the valley of decision.

 Giôên 3:14 (ESV)


 ___
 sword-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] locales

[Ben Morgan]

On Tue, Oct 13, 2009 at 2:38 PM, Chris Little chris...@crosswire.orgwrote:

 3) There are xx_abbr or xx_abbrev locales for German, French, Estonian, and
 Korean and an abbr locale for English. Does anyone actually use any of these
 as their locale? Or are they used in some other way by any front end?

BPBible uses the abbreviations locales for abbreviations (though not
necessarily as they stand in sword SVN trunk - we have our own copy of them,
I think)


 This might have to wait a while, since I foresee it requiring an API
 change, but I would like to fold these into their language's primary locale
 files. (I.e., where we currently have sections called [Meta], [Text], and
 [Book Abbrevs], we would add an [Abbr] section.) Then we can add methods to
 retrieve abbreviations instead of full book names. This allows us to reduce
 the redundant [Book Abbrevs] sections and avoids the current situation where
 locale selection drop-downs include a bunch of languages plus a bunch of
 localized abbreviations.

That sounds a good idea.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Crashes Was: experimental repository new ...

[Ben Morgan]

On Wed, Oct 7, 2009 at 3:37 AM, jhphx jh...@cox.net wrote:



 That's a good reason, right.
 But then even in beta is a potential risk of applications crashing when
 loading a module and on startup when the module is automatically loaded
 because it still is stored in the session.
 We can make sure that every module in beta does at least load correctly on
 the front ends.


 Manfred


 A flag placed as the last thing done at successful shutdown of the program
 and checked and removed before loading a session could be used to prompt the
 user that the saved session may have problems and ask to skip it, so
 avoiding another crash.

There are some modules which may crash when trying to access them. These are
unlikely to ever be in beta, as these are experimental (for a good reason).
Saving the session may help, but if the application accesses all modules on
startup, it may still crash.

A module in beta is no more likely to crash than a module in the main
repository (in fact, it probably is less likely to, as it will be a revision
of a pre-existing module)

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Windows users as poor cousins?

[Ben Morgan]

Hi Jonathan,

Visual Studio is the best way to compile on Windows. I used to compile with
mingw + msys, but the environment feels slow and clumsy, and it produces
larger, slower executables. And Visual Studio is free - you can download the
express editions.

Visual Studio seems to me much easier to work with, compiles faster and
produces better executables. Visual Studio also is much better supported
than mingw.

Your argument that you can't fix VC++ is I think irrelevant; it is very
stable, and even if I do have something wrong in some software (VC++ or
openoffice or whatever), I'm very unlikely to dive in and attempt to fix it.
Being able to modify software doesn't greatly help me.


 IMO it's really sad that anyone would choose an open source
 cross-platform language such as Python, on top of an open source
 cross-platform library such as SWORD, and then deliberately restrict the
 resulting application to just one OS.  But it is your project, and so
 entirely your choice.

Python, though cross-platform, on Windows is built with Microsoft tools (as
they are the best for purpose). Likewise, BPBible compiles SWORD with
Microsoft tools, as they are the best. Mozilla/Firefox is likewise compiled
on Windows with Microsoft tools, and mingw is a tier-2 platform for them.

BPBible does work on linux, and I routinely run it on Linux. I've even run
it on a Mac. But neither of these platforms is as well supported (i.e.
binaries distributed) because most users are on windows (also because I
don't know how to do packaging really for linux...)

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] PySword

[Ben Morgan]

They are different.
The former is a boost.python wrapping of sword
The latter is a pure-python implementation of a zText reader.
Neither are frontends, but libraries.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Sep 29, 2009 at 10:37 AM, jonathon jonathon.bl...@gmail.com wrote:

 All:

 I found a project named pysword at sourceforge
 (http://sourceforge.net/projects/pysword/) and another project named
 pysword at  http://github.com/kcarnold/pysword.

 Is the latter a continuation of the former, or  something completely
 different from the former?

 Both purport to be front ends for The Sword Project, written in python.

 jonathon

 ___
 sword-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] RenderText and static local buffer

[Ben Morgan]

I was debugging a problem in the XUL BPBible where it was filling in a table
for a gospel harmony inside the render filter.
Thus, it was calling RenderText inside a RenderText (though on a different
module). It was ending up with the last verse in the table coming before the
table, which was a bit annoying.

Digging through the code, I finally discovered what the problem was.

In SWModule's RenderText, there is this:
 static SWBuf local;
 if (buf)
  local = buf;

 SWBuf tmpbuf = (buf) ? local : getRawEntryBuf();

So what was happening was that in the middle of the render filter, it was
swapping new buffer contents in, thus ending up with what last came out at
the start to be added onto in the first level of render filter.

So there can only ever be one RenderText call where the buffer is supplied.
If a SWBuf could be passed in this would allow a work-around. Likewise, if
the local buf was on the module, rather than global, this would help.

 http://www.apostlesbible.com/God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Pre-verse headings and osis2mod

[Ben Morgan]

I have a couple of problems with pre-verse headings and osis.
First up, pre-verse div's have been introduced, superseding the old title
x-preverse hack.
How can you tell from the entry attributes whether it came from a title or a
div? is it just that if it comes from a title, it won't start with an ?
I've tried that in BPBible, and it seems to work - but I don't really trust
it. (this is important in BPBible because otherwise it starts wrapping the
contents of pre-verse divs inside h6 tags, creating loads of whitespace...)

It would make it more consistent if the heading filter output the title
around it for the old-style pre-verse titles.

I've attached a (validating) OSIS document, and the raw verse data file for
it. It's possibly not good OSIS, but I don't know.

Observe the probable abundance of whitespace, and try turning headings on
and off.
One big problem here is that structure is being put into these pre-verse
divs by osis2mod.
This includes things like paragraph starts, poetry line starts, etc.
(e.g.
l level=1verse sID=Mark.1.3 osisID=Mark.1.3/Line level 1verse
eID=Mark.1.3/
=
div type=x-milestone subType=x-preverse sID=pv3/l level=1
sID=gen6/div type=x-milestone subType=x-preverse eID=pv3/Line
level 1
)

Unless the structure is completely contained in the pre-verse div, it
shouldn't be turned off when the headings filter is turned off.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
?xml version=1.0 encoding=UTF-8?
osis xmlns=http://www.bibletechnologies.net/2003/OSIS/namespace; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.bibletechnologies.net/2003/OSIS/namespace http://www.bibletechnologies.net/osisCore.2.1.1.xsd;
	osisText osisIDWork=thisWork osisRefWork=bible xml:lang=en
		header
			work osisWork=thisWork
titleTest/title
type type=OSISBible/type
identifier type=OSISTEST/identifier
scopeMark/scope
refSystemBible/refSystem
			/work
			work osisWork=bible
type type=OSISBible/type
refSystemBible/refSystem
			/work
		/header
		div type=book osisID=Mark
			title level=1Book title - Mark/title
			chapter sID=Mark.1 osisID=Mark.1/
			div type=section scope=Mark.1.1-Mark.1.8 xml:space=preserve
titleSection title - Mark 1:1-8/titlep
	verse sID=Mark.1.1 osisID=Mark.1.1/Mark 1:1verse eID=Mark.1.1/
	titleMark 1:2's title/title
	verse sID=Mark.1.2 osisID=Mark.1.2/Mark 1:2
	lg
		l level=2Line level 2/l
		verse eID=Mark.1.2/
		l level=1verse sID=Mark.1.3 osisID=Mark.1.3/Line level 1verse eID=Mark.1.3/verse osisID=Mark.1.4 sID=Mark.1.4 /Mark 1:4/l
	/lg
	End of mark 1:4
	verse eID=Mark.1.4 /
	interverse text
	verse sID=Mark.1.5 osisID=Mark.1.5 /
	Test verse 5
	verse eID=Mark.1.5 /
/p
p
	titleverse 6 pre-verse title/title
	verse sID=Mark.1.6 osisID=Mark.1.6 /
	Test verse 6
	verse eID=Mark.1.6 /
/p
			/div
		chapter eID=Mark.1 /
		/div
	
	/osisText
/osis


nt
Description: Binary data
___
sword-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] Printing an encrypted module?

[Ben Morgan]

Encryption on modules stops people using modules which they haven't paid
for, while stilling allowing installmgr to download them.
Content control (stopping printing, copying, etc.) is a completely different
issue, and may be relevant even for non-encrypted modules.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)


On 27/08/2009, David Haslam d.has...@ukonline.co.uk wrote:


 Presumably an encrypted Bible module is still printable (as well as
 displayable) by any frontend SWORD (or JSword) application that has a print
 option?  Tell me if I am wrong.

 Suppose therefore that a frontend application existed that has print dialog
 options that can be selected to print from Genesis 1:1 through Revelation
 22:21, then in theory, the whole Bible text can be printed in one go,
 right?

 There is nothing to stop anyone developing a frontend with such a feature.
 All our code is open source.

 Since printer drivers abound that can print to PDF or other electronic
 formats, the whole text of a locked module could therefore be output to a
 PDF file, with no security properties preventing further copying.

 So what does locking a module really achieve?

 Anyone seen the emperor's clothes recently?

 -- David
 --
 View this message in context:
 http://www.nabble.com/Printing-an-encrypted-module--tp25167239p25167239.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] using encryption with current osis2mod (r2435

[Ben Morgan]

On 26/08/2009, DM Smith dmsm...@crosswire.org wrote:

 It does not work.


We found this out a while ago, didn't we?



 The code that has been there forever, no longer works. I checked out
 revision 1929 from June 2006 and with minor changes, compiled it against the
 current SWORD library. It has the same problem.

 That code is:
SWFilter *cipherFilter = 0;

if (!cipherKey.empty()){
fprintf(stderr, Adding cipher filter with phrase: %s\n,
 cipherKey.c_str() );
cipherFilter = new CipherFilter(cipherKey.c_str());
module-AddRawFilter(cipherFilter);
}

The rawfilters are run when text is taken out, not put in. So
the cipherfilter will never be run.


 This is the same that is used in mod2zmod and tei2mod. Interestingly,
 cipherraw works entirely differently.


 I don't have a good environment to debug it and would appreciate someone to
 look at it. The basic idea is that the cipher is used on the raw text of a
 verse to create a jumbled string of the same length.


If no one else does, I can probably look at this in a few hours...

Then there is the question of why Jonathan has it working... Are you sure
cipherraw hasn't been near the module? Unmodified code from SVN?
God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] using encryption with current osis2mod (r2435

[Ben Morgan]

On Wed, Aug 26, 2009 at 9:54 AM, Ben Morgan benpmor...@gmail.com wrote:

 On Wed, Aug 26, 2009 at 9:21 AM, Troy A. Griffitts 
 scr...@crosswire.orgwrote:

 I believe the problem is with RawText, but haven't had time to confirm.

 My suspicion is that if you are building a compressed module,
 enciphering should work.

 Just to clear up a few things...

 rawFilters get called (or should get called) when retrieving and when
 setting text.



 If there is still a problem, this is the line of code which should be
 enciphering the data, so we need to see why it is not.

 sword/src/modules/common/zverse.cpp:363

 I haven't hunted down the equiv line in rawverse.cpp but suspect we just
 never added the required 2 lines to readText and doSetText in this file
 because when we've ever needed to release an enciphered module, it was
 released as a compressed module.

 Yes, it looks like some of the text it is being passed through the cipher
 filter in some way, even in rawverse.
 However, preverse content doesn't look like its working properly, appended
 content ditto. I just can't reliably get it working on any setting.
 I will investigate further...

The only reason I was seeing this was because I had text being appended (and
so was being re-retrieved) - rawverse isn't putting enciphered content in to
the module.


God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] using encryption with current osis2mod (r2435

[Ben Morgan]

On Wed, Aug 26, 2009 at 9:21 AM, Troy A. Griffitts scr...@crosswire.orgwrote:

 I believe the problem is with RawText, but haven't had time to confirm.

 My suspicion is that if you are building a compressed module,
 enciphering should work.

 Just to clear up a few things...

 rawFilters get called (or should get called) when retrieving and when
 setting text.



 If there is still a problem, this is the line of code which should be
 enciphering the data, so we need to see why it is not.

 sword/src/modules/common/zverse.cpp:363

 I haven't hunted down the equiv line in rawverse.cpp but suspect we just
 never added the required 2 lines to readText and doSetText in this file
 because when we've ever needed to release an enciphered module, it was
 released as a compressed module.

Yes, it looks like some of the text it is being passed through the cipher
filter in some way, even in rawverse.
However, preverse content doesn't look like its working properly, appended
content ditto. I just can't reliably get it working on any setting.
I will investigate further...

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] using encryption with current osis2mod (r2435

[Ben Morgan]

I didn't have USBINARY defined, so encyphering wasn't doing anything x-(
Once I do, zipped modules seem to work as expected. Raw ones don't.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] .Net Exception Odd behavior...

[Ben Morgan]

It is getting pretty hard to compile with C#, as C# doesn't have as good
support with SWIG. There are two problems here - one is that some of the new
code that I added for Python (which is currently the principal target)
doesn't work on C#, as SWIG for C# doesn't handle some of the templates -
I'll try to fix that (by #ifdef'ing out the code which doesn't work for
C#...)

The other problem is that SWIG wasn't generating code which wouldn't compile
without modifying.
I think I did get some code compiling under C# last time some one asked
about it, but it wasn't easy.

As to the GC problem, at least on python you set filterManager.thisown =
False, and this means it won't be GC'ed. Not sure if SWIG has the same thing
for C#.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
On 22/08/2009, Wade Balzer wbal...@newjerusalem.org wrote:

  That was the biggest problem I had was trying to regenerate the wrapper.



 I compile all the latest updates successfully in VS C++ 2008, but I can’t
 get SWIG to regenerate the wrapper for C#.  So I have been using an older
 version of the compiled binary that is buggy.



 The latest version of SWIG does have fixes and better handling, but I can’t
 get it to compile.  Ugh.  Apparently,  the latest updates to the header
 library were targeted to a PHP target leaving a C# target broken.  :-(



 So… because I couldn’t get it working, I  started to create my own modules
 from an OSIS source.  I was going to parse out the modules and place them on
 a SQL Server, but my tests have been slow searching through an unindexed
 field. (2 minutes to search for a single word using a CLR Regex function.
 Yuck.)   At least with a map of an OSIS document, I can locate each verse
 and traverse all the verses in the bible in under 5 seconds.  If I create a
 binary index, I can return all occurrences of God in less than a second.



 I think I still would rather use the SWORD Library because it is faster on
 searches, and has more people involved in updating the core library.



 My only other option was to create a native C# Sword Library, but I don’t
 have the time or energy to recreate the wheel.



 If anyone can help by taking the latest code base, and recompile a working
 SwigSword.dll targeted for C# and accompanying dll’s, that would be very
 helpful.  Let me know how you got it working would cool too.



 Thanks,



 Wade



 *From:* Jeff Becker [mailto:jbec...@fiveviews.com]
 *Sent:* Friday, August 21, 2009 11:11 AM
 *To:* SWORD Developers' Collaboration Forum
 *Subject:* Re: [sword-devel] .Net Exception Odd behavior...



 It could be the same problem I ran into some time back.  The SwigSword code
 destroys some pointers then tries to use them again.  Under .Net 1.0 it
 wasn't a problem because the error was ignored.  Under .Net 2.0 it raises an
 error and crashes the calling application.  In my case it was MS Word since
 I was working on an Add-In but it would probably crash anything calling the
 dll.



 I'm hoping that Swig has fixed the .Net 2.0 pointer issue.  If that's the
 case then the easiest approach might be to regenerate the wrapper.  I'm
 guessing that the problem isn't in just one property or method since the
 code relatively consistent throughout.

 -Original Message-
 *From:* Wade Balzer [mailto:wbal...@newjerusalem.org]
 *Sent:* Friday, July 31, 2009 11:42 AM
 *To:* sword-devel@crosswire.org
 *Subject:* [sword-devel] .Net Exception Odd behavior...

 I am working on a Bible project in C# for the web.  I am using the
 SwigSword.dll wrapper.



 When I load the manager using the default location for the modules as
 provided by the SWORD_PATH environment, it words fine and the debugger exits
 without a problem.



 filterManager = new MarkupFilterMgr((char)Sword.FMT_OSIS, (char)Sword
 .ENC_HTML);

 manager = new SWMgr( filterManager);



 GC.SuppressFinalize(filterManager);



 However since this will be a web environment, I need to directly point to
 the Module locations without directly pointing to my local %SWORD_PATH%
 variable.



 When I set the location of the config, and manually set the location of the
 module path, everything seems to work fine until I exit the debugger.  It
 CRASHES.



 SWConfig config = new SWConfig(BaseModDir + mods.d\\global.conf);

 SWConfig sysconfig = null;



 filterManager = new MarkupFilterMgr((char)Sword.FMT_OSIS, (char)Sword
 .ENC_HTML);

 //manager = new SWMgr( filterManager);

 manager = new SWMgr(config, sysconfig, false, filterManager);

 manager.configPath = BaseModDir + mods.d\\;

 manager.prefixPath = BaseModDir;

 manager.Load();



 manager.augmentModules(BaseModDir);



 GC.SuppressFinalize(filterManager);



 I am not sure why the first one works without a problem, and the second one
 works, but crashes on exit.



 

Re: [sword-devel] Need some help before starting new OSIS file

[Ben Morgan]

Just some additional info from my point of view (as a BPBible developer, not
as a module creator):

On Fri, Aug 21, 2009 at 8:16 AM, Daniel Owens dhow...@pmbx.net wrote:

 That should work, but the wiki advises this:

 q marker=#8220 sID=qN/ ... q marker=#8221 eID=qN/

 I'm not sure if the start and end IDs really matter. You can always try it
 without them. If it doesn't work you haven't lost anything, I suppose. You
 can just insert the unicode character too, if I am not mistaken, though
 that's not the best practice.

sID's *must* be matched with eID's. There are two forms of quotes (this
generalizes to all osis milestoneable elements) qtext/q and q
sID=quote-id /test q eID=quote-id /, where quote-id is unique to this
quote. The latter is useful as it can go across paragraph breaks. I would
strongly recommend having these quotes in here.


   3Can I implement line breaks using lb within a verse?  (They are not
 grouped so lg seems like a lot of work to get the same result.)

 I have tried this and it doesn't work very well. Last I knew, osis2mod
 converted lg and l elements so that the output is lb
 type=x-end-paragraph/ lb type=x-begin-paragraph/. You can always try
 inserting that at the end of each paragraph, but it's not the best practice.
 I haven't worked on this for awhile, but my memory of back then (a year
 maybe) is that it was the challenging part of preparing a module.

Why do you need line breaks? If these denote paragraphs, they really should
be marked as paragraphs.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Thayer's and BDB lexicons

[Ben Morgan]

Read http://crosswire.org/forums/mvnforum/viewthread_thread,560#1709
Basically, what was supposed to be Thayer's were from modified versions from
Online Bible, and thus not in the public domain.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Mon, Aug 17, 2009 at 4:24 PM, Teus Benschop teusjanne...@gmail.comwrote:

 Good day,

 Looking through the various archives of sword-devel, several years back
 it mentioned the Thayer's and BDB lexicons, as if these were produced as
 modules for the Sword system.

 Could I ask a question in relation to this?

 Are these modules still available?
 Are these in the public domain?
 What sources were used for these?

 Thanks for any help.

 Teus.


 ___
 sword-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] Sections, Titles and OSIS hiccups

[Ben Morgan]

Are you using osis2mod from SVN? If not, then this may have been fixed
already.
God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Sun, Aug 16, 2009 at 4:00 PM, Greg Hellings greg.helli...@gmail.comwrote:

 OSIS fans and module gurus,

 I'm trying to follow the best practices of OSIS here, but things just
 seem a little out of whack - and it regards the mischevious
 inter-verse content.  I have rendered the following OSIS snippet:

verse eID=Matt.1.25/
chapter eID=Matt.1/
 /div
 div type=section canonical=true
titleAng Pag-abot it mga Mainalamon nga mga Tawo/title
chapter osisID=Matt.2 sID=Matt.2/
verse osisID=Matt.2.1 sID=Matt.2.1/

 While this seems like the right way, conceptually, to do things in my
 opinion, the results are not what I want.  The title text clearly is
 associated with Chapter 2, in both semantics and in the OSIS document
 itself.  Title is a sibling of the chapter osisID=Matt.2 element,
 while being but a cousin of Matt.1's elements.  When I display the
 text in a frontend, however, I find the text of that title at the end
 of chapter 1 instead of right before chapter 2.

 More frustrating, though, the following corresponding snippet, from
 the beginning of the book:
 div type=book canonical=true osisID=Matt
title type=main short=MattMatt/title
div type=section canonical=true
titleAng mga Ulang ni Jesu Kristo/title
chapter osisID=Matt.1 sID=Matt.1/
verse osisID=Matt.1.1 sID=Matt.1.1/
 renders exactly as I want it to.  When I pull up Matthew 1, I get the
 section title, Ang mga Ulang ni Jesu Kristo, right before verse 1.
 That's what I want to happen with identical code at the beginning of
 chapter 2, but it doesn't!

 I realize that calculating such relative relationships is possibly
 beyond the ken of osis2mod, but is there any better means I could use
 to associate that title with chapter 2?  It's not a chapter title, so
 putting it inside of either chapter limits is clearly incorrect.  I
 could possibly render it to be part of Matt.2.0, but it's not an
 introduction, and the section that it titles does not span the whole
 chapter and the title would not be displayed anyway, in most
 frontends.

 My own suggestion is that a title element should be associated with
 the object that it precedes - at least in the English speaking world
 I'm accustomed to seeing titles before their works.  Whether or not it
 is actually *part of* that object is probably a case-by-case
 situation, and one best left up to the encoder.  But, in the interim,
 what am I to do here?

 --Greg

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

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

Re: [sword-devel] Wiki Misrepresentation

[Ben Morgan]

Yes, we have been through this before.

The answer we have got from the FSF is that GPL compatible licenses are OK
for *all* code of frontends using the library, but of course the whole thing
has to operate under the GPLv2 (so you can't get round GPL restrictions by
using a compatible license on the frontend).

Just out of curiosity, what GPLv2 only non-crosswire code is there? I can't
see any with a quick look.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Tue, Aug 4, 2009 at 9:43 AM, Famile von Kaehne ref...@gmx.net wrote:

 Greg,


 We have been on teh mailing list through this discussion already a few
 dozen of times.


 If you write GUI code for _a_ bible programme and then go looking for a
 suitable backend, + decide to go for libsword your initial independent
 GUI code may be under any licence you see fit as long as it is GPL
 compatible, your glue code must be GPL and the overall application must
 be GPL. The best example within the fold of sword related programmes is
 LCD Bible. The guy who wrote it republished his GUI with a couple of
 other backends and some of these are not GPL but closed source. His
 originl fronend code may be under whatever license, but he needed to
 relicence everything as GPL prior to publishing.


 If you start out with libsword and build your code upon that then you
 start out under GPL and  continue. If you end up incorporating
 pre-existing code from something else, then this (as above) may be under
 any other GPL compatible license and the overall final product will be
 again GPL.


 There are a few outlying cases which have been raised a few times and a
 couple of people suggested ingenuous sever/client constructions which
 they felt  would allow them to bypass the overall GPL but thgese are the
 exceptions (which might not even apply if you set a lawyer onto it.


 The main confusing aspect is GPL compatible. This can mean two things


 a) a license which is free enough to allow code under it be incorporated
 into GPL code.


 b) a license which states the same as the GPL but uses other words.


 Latter practically does not exist, but lingers in people's minds and
 confuses the issues. Former are BSD amd MIT style free licenses or
 indeed public domain code. The compatibility is a one way street. I
 can incorporate BSD/MIT/PD code into  my GPL programme but I can not
 incorporate GPL code into my BSD programme without licensing the lot as
 a GPL programme.


 With regard to GPL 2 vs 3 - again this has been raised a few times. The
 FSF is  pushing GPL 3, but for us this is no option as some of the code
 we use is GPL vs 2 only. GPL v2 and v3 are not compatible.


 yours in him


 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] KJV Beta issue

[Ben Morgan]

BPBible 0.4.4 currently displays a pilcrow without a space after it, as that
is what is in the text.
BPBible 0.5 will turn these into paragraphs, as that is what they represent.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Sun, Jun 14, 2009 at 7:07 PM, David Haslam d.has...@ukonline.co.ukwrote:


 I later observed that BibleDesktop does display a space after each pilcrow.
 It may therefore be an issue for BPBible rather than KJV source text.

 I'm currently having problems with Xiphos - so can't yet check that as a
 front end.

 I still have SPW version 1.5.9 installed, and that doesn't display the
 pilcrows!
 It will be some time before I get round to installing 1.6

 I will keep my eyes open to see if other front ends display them.

 David



 DM Smith-5 wrote:
 
 
 
  Sent from my iPod
 
  On Jun 13, 2009, at 1:57 PM, David Haslam d.has...@ukonline.co.uk
  wrote:
 
 
  Hi DM,
 
  In my printed KJV Bibles, there is usually a space between the
  Pilcrow and
  the first letter of the verse text.
 
  These spaces seem to be absent (I am currently viewing with BPBible).
 
  For some leading letters, such as I, the omission of such a space
  causes
  poor legibility (with some fonts).
 
  Example, Isaiah 45:5
  ¶I am the LORD, and there is none else, there is no God beside me: I
   girded
  thee, though thou hast not known me:
 
  Is this a text-source markup issue, or a front end bug?
 
 
  I could argue either way. I think I'll fix it in the source.
 
  Thanks for the find.
 
  In Him,
DM
 
  David
 
  btw.  Isaiah 45 was one of today's M'Cheyne readings.
  One of my four KJV printed editions had no Pilcrow for this verse!
 
 
 
  DM Smith-5 wrote:
 
  Brian J. Dumont wrote:
  I'm using KJV Beta (2.4), and have noticed quite a few paragraph
  markers (¶) which show up.  See Num 16:12 for one example.
 
  Shouldn't these be replaced with osis markup to denote paragraphs?
 
 
  No, they are part of the text of the KJV.
 
  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
 
 
 
  --
  View this message in context:
  http://www.nabble.com/KJV-Beta-issue-tp23962991p24014830.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
 

 --
 View this message in context:
 http://www.nabble.com/KJV-Beta-issue-tp23962991p24019800.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 Beta issue

[Ben Morgan]

On Mon, Jun 15, 2009 at 10:15 AM, Greg Hellings greg.helli...@gmail.comwrote:

 On Sun, Jun 14, 2009 at 6:59 PM, Ben Morganbenpmor...@gmail.com wrote:
  BPBible 0.4.4 currently displays a pilcrow without a space after it, as
 that
  is what is in the text.
  BPBible 0.5 will turn these into paragraphs, as that is what they
 represent.

 This should DEFINITELY be an option, as they don't actually represent
 paragraphs.  They represent printed Pilcrow characters in the KJV
 text, not paragraphs.  The reader should understand they indicate the
 beginning of a conceptual paragraph according to the translators'
 intentions, but they do not actually represent paragraphs in the
 printed text.

I'm not sure how much I care about the printed text; if the printed text is
verse-per-line, this doesn't mean that I have to restrict the users to this.
Similarly, if the printed text uses pilcrows, it doesn't mean that users
have to see them.

I'm not sure what distinction you are drawing between conceptual
paragraphs and actual paragraphs unless it is just talking about
representing the text exactly.

I could put an option in to let people display the pilcrows... and then
maybe put some title text explaining them on mouseover...

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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 Beta issue

[Ben Morgan]

On Mon, Jun 15, 2009 at 10:43 AM, Greg Hellings greg.helli...@gmail.comwrote:

 Personally I think that would be better than just forcing either one,
 and is a feature I've often thought would be well received.
 Personally I think it might be interesting to see where the
 translators thought these paragraphs ought to be as compared to more
 recent translators, etc.  The more user choices, especially useful and
 well explained choices, the better (in my opinion).

Developers like options, but usability studies suggest that they are not so
good for users. Special care should be taken with the default options, as
many users may not change them. Also, lots of options give many more
combinations where things can break - which can lead to regressions easily.
So options have to be introduced with care.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] How broadly do we define API (was: Re: which engine sources to use )

[Ben Morgan]

On Wed, Jun 10, 2009 at 1:51 PM, Dmitrijs Ledkovs
dmitrij.led...@gmail.comwrote:

 Keep the same svn. With a little bit of auto-foo magic you can
 generate two different tarballs and release either of them at their
 respective schedules.

 IMHO this should be at least done for the bindings. Because python
 bindings autofoo assumes that the libsword is already installed on the
 system during build-time. This is very hard to satisfy on buildd /
 chroot. On the other hand if bindings were a separate tarball it could
 easily build-depend on libsword such that we (as is packagers) create
 libsword package first and then create bindings package.

 Maybe I'm wrong. In that case could you please suggest how to build
 python bindings when all you have is compiled sword in the current
 directory, or you have libsword installed into $DESTDIR eg. in debian
 case ./debian/libsword/usr/lib/ and other similar paths.

IIRC, you can do --with-sword-dir=$DESTDIR.

As to the case for splitting the bindings off, I'm not sure whether this is
wise or not. BPBible will probably sometime ship with its own bindings (that
way I can do more efficient BPBible-specific filters)

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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 handling of OSIS paragraphs

[Ben Morgan]

On 07/06/2009, Chris Little chris...@crosswire.org wrote:

 The *htmlhref filters are the GnomeSword filters. They may now be used by
 other front ends, and the GnomeSword/Xiphos team may have abandoned their
 maintenance, but they were originally written by Terry and do some
 non-standard stuff (as opposed to the *html filters, which should just
 output valid html fragments). They were included in Sword long ago at his
 request.


The *html filters haven't been maintained for a long time (as far as I can
tell) and probably need removing - the htmlhref ones do a more reasonable
job of html rendering.

So, while others may happen to know the purpose of all of these !Ps, it's
 also possible that the only ways of determining their purpose and the
 answers to your questions would be to ask Terry or dig through the code of
 Xiphos (or possibly an old version of GnomeSword).

BPBible just changes these into /pp (I think). My guess was these
were to mark a new paragraph and possibly end an old one.
I don't think !Pbr / should ever be output, or !/P.
Possibly p or /pp is best? I don't think br / is good.

Another problem I have noticed with paragraphs is in some cases, the
paragraphs output try to include a heading (whereas I don't believe
paragraphs should include headings in HTML...)

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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 beta

[Ben Morgan]

On Mon, Jun 1, 2009 at 10:57 PM, DM Smith dmsm...@crosswire.org wrote:


 On May 31, 2009, at 11:13 PM, Ben Morgan wrote:

 It seems to work in BPBible, with one exception:
 Currently pre-verse canonical headings are turned off by the osis headings
 filter when headings are off. This is because it is looking at the canonical
 attribute on the pre-verse div's tag, rather than title inside it.

 I think the output of osis2mod is correct, and this is a 1.6.0 bug.


 I think so too. As I just noted in my response to Ryan, much of the
 inter-verse tags are structural, not having to do with titles, but with the
 proper structure of the document and need to be preserved.

 If anything the pre-verse div needs to be marked canonical=true.

I wondered about this, but what if there is a mix of canonical and
non-canonical content in here? Some filtering still needs to be done inside
the div, I think.




 Just another thing I noticed with testing - in Matthew 8:13, the red letter
 text spans to the end of the verse when it shouldn't. (this seems to be true
 with the non-beta version as well). I presume this is a localized problem...


 I don't think this is a bug in the module, but in the SWORD engine. It also
 happens whenever there are two WoC (Words of Christ) in one verse. This is
 not a new problem.

I thought from looking that this was a problem in the OSIS markup in the
SWORD module. I can't check at the moment, though.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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 beta

[Ben Morgan]

It seems to work in BPBible, with one exception:
Currently pre-verse canonical headings are turned off by the osis headings
filter when headings are off. This is because it is looking at the canonical
attribute on the pre-verse div's tag, rather than title inside it.

I think the output of osis2mod is correct, and this is a 1.6.0 bug.

Just another thing I noticed with testing - in Matthew 8:13, the red letter
text spans to the end of the verse when it shouldn't. (this seems to be true
with the non-beta version as well). I presume this is a localized problem...

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Mon, Jun 1, 2009 at 9:13 AM, DM Smith dmsm...@crosswire.org wrote:


 On May 31, 2009, at 5:12 PM, Eeli Kaikkonen wrote:

  DM Smith wrote:

 I've put the KJV, built with the latest osis2mod, in beta mods. Please
 test it with 1.6.0 front-ends. Take a look at Psalm 3 and others with titles
 as that is using the new pre-verse div.


 What exactly it should put out? With BibleTime I see PSALM 3. and
 1 Lord, how are they increased that trouble me! many are they that rise
 up against me...


 It has a title (aka header). So try showing and hiding the header.

 If it shows up correctly, then it's good.

 The reason to test that is because we are representing titles differently.

 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] WLC 1.5 loses spacing?

[Ben Morgan]

Just to be clear: I don't think the WLC in beta will work completely
properly with any existing frontend, as I believe it uses alternate
versification. Until applications support this, the version not in beta will
be better.

God Bless,
Ben
---
Multitudes, multitudes,
in the valley of decision!
For the day of the LORD is near
in the valley of decision.

Giôên 3:14 (ESV)

On 25/05/2009, Teus Benschop teusjanne...@gmail.com wrote:

 I think that the morphology database is a commercial product. If such a
 module would ever become available for the Sword library, and it would
 be made available commercially, I would buy a few copies, one for each
 of our translators.

 Thanks for the hint about BibleTime, will try it out once BibleTime is
 packaged with libsword8 dependency.

 Teus.


 On Mon, 2009-05-25 at 13:32 +0200, Martin Gruner wrote:
  Hi Teus,
 
  BibleTime does show indicators for the segmentation, depending on the
 display style that is chosen (these are customizable to some extent).
 
  If the morph database is copyrighted, an encrypted module would have to
 be created for secure distribution. This could even be in the commercial
 interest of WHI.
 
  I would probably by this module.
 
  mg
 




 ___
 sword-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 problems

[Ben Morgan]

osis2mod doesn't handle comments - is this known/cared about?
osis2mod currently assumes that a div eID=... that appears outside a
verse, but inside a chapter is a chapter-closing div (presumably because
that is how commentaries close chapters). This breaks the pre-verse logic
when you have this type of thing (inside a chapter):
div type=section
 titleGenesis 1.1 title/title
 verse osisID=Gen.1.1 osisRef=Gen.1.1Verse 1 text/verse
/div
div type=section
 titleGenesis 1.2 title/title
 verse osisID=Gen.1.2 osisRef=Gen.1.2Verse 2 text/verse
/div

This should put Genesis1.2 title in Genesis 1:2. However, it currently puts
it at the end of Genesis 1:1 due to the closing div.

I have fixed two other problems today with osis2mod:
1) due to typo, the default storage was LZSS compression
2) pre-verse material which was handled was not matching the sID with the
eID

I wonder if we need to release some of the important utilities at different
times from the engine. (i.e. have a osis2mod release once problems are fixed
with it)

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] osis2mod problems

[Ben Morgan]

 On Mon, May 18, 2009 at 3:15 PM, Jonathan Marsden jmars...@fastmail.fmwrote:

 Ben Morgan wrote:

  I wonder if we need to release some of the important utilities at
  different times from the engine. (i.e. have a osis2mod release once
  problems are fixed with it)

 To me, this suggests more the need for (more and better?) automated
 tests of the utilities, rather than a different release schedule for
 them?  As you fixed the issues you found, did you add to the test suite
 regression tests for them?  If not, is there something in the overall
 testing structure that makes that difficult or impractical to do?

I didn't add regression tests... I'm not sure how workable they are. (though
they would probably be a good idea)
There are two ways you could attack the problem:
Either you store input and expected output for lots of different test cases
- but a reasonable component of these will be binary and as such not really
allow easy comparing.
The other option would be to generate a lot of modules and then fetch verses
from them, I suppose.
It would mean that every time you changed the output (this happened with
more than one thing in 1.6.0), you would have to change potentially a large
number of expected outputs.


 If we are now to enjoy rapid (every month or two?) 1.6.x update
 releases, then I'm not sure there would be much benefit to doing utility
 releases in between those, would there?  And you'd need a different
 version numbering scheme, and a separate source tarball...


 I'd rather we just aim for more frequent SWORD releases :)

These are (as far as I can see) critical issues and need (relatively)
immediate fixing.
People have complained before about being expected to run SVN osis2mod to
get the latest version...

In some ways osis2mod changes are important to be released quickly.
Since most osis2mod changes probably don't require a new engine version, we
are supporting a range of previous versions (though this isn't true in
1.6.0). If we have improved osis2mod support, we should release it ASAP to
stop bad module creation happening - there are few things worse than having
badly formatted modules around.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] osis2mod problems

[Ben Morgan]

On Mon, May 18, 2009 at 3:35 PM, Jonathan Marsden jmars...@fastmail.fmwrote:

 Ben Morgan wrote:

  I didn't add regression tests... I'm not sure how workable they are.
 (though
  they would probably be a good idea)

 Can't we do osis2mod and then mod2osis (or even mod2imp) and
 store/compare that output, so that the comparison is of text?  Or is
 there some reason why that can't work?

Not really, I don't think. The round-trip may be somewhat important, but it
is the bit in the middle that *really* needs testing. You can easily have it
survive the round-trip but be wrong in the middle.



 Given the number of module creation tool issues there seem to be, having
 some automated testing for the utilities seems worth at least some kind
 of attempt.  If in a few months we learn that it didn't really help...
 well, OK, at least we tried :)

 Well, yes. It probably is a good idea, if this is the way that people are
meant to import.


  These are (as far as I can see) critical issues and need (relatively)
  immediate fixing. ...

  In some ways osis2mod changes are important to be released quickly.

 In that case, IMO we have to declare these bugs as being important, and
 therefore we need for a very immediate SWORD 1.6.1 release to fix these
 issues!  Maybe you could request a 1.6.1rc1 right away, and then if that
 works well for testers for a week or so, we can release 1.6.1 ?

This is part of why it makes sense for utilities to be released separately.
The problem here isn't in the engine, so it doesn't necessarily make too
much sense to have a release of the engine...
However, I guess users expect the latest versions of the utilities in the
latest version of the library - I guess this is more of an issue for future
consideration...

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Autotools Bug?

[Ben Morgan]

On Tue, May 12, 2009 at 1:13 PM, Jonathan Marsden jmars...@fastmail.fmwrote:


 Probably.  Proprietary development environments like this are just not
 often seen as critical targets for open source tools, I would think.


 Especially when it's not really clear what the benefits of MSVC and
 Borland over gcc would be at the end of the day... will the resulting
 app work differently?  Better?  Faster?  Or is this just a matter of
 personal choice for the developer?

MSVC is (I believe) faster, produces smaller and faster executables, etc.
BPBible sword bindings are compiled with MSVC.

Additionally, MSYS and (I believe) Cygwin are horrible environments to try
to use... (I haven't used Cygwin, but I have used MSYS)

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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.6.x Localization (Ps 151)

[Ben Morgan]

 It still seems clear, to me, that there are a large number of
 technical difficulties as we climb outward in our search to support
 everyone's canon.  I'm guessing a mapping mechanism will have to wait
 until we have determined our full support extent and, even then, will
 be non-trivial to support verses which are partially broken up in some
 versions but not others and versions which include in their print
 multiple versifications.

Of course there are technical difficulties if we seek to copy the printed
text exactly - but this should not delay a mapping mechanism.
A mapping mechanism is, I believe, more important than trying to support
more complicated v11n's with reordering, inserted text, etc.
(I'm not saying that I don't want to see more complicated v11n's - but I
think they are a lower priority)

Mapping in the general case should be actually pretty easy mostly - provided
you have the data...

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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.6.x LOCALIZATION - Gaeilge (Irish)

[Ben Morgan]

Looks like it was in latin-1. A utf8 version is attached - this validates
for me

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Thu, May 7, 2009 at 9:20 AM, Troy A. Griffitts scr...@crosswire.orgwrote:

 Thanks John,

 I tried your locale, but it came back with a number of errors.  I presumed
 it was the wrong encoding so I ran it through:

 uconv -t UTF-8

 but uconv reported illegal characters, which usually means that it guessed
 the wrong source encoding.  So I really am not sure what to do with the
 file.  Anyone else have any ideas what encoding it is in?

-Troy.



 johndu...@cgcf.net wrote:

 Troy,

 I've not got set up with all the utilities etc for Sword yet, but plan to
 do
 so shortly.

 In the meantime, I thought that I would try to provide the Irish
 localisation texts of the Bible names.  I've put together a conf file
 (attached) along the lines suggested, but it is untested.  If you have
 time,
 can you please check it to see if it is OK, as I can't check it yet? (I
 expect it to be OK, but then again no-one ever expects bugs!).  I believe
 that it is UTF8 generated in jEdit, but I don't know how to check this.

 There are only 73 books in the Irish Bible, but I've put included the
 English names of the other books in case they just need to be there for
 the
 file to work.

 Let me know if there is anything else I need to change/do for this
 localisation.

 Thanks
  John Duffy

 -Original Message-
 --

 Message: 1
 Date: Tue, 05 May 2009 13:58:48 -0700
 From: Troy A. Griffitts scr...@crosswire.org
 Subject: [sword-devel] SWORD 1.6.x LOCALIZATION HELP WANTED
 To: SWORD Developers' Collaboration Forum sword-devel@crosswire.org
 Message-ID: 4a00a888.4080...@crosswire.org
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 Hope the ALL CAPS gets through your spam filters.

 Now that we're on the brink of releasing the 1.6.x branch publicly, and
 we've nailed down the v11n systems to include, we could really use help
 updating the locale files to include information to take advantage of the
 new alternate versification (av11n) feature.

 1.6.x uses a new locale format which replaces the old system of using book
 numbers with OSIS book names.

 Work to convert the existing locales has already taken place and is
 included
 in the 1.6.0RC3 package.


 What is NOT included are translations and abbreviations of the new book
 names from the new versification systems we are releasing in 1.6.0. This
 means that these books will appear in English until translations are
 provided.


 I've updated the locale template which is included in our source tree at:

 http://crosswire.org/svn/sword/trunk/doc/translation-template.conf

 Included is an #Apocr comment which separates the old book names above it,
 from the new book names below.  Also included is a new updated and expanded
 commentary on how to tune your locale abbreviations to better parse input
 from users.


 The existing locales can be seen in SVN here:

 http://crosswire.org/svn/sword/trunk/locales.d/


 Please submit any updated locales, and be sure to try them first with:

 sword/tests/parsekey jn1.1 your_locale_abbrev

 to be sure the sanity check tests pass.

 If you get them in to me soon, they might even get bundled in 1.6.0!


 Thank you for making SWORD usable by so many people groups!


-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



ga-utf8.conf
Description: Binary data
___
sword-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] Chinese transliteration with strong's numbers

[Ben Morgan]

Module: ChiUns 2.1
Transliteration: Latin
ICU 3.4.1

diatheke -t latin -b ChiUns -f osis -k 1 Sam 1:5
I Samuel 1:5: w  savlm=x-Strongs: H05414gěi /w w savlm=x-Strongs:
H02584hā ná /w w savlm=x-Strongs: H04490|x-Strongs: H0639|x-Strongs:
H0259de què shì shuāng fēn /w w  savlm=x-Strongs: H0157, yīn wèi tā
ài /w w savlm=x-Strongs: H02584hā ná /w divineNamew
savlm=x-Strongs: H03068. wú nài yé hé huá /w/divineName w
savlm=x-Strongs: H07358|x-Strongs: H05462bù shǐ hā ná shēng yù /w
.milestone type=line/

Two problems here in this particular w (this is not isolated to this one,
either):
w savlm=x-Strongs: H04490|x-Strongs: H0639|x-Strongs: H0259de què shì
shuāng fēn /w
1. it uses | to separate, rather than a space. This needs to be fixed in the
module.
2. the transliterator has introduced spaces after the x-Strongs:, which
breaks it badly. This needs to be fixed in the transliterator. (Note: it
looks like ICU 4 may not have some of these problems)

This causes problems in both BPBible and Xiphos - and I expect all
frontends.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] ESV linegroups not processed in osishtmlhref

[Ben Morgan]

The ESV has linegroups of the style lg sID=... and lg eID=..., but
these aren't picked up by osishtmlhref.
It has a rule to change lg and /lg into br /, but none for lg's with
attributes.
This would be reasonably simple to add - just another case in the token
handling (rather than relying on token substitution).

A while ago, Daniel Owens and I were talking about the use of linegroups in
VietNVB. Daniel had removed the linegroups as they caused a new line to
appear after the versenumber in (I think) Xiphos - and he noticed this
didn't happen with the ESV's linegroups. I now wonder whether this was
because the ESV didn't output the br / at the start of line groups, due to
the sID and eID elements. If so, perhaps br / shouldn't be output? (BTW,
linegroups are important to retain intact, so I don't want them to be
eliminated from the module...)

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] Building problem on Ubuntu 9.04

[Ben Morgan]

Have you run autogen.sh recently?

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Wed, Apr 29, 2009 at 3:54 PM, Peter von Kaehne ref...@gmx.net wrote:

 /home/peter/Downloads/Crosswire/sword/lib/../src/mgr/installmgr.cpp:92:
 undefined reference to `sword::CURLHTTPTransport::CURLHTTPTransport(char
 const*, sword::StatusReporter*)'
 collect2: ld returned 1 exit status
 make[2]: *** [installmgr] Error 1


 libcurl-dev is installed. Configure describes it being present and found.

 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] Autonormalize and av11n

[Ben Morgan]

This is brought to mind by the recent discussions of how many verses in
certain chapters. If there is not mapping, it is important that you can feed
similar verse references in and get something out of it. It may not be
right, but it should be close.

If a user types in 3 John 15, if the versification doesn't have this verse,
it makes most sense to send them to 3 John 14 (rather than to Jude 1). This
can be accomplished by setting autonormalize off and clipping to bounds.

If a user, however, types Malachi 4 into a leningrad locale, they will end
up in 1 Chronicles 1. However, turning Autonormalize off doesn't help (much)
here; we get the curious range returned: Malachi 4:1-I Chronicles 1:54
Optimally, it would bind this to somewhere in Malachi 3 (perhaps the last
verse?)

I can see no easy way forward here, due to the way things work. The
UpperBound of a range will/has to be autonormalized so that it can find the
maximum verse - so unless versekeys are changed to store a chapter (or book)
as a whole rather than binding the values immediately, this can't really
work...

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Release-critical TODO items

[Ben Morgan]

On Mon, Apr 27, 2009 at 2:39 PM, Jonathan Marsden jmars...@fastmail.fmwrote:


 3) SWIG issues and related segfaults (Ben)


This came with r2313, and I'm at a loss how to deal with it...
Python program (this worked r2312, crashes r2313):
import Sword
Sword.VerseKey()

valgrind gives this (as well as others, but this is the first)
==10943== Invalid write of size 1
==10943==at 0x48A26D1: sword::VerseKey::init() (versekey.cpp:62)
==10943==by 0x48A7F13: sword::VerseKey::VerseKey(char const*)
(versekey.cpp:103)
==10943==by 0x4818B18: _wrap_new_VerseKey (Sword.cxx:7023)
==10943==by 0x407E65C: PyCFunction_Call (methodobject.c:108)
==10943==by 0x4048846: PyObject_Call (abstract.c:1861)
==10943==by 0x40CA8D2: PyEval_EvalFrameEx (ceval.c:3853)
==10943==by 0x40CDBD1: PyEval_EvalCodeEx (ceval.c:2836)
==10943==by 0x406A7A9: function_call (funcobject.c:517)
==10943==by 0x4048846: PyObject_Call (abstract.c:1861)
==10943==by 0x40500D4: instancemethod_call (classobject.c:2519)
==10943==by 0x4048846: PyObject_Call (abstract.c:1861)
==10943==by 0x40940DD: slot_tp_init (typeobject.c:4943)
==10943==  Address 0x45B55D4 is not stack'd, malloc'd or (recently) free'd
==10943==

gdb gives a stack trace of:
0x00b86050 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0x00b86050 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
#1  0x00569706 in std::_Rb_tree_iteratorstd::pairsword::SWBuf const,
sword::SWLocale* ::operator++ (this=0xbfe04c28)
at
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:190
#2  0x0056798b in sword::LocaleMgr::deleteLocales (this=0x81de948)
at ../src/mgr/localemgr.cpp:193
#3  0x00567a67 in ~LocaleMgr (this=0x81de948) at
../src/mgr/localemgr.cpp:138
#4  0x00568c34 in ~__staticsystemLocaleMgr (this=0x62abe0)
at ../src/mgr/localemgr.cpp:47
#5  0x005674c8 in __tcf_0 () at ../src/mgr/localemgr.cpp:48
#6  0x0095e9d9 in exit () from /lib/libc.so.6
#7  0x00948df4 in __libc_start_main () from /lib/libc.so.6
#8  0x080484a1 in _start ()

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Release-critical TODO items

[Ben Morgan]

Sorry, I found the problem.
SWIG was being defined while building, so it was ommitting a part of the
versekey definition. Sorry about that.

It needs a #ifndef SWIG around that mutable inline struct in versekey.h as
SWIG can't understand this.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)



On Mon, Apr 27, 2009 at 5:04 PM, Troy A. Griffitts scr...@crosswire.orgwrote:

 Ben,

 I know you realize this, but we're at 2349 now.  I realize the revision
 you're giving is the first revision you see the troubles, but I just want to
 make sure you're seeing the troubles with 2349.  I just ran valgrind against
 a basic test that instantiates a few VerseKey objects and didn't see any
 troubles.  I ran through valgrind and it was clean.

 Could you try for me to do a:

 make distclean
 ./autogen.sh
 ./usrinst.sh
 make
 sudo make install

 and then try your test again?

 I wish I had some info, but my tests don't fail here.  Keep me posted with
 what you find.

-Troy.



 Ben Morgan wrote:

 On Mon, Apr 27, 2009 at 2:39 PM, Jonathan Marsden 
 jmars...@fastmail.fmmailto:
 jmars...@fastmail.fm wrote:


3) SWIG issues and related segfaults (Ben)


 This came with r2313, and I'm at a loss how to deal with it...
 Python program (this worked r2312, crashes r2313):
 import Sword
 Sword.VerseKey()

 valgrind gives this (as well as others, but this is the first)
 ==10943== Invalid write of size 1
 ==10943==at 0x48A26D1: sword::VerseKey::init() (versekey.cpp:62)
 ==10943==by 0x48A7F13: sword::VerseKey::VerseKey(char const*)
 (versekey.cpp:103)
 ==10943==by 0x4818B18: _wrap_new_VerseKey (Sword.cxx:7023)
 ==10943==by 0x407E65C: PyCFunction_Call (methodobject.c:108)
 ==10943==by 0x4048846: PyObject_Call (abstract.c:1861)
 ==10943==by 0x40CA8D2: PyEval_EvalFrameEx (ceval.c:3853)
 ==10943==by 0x40CDBD1: PyEval_EvalCodeEx (ceval.c:2836)
 ==10943==by 0x406A7A9: function_call (funcobject.c:517)
 ==10943==by 0x4048846: PyObject_Call (abstract.c:1861)
 ==10943==by 0x40500D4: instancemethod_call (classobject.c:2519)
 ==10943==by 0x4048846: PyObject_Call (abstract.c:1861)
 ==10943==by 0x40940DD: slot_tp_init (typeobject.c:4943)
 ==10943==  Address 0x45B55D4 is not stack'd, malloc'd or (recently) free'd
 ==10943==

 gdb gives a stack trace of:
 0x00b86050 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
 (gdb) bt
 #0  0x00b86050 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6
 #1  0x00569706 in std::_Rb_tree_iteratorstd::pairsword::SWBuf const,
 sword::SWLocale* ::operator++ (this=0xbfe04c28)
at
 /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:190
 #2  0x0056798b in sword::LocaleMgr::deleteLocales (this=0x81de948)
at ../src/mgr/localemgr.cpp:193
 #3  0x00567a67 in ~LocaleMgr (this=0x81de948) at
 ../src/mgr/localemgr.cpp:138
 #4  0x00568c34 in ~__staticsystemLocaleMgr (this=0x62abe0)
at ../src/mgr/localemgr.cpp:47
 #5  0x005674c8 in __tcf_0 () at ../src/mgr/localemgr.cpp:48
 #6  0x0095e9d9 in exit () from /lib/libc.so.6
 #7  0x00948df4 in __libc_start_main () from /lib/libc.so.6
 #8  0x080484a1 in _start ()

 God Bless,
 Ben

 ---
 Multitudes, multitudes,
   in the valley of decision!
 For the day of the LORD is near
   in the valley of decision.

 Giôên 3:14 (ESV)


 

 ___
 sword-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] Nearness to release

[Ben Morgan]

On Mon, Apr 27, 2009 at 12:50 PM, Troy A. Griffitts scr...@crosswire.orgwrote:

 Jonathan Marsden wrote:

 Troy A. Griffitts wrote:
 Good :)

 Is there is list of all known release-critical bugs and TODO items
 somewhere?


 No, the bugtracker is clean now for critical 1.6.x changes, as far as I
 know (right?).  We're only fixing feedback we get on the RCs now.

 The only outstanding issue of which I know is the link bug DM is working on
 with osis2mod, but I'm about to tell him that he probably needs to check the
 ordinal count of his returned ListKey in a different manner in our osis2mod
 utility, so this probably won't be an API change.  I think we're just
 waiting now to bundle locales and v11n systems.  No code changes unless
 someone speaks up about something I've overlooked again.

At the moment, current SVN:
1) won't compile with SWIG (versekey changes - I have a patch for these)
2) Breaks disastrously with SWIG once compiled - segfaulting in lots of
places... (e.g. this code dies in localemgr destructor:
import Sword
Sword.VerseKey()
)

I'm trying to track the second one down, but it seems to only occur in the
bindings...


  There have now been several commits since 1.6.0RC2... (I'd
 say exactly now many, but it wasn't tagged... :)


 scr...@scribe-laptop:~/src/sword-1.6.0RC2$ svn log -r {`ls -l
 configure|cut -f6 -d' '`}:HEAD http://crosswire.org/svn/sword/trunk

 :)


  is it perhaps time for an RC3 and a freeze on all non-essential changes
 until we can get a
 final 1.6 out the door??


 Yeah, I'd say so.  I'm about to head out to evening service at Church since
 I slept in this morning :) and when I get back, if no one has complained, we
 can bundle an RC3 and hopefully go out the door soon.  I don't consider
 locale or v11n data changes warrant for a new RC, so if we only get those
 changes over the next couple days, let's shoot to release a final on Tuesday
 evening PST.

  (Creating a branch for the 1.6.0 release, so that new commits intended
 for 1.6.1 could continue on svn head, would also work well, but that
 doesn't seem to be the SWORD way of doing things).


 :)  Again, this release has undergone a little more testing than usual as
 we're hoping to 'change our ways' with this BRANCH and force ourselves to
 not do API changes in 1.6.x.



 My plan is to continue to work on 1.6.x for a while (months), improving
 speed, filters, and fixing any bugs, and actually USE 1.6.x in some of my
 own apps for a while before starting any API-changing additional features
 which will require a branch of HEAD to 1.6.x, and 1.7.x to continue in HEAD
 at that point.  I don't want to have to branch until we necessarily start
 1.7.x API-breaking changes; otherwise we have to keep merging 1.6.x changes
 into HEAD, which would make the lines identical till we start 1.7.x work
 anyway.  Though we will definitely TAG 1.6.0 (which is the same as a branch
 anyway in svn-- if we need to change our minds for some odd reason).

How long does that delay mapping between versifications?  I think this is
relatively important to have - especially if modules start being re-released
with av11n - which I would strongly discourage at the moment, seeing as no
frontend yet supports them.

God Bless,
Ben
---
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
___
sword-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] abbreviations.sh (was: Re: linking / testsuite )

[Ben Morgan]

On Thu, Apr 23, 2009 at 3:42 PM, Jonathan Marsden jmars...@fastmail.fmwrote:

 Earlier, in response to Ben, I wrote:

  If I have time later tonight, once I have a sword 1.6.0RC2 package out
  for front end developers to test with, I'll see about creating the 198
  item single locale test and (if I succeed!) I'll contribute it to the
  SWORD codebase, just to demonstrate that creating such a test really is
  in fact doable :)

 Here is abbreviations.sh.  I got an initial set of abbreviations from
 the OSIS User Manual, by cut and paste, and then added (usually) two
 more per book, that I just made up.


 In the process of creating and testing it under 1.6.0RC2 I found a
 surprises.  It may really be a bug, demonstrating to Ben and the team
 the value of this kind of very simple regression test script... or it
 may just reflect my lack of understanding of the intent and workings of
 the SWORD library.



 parsekey 1Ki   does not display I Kings, but I Samuel.  Likewise for 2Ki
 and II Samuel.  Similar behavior is seen for 1Kin, 2Kin, 1King and
 2King.  Intuitively, this feels incorrect to me.  As some mild degree of
 justification for this, I offer:

  http://www.biblegateway.com/passage/?search=1Ki

 which does what I would expect -- it displays I Kings.

This is another problem from adding additional ones and needs to be fixed
(specifically,  1 Kingdoms = 1 Samuel). My testing script was only checking
against new books, so it didn't pick this up...


 (A test tool that compares the results of lookups on biblegateway.com
 and using SWORD might be an interesting thing for someone to create, BTW!).

 Observations: There are more abbreviations which I would like to work,
 but which don't seem to, such as Gn for Genesis, SoS for Song of
 Solomon, but I have no real idea if these are legitimate
 abbreviations.  I do not claim to be a domain expert on abbreviations :)
  I am fairly confident that 1Ki *is* an abbreviation for I Kings that I
 have seen and used before, not just on biblegateway.com.

It seems lots of custom ones were dropped during the transition that used to
be there. BPBible has its own english conf file (
http://code.google.com/p/bpbible/source/browse/trunk/locales/locales.d/SWORD_1512/bpbible.conf),
so many of the problems others have seen in other frontends do not apply to
it. I C (and II C) is another error case which should be handled, but
this one looks a little more complicated as the data clearly points it to 1
Corinthians - but it never gets there...

Here is the (very simple!) script.  I've assigned copyright to
 CrossWire.  It's a trivial for loop plus a list of abbreviations.  I can
  create a Jira item for it, and attach the script and a .good file for
 it, if that would be preferred.

Another thing that could be done is to create all possible abbreviations
from the abbreviations file... Anyway, this is a good addition. You have Ez
for Ezekiel and Ezra (but currently it is Ezekiel) and Ze for Zephaniah and
Zechariah (currently Zechariah). Also Phi for Philemon - it goes to
Philippians currently. I've added these to verseparsing.sh with the
conflicting ones removed. It doesn't pass currently, due to the kings
problem.

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