[sword-devel] Re: Christian Distro
edb_fpcc at comcast.net
edb_fpcc at comcast.net
Tue Apr 5 12:11:55 MST 2005
Hello, everyone!
I see I need to clarify some of my comments...
> > a text editor (I prefer
> > nano over zile, easier for a newbie to use, but it doesn't matter THAT much -
> > most newbies don't do console editing anyway).
>
> It would be wise to leave vi as editor in. (It is the default unix editor
> and nerds like me will not be able to edit tekst files without it if we
> need to assist one of our brothers or sisters.)
What I meant was I didn't care WHICH text editor was left in, just as long as we had at least one included. My personal preference for a text editor is nano, but I can use vi in a pinch. Vi isn't that large, so there's no problem with a couple of text editors.
My POINT behind all of this, however, is that if we're going to use IchthuX as an OUTREACH TOOL to people who do not yet know Jesus nor Linux, it would be best to SIMPLIFY as much as is possible.
When sharing the Gospel, does Billy Graham start off with words like "Propitiation" or "Substitutionary Atonement"? No, he doesn't. He describes those CONCEPTS, but in terms that the pre-Christian can easily grasp.
I think this same concept should be applied to an evangelistic distro - it's not just about compiling a bunch of Christian Debian packages, but how we PRESENT them to the user that is going to make a huge difference. :D Let's go ahead and make sure that there are some powerful tools under the hood... but we don't need to spend extra time explaining what "zile" or "nano" is to the average end-user. I'd even venture to say that the average end-user won't even CARE that there are CLI text editors... so there's no need to point them out specifically.
Which brings me to my next thoughts about how the distro should be organized...
> > The entire KDE menu structure is WAY too complicated. It should be streamlined
> > down to just a few menu entries, with organized submenus. I know this is
> > possible, because the Multimedia menu is subdivided into Sound, Video, and
> > Viewers. This is excellent - let's continue this all the way through and
> > SIMPLIFY.
>
> Sub menu's are NOT simplifying in my book. It means more work to navigate
> and more room for errors. (When they exposed me to windows XP I was
> seriously annoyed to find this kind of RSI inflicting sub-sub-sub-sub
> menu's becoming the standard.)
Ah, but you've hit upon the point exactly. The sub-menu IS the standard. It's certainly the standard that the non-Linux user is used to seeing. This brings us back to the purpose of IchthuX - EVANGELISM... both of the gospel of Jesus Christ and of the freedom of Open Source.
When sharing the Gospel with a pre-Christian, it is most wise to communicate to them AT THEIR LEVEL. Understanding is CRUCIAL. Without understand, life-change cannot happen - they cannot follow Jesus if they can't understand that HE is the one we're talking about, and they can't be set free from inferior proprietary systems if they see the alternative as something so completely over-their-head that it is unusable.
I have done a number of comptuer "conversions", and without exception, each one has been dependant upon the end-user UNDERSTANDING how to use their own system.
> > 2) During the HD install, the script has LILO as the default, but LILO is not
> > nearly as flexible/recoverable as GRUB. Any chance we could switch the two?
>
> This would require some serious work. But if anyone can do it it would be
> wise as lilo is bound to tempt people to use the Lords name in an entirely
> ill manner.
Hah! that is the PERFECT justification to use GRUB!! :D (I feel much the same way about LILO...)
Grace and peace to you all - PastorEd
> Send sword-devel mailing list submissions to
> sword-devel at crosswire.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.crosswire.org/mailman/listinfo/sword-devel
> or, via email, send a message with subject or body 'help' to
> sword-devel-request at crosswire.org
>
> You can reach the person managing the list at
> sword-devel-owner at crosswire.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sword-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Re: Christian Debian distro talk / Report (Hugo van der Kooij)
> 2. Re: 1 bug left for 1.5.8 (Chris Little)
> 3. Re: 1 bug left for 1.5.8 (Krzysztof Bialas)
> 4. Re: Re: Christian Debian distro talk / Report (JPKlingon at aol.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Apr 2005 08:28:54 +0200 (CEST)
> From: Hugo van der Kooij <hvdkooij at vanderkooij.org>
> Subject: Re: [sword-devel] Re: Christian Debian distro talk / Report
> To: "SWORD Developers' Collaboration Forum"
> <sword-devel at crosswire.org>
> Message-ID:
> <Pine.LNX.4.58.0504050812120.4307 at gandalf.hugo.vanderkooij.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Mon, 4 Apr 2005, Pastor Ed B. wrote:
>
> > 1) there are a LOT of extra packages from Knoppix in IchthuX that just don't
> > really need to be there to meet our stated outreach goals. Looking at the
> > overloaded KDE menu just makes me feel bloated.
> >
> > Can we *please* get rid of the development packages, the unnecessary editors
> > (5 editors? how about just down to Kedit, Kate, and a text editor (I prefer
> > nano over zile, easier for a newbie to use, but it doesn't matter THAT much -
> > most newbies don't do console editing anyway).
>
> It would be wise to leave vi as editor in. (It is the default unix editor
> and nerds like me will not be able to edit tekst files without it if we
> need to assist one of our brothers or sisters.)
>
> > 2) During the HD install, the script has LILO as the default, but LILO is not
> > nearly as flexible/recoverable as GRUB. Any chance we could switch the two?
>
> This would require some serious work. But if anyone can do it it would be
> wise as lilo is bound to tempt people to use the Lords name in an entirely
> ill manner.
>
> > 3) Since this is going to be an OUTREACH tool that will be given to people who
> > are unfamiliar with Linux, we should probably spend some time naming things
> > so that non-Linux users won't get overly confused. For example:
> >
> > In the KDE menu, what does KNOPPIX mean? Since I'm a fairly experienced Linux
> > user, I know right away what it means. But what if we give this disk to
> > someone who has never even SEEN Linux, let alone the KNOPPIX distro. It will
> > just confuse them.
>
> And how confusing will it be if any who knows linux tries to help? They
> will never be able to make their way through it. And will other names
> really help? (I must admit I even have to translate all Dutch computer
> terms to English before they start to make sense if someone needs
> assistance.)
>
> > The entire KDE menu structure is WAY too complicated. It should be streamlined
> > down to just a few menu entries, with organized submenus. I know this is
> > possible, because the Multimedia menu is subdivided into Sound, Video, and
> > Viewers. This is excellent - let's continue this all the way through and
> > SIMPLIFY.
>
> Sub menu's are NOT simplifying in my book. It means more work to navigate
> and more room for errors. (When they exposed me to windows XP I was
> seriously annoyed to find this kind of RSI inflicting sub-sub-sub-sub
> menu's becoming the standard.)
>
> Remove the parts you do not need but do not start to complicate a system
> with loads of menu's.
>
> Hugo.
>
> --
> I hate duplicates. Just reply to the relevant mailinglist.
> hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/
> Don't meddle in the affairs of magicians,
> for they are subtle and quick to anger.
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 05 Apr 2005 01:17:39 -0700
> From: Chris Little <chrislit at crosswire.org>
> Subject: Re: [sword-devel] 1 bug left for 1.5.8
> To: "SWORD Developers' Collaboration Forum"
> <sword-devel at crosswire.org>
> Message-ID: <425249A3.3010400 at crosswire.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Okay, I've taken a look at the test.osis.xml file Christopher posted in
> the bug tracker and found the following. This is based on a module
> compiled with osis2mod (from SVN) and the same module inspected in
> BibleCS 1.5.8pre3, as well as the module exported with mod2osis &
> mod2imp (from SVN).
>
> (Quoting from Matthew chapter 1 in the document test file:)
> > This is a test file to show off the problems encountered with Sword
> > OSIS2Mod and Sword for windows rendering. In the examples below I've
> > used '[' and ']' in the place of '<' and '>'
> > This file was written using XMLSpy and validated successfully against
> > osisCore.2.0.1.xsd
>
> Just to confirm, it also validates in oXygen.
>
> > This file is split up into several chapters each showing a different
> > behaviour. The contents of each chapter is described below:
> > 0) Introduction test:
> > chapter 0: introduction which contains multiple parapgraphs is not
> > rendered properly (some RTF rubbish)
>
> Works/renders fine in 1.5.8pre3. Maybe the problem has already been
> corrected.
>
> > 1) Paragraph tests: additionally chapterTitle in chapters 2-4 is just
> > ignored...
>
> The chapterTitle attribute on <chapter> elements is preserved by
> osis2mod, but ignored by the engine. I have no idea what this attribute
> is for, but would guess it is something we forgot to remove when we
> changed how titles are done. In any case, the correct way to encode all
> titles that occur in the text would be with <title>.
>
> > chapter 2: paragraph markers outside of verse tags (paragraphs enclose
> > verse tags) - resulting a complete mess in Sword for Windows RTF
>
> It's unattractive but not RTF gibberish, so I suspect this has already
> been fixed.
>
> > chapter 3: paragraph markers inside verses, with construct like this:
> > [verse s][p]text[/p][p][verse e][verse s]text[/p][p][verse e]. This is
> > the workaround for problems introduced in chapter 2.
> > chapter 4: paragraph markers completelly embeded into verses - all [p]
> > and [/p] markers are inside the verse tags. Also considered by me as a
> > woraround to problems in chapter 2
>
> Workarounds are bad.
>
> > 2) notes/xrefs problems:
> > chapter 5: xrefs crossing paragraph boundaries
>
> This is also just the problem above that was fixed.
>
> > 3) problems with div's and titles
> > chapter 6: div and title ignored if placed before the chapter start
> > tag
>
> This is correct, but where should content between two chapters go?
> Should it go in the introduction to the following chapter?
>
> > chapter 7: two separate divs and titles inside a chapter - possibly
> > missing newline after the div end tag
>
> This is just a criticism of rendering style, so not really a bug. And
> it's a criticism specific to BibleCS. Short answer: no, div should not
> generate paragraph breaks.
>
> Best practice OSIS requires a structure of:
> <div type="book"> with other div types embedded in that, notably <div
> type="section">. But the lowest level of the primary OSIS hierarchy is
> <p>. <p> should and does generate paragraph breaks. It never allows
> embedding of <div>s, so <p> should be the lowest level always. (This
> ignores simple Bibles without any paragraph structure, just
> book/chapter/verse.)
>
> > chapter 8 and 9: div spanning two chapters - almost ok
>
> Same issue as chapter 7.
>
> > chapter 10: div and title just after the chapter start tag - also
> > almost correct
>
> Same issue as chapter 7, also. But there is also a problem here with
> osis2mod. It's making two copies of <title> elements that occur before
> the first verse. (One in the chapter intro, one in the verse 1 preverse
> title.) It is only the second of these that is being rendered. Instead,
> perhaps we should render the intro content and eliminate any preverse
> titles in verse 1. This is an osis2mod and/or frontend issue (not API).
>
> > chapter 11: two embedded divs just after the chapter start results in
> > first title missing
>
> The preverse code is only grabbing the previous title, so only the last
> title is rendered. Implementing the above would fix this.
>
> > chapter 12: two embedded divs in the middle of the chapter - the
> > titles are in the wrong order
>
> Again it's the preverse code. It's only grabbing the previous title to
> put IT before the verse number. All remaining titles will appear in
> proper order. (For German-speakers, it's just like verb-second. Only the
> very last verb in a clause gets promoted to the second position in the
> clause. :)
>
> > chapter 13: three embedded divs just after the chapter start - two
> > sections missing and verses concatenated
>
> This one is the encoder's fault. :) All of the verses have the same
> osisID (Matt.13.1), so they are concatenated into that verse. Aside from
> the behavior parallel to chapter 11, osis2mod is functioning correctly.
>
> > chapter 14: three embedded divs in the middle of the chapter - wrong
> > titles order
>
> Same as 12.
>
> > chapter 15: a note in the title - not rendered as a note!
>
> The data is correct, the rendering (in BibleCS) is incorrect.
>
> > 4) Various tests
> > chapter 16: test of alternative passages
>
> <rdg> isn't handled, but it also isn't very interesting. I'll make a
> note to add a handler in the filters, but all it will do is italicize
> the contents.
>
> <rdg> is not for alternative passages, just alterate readings. So you
> wouldn't have "<note type="alternative"><catchWord>something</catchWord>
> <rdg>First version of the text</rdg> <rdg>Second version of the
> text</rdg></note>" and expect there to be a toggle between the two
> readings. The primary reading occurs in the text (and possibly in the
> <catchWord>).
>
> The OSIS 2.1 draft manual gives the following example of intended usage:
>
> <verse osisID="NRSV.Song.2.1">I am a rose<note
> osisRef="NRSV.Song.2.1 at s[rose]">Heb <rdg>crocus</rdg></note> of Sharon,
> a lily of the valleys.</verse>
>
>
>
> Thanks for going to the trouble of writing the test file. I'll continue
> to use it to test until we get the import & rendering improved. It
> illustrated a lot of areas where both osis2mod and BibleCS could use
> some work, but I don't think any of the items need to hold up the
> release of 1.5.8 (the API). I would recommend we attend to the osis2mod
> and BibleCS problems before releasing them. (I realize that much of the
> BibleCS code responsible for its deficiencies is in the OSIS2RTF filter,
> which is technically part of the API, but I don't think this is used by
> anything other than BibleCS, so I wouldn't see a problem with releasing
> 1.5.8 with a buggy OSIS2RTF, so long as it gets fixed before the next
> BibleCS itself is released.)
>
> --Chris
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Apr 2005 13:10:31 +0200
> From: "Krzysztof Bialas" <krzbia at ctm.gdynia.pl>
> Subject: Re: [sword-devel] 1 bug left for 1.5.8
> To: "SWORD Developers' Collaboration Forum"
> <sword-devel at crosswire.org>
> Message-ID: <000601c539d0$17952bc0$d064a8c0 at ctm.gdynia.pl>
> Content-Type: text/plain; format=flowed; charset="UTF-8";
> reply-type=response
>
> Chris, Thank You very much for taking time and investigating the problems in
> the test file. I'm sorry for the mixup with osis id's, I've corrected this
> and verses are no longer concatenated :-).
> With paragraphed intros and paragraph markers outside of the verse tags I
> still see 'gibberish', BUT I'm not using SVN version of tools and Sword.
> osis2mod and icudt28l.dll are from the
> http://crosswire.org/ftpmirror/pub/sword/utils/win32/, and the sword
> 1.5.8pre3 is from
> http://www.crosswire.org/sword/ALPHAcckswwlkrfre22034820285912/alpha/. I
> expect that someone repaired this issue later - so I'd appreciate if someone
> could post new binaries of BibleCS, icu and utils. Please please pretty
> please with sugar on the top? :-)
>
> I won't oppose the release of 1.5.8 - right now I'm just a little confused
> about the release of BibleCS 1.5.8 and win32 utils (with osis2mod). Can
> someone define the release date? So the course of action would be to:
> release sword-api 1.5.8 and then correct the rendering and osis2mod small
> faults and release BibleCS?
>
> Thank You form pointing out the OSIS style corrections. With further
> questions regarding OSIS coding I will go first to the osis-user list - and
> I have quite a few questions, I can assure You :-)
>
> Just as a side note. I would expect something like 'my' test file done
> earlier to check whether tools/api/rendering engine works correctly and use
> it to quickly check further releases. Perhaps the file I've created - with
> necessary corrections and additions could serve as a general test file for
> OSIS support in the Sword project. Doing my part of the job I'll correct the
> file problems with OSIS id's and change the notation from 'there is a bug
> here and here' to 'it should look like that or that' so anyone could quickly
> check whether tools/api/rendering works correctly after next batch of SVN
> updates (or even better BEFORE a batch of SVN checkins :-)). OK?
>
> Thank You again Chris;
>
> Christopher.
>
> ----- Original Message -----
> From: "Chris Little" <chrislit at crosswire.org>
> To: "SWORD Developers' Collaboration Forum" <sword-devel at crosswire.org>
> Sent: Tuesday, April 05, 2005 10:17 AM
> Subject: Re: [sword-devel] 1 bug left for 1.5.8
>
>
> > Okay, I've taken a look at the test.osis.xml file Christopher posted in
> > the bug tracker and found the following. This is based on a module
> > compiled with osis2mod (from SVN) and the same module inspected in BibleCS
> > 1.5.8pre3, as well as the module exported with mod2osis & mod2imp (from
> > SVN).
> >
> > (Quoting from Matthew chapter 1 in the document test file:)
> > > This is a test file to show off the problems encountered with Sword
> > > OSIS2Mod and Sword for windows rendering. In the examples below I've
> > > used '[' and ']' in the place of '<' and '>'
> > > This file was written using XMLSpy and validated successfully against
> > > osisCore.2.0.1.xsd
> >
> > Just to confirm, it also validates in oXygen.
> >
> > > This file is split up into several chapters each showing a different
> > > behaviour. The contents of each chapter is described below:
> > > 0) Introduction test:
> > > chapter 0: introduction which contains multiple parapgraphs is not
> > > rendered properly (some RTF rubbish)
> >
> > Works/renders fine in 1.5.8pre3. Maybe the problem has already been
> > corrected.
> >
> > > 1) Paragraph tests: additionally chapterTitle in chapters 2-4 is just
> > > ignored...
> >
> > The chapterTitle attribute on <chapter> elements is preserved by osis2mod,
> > but ignored by the engine. I have no idea what this attribute is for, but
> > would guess it is something we forgot to remove when we changed how titles
> > are done. In any case, the correct way to encode all titles that occur in
> > the text would be with <title>.
> >
> > > chapter 2: paragraph markers outside of verse tags (paragraphs enclose
> > > verse tags) - resulting a complete mess in Sword for Windows RTF
> >
> > It's unattractive but not RTF gibberish, so I suspect this has already
> > been fixed.
> >
> > > chapter 3: paragraph markers inside verses, with construct like this:
> > > [verse s][p]text[/p][p][verse e][verse s]text[/p][p][verse e]. This is
> > > the workaround for problems introduced in chapter 2.
> > > chapter 4: paragraph markers completelly embeded into verses - all [p]
> > > and [/p] markers are inside the verse tags. Also considered by me as a
> > > woraround to problems in chapter 2
> >
> > Workarounds are bad.
> >
> > > 2) notes/xrefs problems:
> > > chapter 5: xrefs crossing paragraph boundaries
> >
> > This is also just the problem above that was fixed.
> >
> > > 3) problems with div's and titles
> > > chapter 6: div and title ignored if placed before the chapter start
> > > tag
> >
> > This is correct, but where should content between two chapters go? Should
> > it go in the introduction to the following chapter?
> >
> > > chapter 7: two separate divs and titles inside a chapter - possibly
> > > missing newline after the div end tag
> >
> > This is just a criticism of rendering style, so not really a bug. And it's
> > a criticism specific to BibleCS. Short answer: no, div should not generate
> > paragraph breaks.
> >
> > Best practice OSIS requires a structure of:
> > <div type="book"> with other div types embedded in that, notably <div
> > type="section">. But the lowest level of the primary OSIS hierarchy is
> > <p>. <p> should and does generate paragraph breaks. It never allows
> > embedding of <div>s, so <p> should be the lowest level always. (This
> > ignores simple Bibles without any paragraph structure, just
> > book/chapter/verse.)
> >
> > > chapter 8 and 9: div spanning two chapters - almost ok
> >
> > Same issue as chapter 7.
> >
> > > chapter 10: div and title just after the chapter start tag - also
> > > almost correct
> >
> > Same issue as chapter 7, also. But there is also a problem here with
> > osis2mod. It's making two copies of <title> elements that occur before the
> > first verse. (One in the chapter intro, one in the verse 1 preverse
> > title.) It is only the second of these that is being rendered. Instead,
> > perhaps we should render the intro content and eliminate any preverse
> > titles in verse 1. This is an osis2mod and/or frontend issue (not API).
> >
> > > chapter 11: two embedded divs just after the chapter start results in
> > > first title missing
> >
> > The preverse code is only grabbing the previous title, so only the last
> > title is rendered. Implementing the above would fix this.
> >
> > > chapter 12: two embedded divs in the middle of the chapter - the
> > > titles are in the wrong order
> >
> > Again it's the preverse code. It's only grabbing the previous title to put
> > IT before the verse number. All remaining titles will appear in proper
> > order. (For German-speakers, it's just like verb-second. Only the very
> > last verb in a clause gets promoted to the second position in the clause.
> > :)
> >
> > > chapter 13: three embedded divs just after the chapter start - two
> > > sections missing and verses concatenated
> >
> > This one is the encoder's fault. :) All of the verses have the same osisID
> > (Matt.13.1), so they are concatenated into that verse. Aside from the
> > behavior parallel to chapter 11, osis2mod is functioning correctly.
> >
> > > chapter 14: three embedded divs in the middle of the chapter - wrong
> > > titles order
> >
> > Same as 12.
> >
> > > chapter 15: a note in the title - not rendered as a note!
> >
> > The data is correct, the rendering (in BibleCS) is incorrect.
> >
> > > 4) Various tests
> > > chapter 16: test of alternative passages
> >
> > <rdg> isn't handled, but it also isn't very interesting. I'll make a note
> > to add a handler in the filters, but all it will do is italicize the
> > contents.
> >
> > <rdg> is not for alternative passages, just alterate readings. So you
> > wouldn't have "<note type="alternative"><catchWord>something</catchWord>
> > <rdg>First version of the text</rdg> <rdg>Second version of the
> > text</rdg></note>" and expect there to be a toggle between the two
> > readings. The primary reading occurs in the text (and possibly in the
> > <catchWord>).
> >
> > The OSIS 2.1 draft manual gives the following example of intended usage:
> >
> > <verse osisID="NRSV.Song.2.1">I am a rose<note
> > osisRef="NRSV.Song.2.1 at s[rose]">Heb <rdg>crocus</rdg></note> of Sharon, a
> > lily of the valleys.</verse>
> >
> >
> >
> > Thanks for going to the trouble of writing the test file. I'll continue to
> > use it to test until we get the import & rendering improved. It
> > illustrated a lot of areas where both osis2mod and BibleCS could use some
> > work, but I don't think any of the items need to hold up the release of
> > 1.5.8 (the API). I would recommend we attend to the osis2mod and BibleCS
> > problems before releasing them. (I realize that much of the BibleCS code
> > responsible for its deficiencies is in the OSIS2RTF filter, which is
> > technically part of the API, but I don't think this is used by anything
> > other than BibleCS, so I wouldn't see a problem with releasing 1.5.8 with
> > a buggy OSIS2RTF, so long as it gets fixed before the next BibleCS itself
> > is released.)
> >
> > --Chris
> >
> > _______________________________________________
> > sword-devel mailing list: sword-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Apr 2005 07:36:02 EDT
> From: JPKlingon at aol.com
> Subject: Re: [sword-devel] Re: Christian Debian distro talk / Report
> To: sword-devel at crosswire.org
> Message-ID: <13c.108f1f16.2f83d222 at aol.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> In a message dated 4/5/2005 1:31:37 AM Central Daylight Time,
> hvdkooij at vanderkooij.org writes:
>
>
> > Can we *please* get rid of the development packages, the unnecessary
> editors
> > (5 editors? how about just down to Kedit, Kate, and a text editor (I prefer
> > nano over zile, easier for a newbie to use, but it doesn't matter THAT
> much -
> > most newbies don't do console editing anyway).
>
> It would be wise to leave vi as editor in. (It is the default unix editor
> and nerds like me will not be able to edit tekst files without it if we
> need to assist one of our brothers or sisters.)
>
>
>
> Yes - Editors typically don't take that much space, and people have VERY
> decided preferences. If I don't have an Emacs work-alike I almost always wind
> up installing it. Keep Zile - keep emacs too!
>
> ** _http://KLV.mrklingon.org_ (http://klv.mrklingon.org/) :The Klingon
> Language Version Bible **
> **** Hegh tI, 'ej ngab tI naH, 'ach reH taHtaH joH'a'ma' mu'****
> **"The grass withers, and the flowers fade, but the word of our **
> ** God stands forever." Isaiah 40.8 NLT **
>
> ** joel peter anderson * joela at mrklingon.org **
>
> Vaccines Save Lives * http://www.vaccineinformation.org
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www.crosswire.org/pipermail/sword-devel/attachments/20050405/173c72c4/att
> achment.html
>
> ------------------------------
>
> _______________________________________________
> sword-devel mailing list
> sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
>
>
> End of sword-devel Digest, Vol 13, Issue 10
> *******************************************
More information about the sword-devel
mailing list