Open GoogleCodeExporter opened 9 years ago
I think this feature is very important. It is not so easy to choose THE right
format,
because there are several with different translations.
OpenSong and SongBeamer can import the Zefania-XML format which is on
Sourceforge
(http://sourceforge.net/projects/zefania-sharp/) but it seems that this format
is not
actively supported. (In my opinion one of the main problems with christian
software
is maintaining it...). I think the XML specifications are open, but I wouldn't
call
this a standard. Rather an ad hoc standard (not develped in collaboration with
many
organizations...).
And there is also E-Sword (http://www.e-sword.net) with a lot of modules. But I
don't
know anything about the e-sword format. I don't think it is open.
From all of them I would prefer the SWORD project, because they implement open
standards like Open Scriptural Information Standard (OSIS,
http://www.bibletechnologies.net/), Theological Markup Language (ThML,
http://www.ccel.org/ThML/), Text Encoding Initiative (TEI,
http://www.tei-c.org/release/doc/tei-p4-doc/html/DI.html) and General Bible
Format
(GBF, http://www.ebible.org/bible/gbf.htm) which are all XML formats except of
GBF.
Original comment by Siegwar...@gmail.com
on 29 Feb 2008 at 10:59
I did see the zefania format, but it said the project was inactive, so I'm
hesitant
to use it.
I like the sword project, because it has multiple versions already. It would
keep the
ExpoSong installer small since we can just allow the user to download the
individual
modules from the Sword Project's website. It would be good to have ExpoSong
install
the module files though.
Original comment by bradleelandis
on 29 Feb 2008 at 11:29
OpenSong actually has bible translations available, and they are in a really
good xml
format. We could allow the user to download these manually so that we don't
have to
worry about copyright stuff. The format helps keep the size of the file down
with one
letter xml entities (b=book, c=chapter, v=verse). They may be in zefania
format, I'm
not sure, but it's the only place I've found so many bibles that are free of
charge.
Original comment by bradleelandis
on 14 Jul 2008 at 8:24
I ran some tests on loading the xml files from OpenSong, and it actually took
about
from 2.7 to 5 seconds to load the xml file into DOM, and uses quite a large
amount of
space in memory (90 MB estimated for a simple python script that loads a 4MB
file).
This might be acceptable, as the user will be expected to have a fast computer
with
plenty of memory, we'll just have to be able to access it quickly.
I'll have to try it out using SAX to see if that's an option, but I think DOM
will be
better because you can load it at the beginning and not worry about it again.
Original comment by bradleelandis
on 22 Oct 2008 at 3:30
This should be added as a feature within 2 releases.
Original comment by bradleelandis
on 6 Nov 2008 at 12:08
Original comment by bradleelandis
on 7 Oct 2009 at 4:08
Original comment by s.mehrbrodt
on 13 Mar 2010 at 9:55
Bible verses is the one thing lacking for 1.0, and schedule area depends on it,
so I'm moving these to be on the list for 1.0.
Original comment by bradleelandis
on 25 Jan 2011 at 5:04
Original comment by bradleelandis
on 27 Jan 2011 at 8:36
Original comment by bradleelandis
on 27 May 2011 at 6:30
One of our users would like to see us use the Sword modules with libsword
http://groups.google.com/group/exposong/browse_thread/thread/2918bb21c3f0b71e
We need to evaluate performance of different options (4 million characters in
the Bible), so our memory usage is going to increase greatly if we have to load
the full Bible into memory, and even more for multiple versions.
I think Zefania and Sword have the same free modules, but I'm not sure about
buying versions.
Original comment by bradleelandis
on 8 Nov 2011 at 3:24
Wondering if the small utility called "diatheke" could be used (at least on
Linux) to call-up Bible verses, chapters, even whole books into ExpoSong
without actually loading an entire Bible into memory. The SWORD modules are
pretty extensive in their versions (ASV, KJV, BBE, YLT, etc), they are all
free, and from what I understand diatheke is really designed for this sort of
thing. I believe diatheke is used for just this purpose to load Bibles into
Lyricue.
Original comment by ad...@computers4christians.org
on 17 Nov 2011 at 3:18
@admin@computers4christians.org, unless it's written in Python, it would
probably be better to write our own, unless it's a package that is built into
Linux distributions.
This site has a Python module for reading sword modules:
https://github.com/kcarnold/pysword . I need to test it out.
Original comment by bradleelandis
on 28 Dec 2011 at 11:58
I've imported kcarnold's pysword library above to lib/es_pysword/. I created
test.py to figure out how we need to get it to work in ExpoSong. The verses are
in XML, so I plan on removing the tags, and any <note>s that are in the verse.
Right now, I am just unzipping sword modules in data/sword/.
Original comment by bradleelandis
on 30 Dec 2011 at 5:21
Original comment by bradleelandis
on 31 Dec 2011 at 1:14
I've done about as much performance improvements to the module that I can, but
with a decent computer, it takes about 15 seconds just to load Genesis. There
are a couple of options I see that we could do (from worst to best).
* Load the books at the beginning, making initialization time more than 4 minutes.
* Load the books as presentations, but don't actually load any verses unless the user clicks the book, causing some delay for loading.
* Load the books as presentations, and provide another list below preslist for chapters that would only show when the Bible presentation types is selected. The user would click the book, then the chapter, and would only have to load a chapter at a time, taking 7 seconds or so.
The pysword module has to unzip each verse. If the modules were uncompressed,
it might work a little faster. We could provide an import dialog to extract the
text.
Maybe Zefania would be better, but I can't even find the spec for the format,
and I'd hate to use a format from a project that will probably never be
maintained again.
Original comment by bradleelandis
on 13 Jan 2012 at 5:45
Original issue reported on code.google.com by
bradleelandis
on 28 Feb 2008 at 11:53