I find TEI somewhat unfathomable, but would like to advise that I have done a lot of work in the libsword svn head to a) make all xml input come out as xhtml with class attributes (which then can be used to render with CSS), b) make the engine spit out some decent default CSS and c) have recently committed a patch by DomCox which brought TEI support generally onto the level of OSIS in terms of tables and images. TEI Links have been working for a while I think.
If you want to see whether the module renders decently look at it in Xiphos compiled against svn-head.
Peter
Gesendet: Donnerstag, 07. Januar 2016 um 13:15 Uhr
Von: "DM Smith" <dmsm...@crosswire.org>
An: "SWORD Developers' Collaboration Forum" <sword-devel@crosswire.org>
Betreff: Re: [sword-devel] NASB status
Von: "DM Smith" <dmsm...@crosswire.org>
An: "SWORD Developers' Collaboration Forum" <sword-devel@crosswire.org>
Betreff: Re: [sword-devel] NASB status
I really don’t want to encourage the flames.
_______________________________________________ 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
I was asked to modify the C++ source. I did that. I didn’t rewrite it. It is still C++. I think it can be diffed with the original to understand my changes. But I don’t remember if that is the case when I updated it for the latest Lockman input.
Greg’s work is complete. BibleDesktop has a publicly available beta that works with it. (It is not appropriately packaged for each platform.) Existing BD can be patched by a user placing an xslt file in a particular place on their computer.
Regarding JSword, it has full support for the NASB. STEP and AndBible have been released with such support. BibleDesktop beta 2.0 is available with support. I’ve got a couple of nasty bugs in zLD modules that have to be squashed. (I’ve squashed a dozen or so other bugs in the last month.) Other than that, it is merely a packaging issue. So, a version of BD is available for the NASB today. A user may have to run it from a shell script.
I also have done the naslex work. It is written in Perl. Is it complete? I doubt it, as I stopped when my nasb effort wasn’t acceptable. From what I remember:
The markup of the lex is in TEI. This was one of the first dictionaries in TEI. It may need to be examined to see if it still is appropriate.
There was a question to Chris Little, way back then, about how to do linking within the module. I don’t think there was an answer.
There are entries of the form Hnnnn!b (that’s what is in the NASB; in the lex it is Hnnnnb), and the SWORD engine was changed to handle these. The SWORD engine was also modified to handle these when using any of the current Strong’s Number dictionaries.
IIRC, Lockman wanted a single module for the lex. We talked about having a single module with both H and G entries. That is the key would have a leading H or G. This of course would have Greek before Hebrew. I don’t know if the SWORD engine was changed to allow for this.
If I recall, BibleDesktop, SwordWeb and The SWORD Project for Windows displayed the “word" differently. I don’t remember whether it was the Greek or the Hebrew. Best as I can remember, it was an “accented” capital letter.
I don’t remember whether there was a display problem with JSword frontend.
On the CrossWire server, for those that have accounts, the naslex work here: ~dmsmith/newmods/lockman/nasec/naslex
Together in His Service,
DM
Here is an example of the TEI:
<superentry id="H8163" key="H8163"><entryFree><orth xml:lang="he">ריעִשָׂ</orth> <pron>sair</pron> or</pron><orth xml:lang="he">רעִשָׂ</orth> <pron>sair (<xr type="xref"><ref target="BDB:972c">972c</ref></xr>)</pron>; <etym>from the same as <xr type="see">[<ref target="H8181">8181</ref>]</xr></etym>; <def><hi rend="italic">hairy</hi></def>:― <usg>hairy(3), shaggy(2).</usg></entryFree><entryFree><orth xml:lang="he">ריעִשָׂ</orth> <pron>sair (<xr type="xref"><ref target="BDB:972c">972c</ref></xr>)</pron>; <etym>from the same as <xr type="see">[<ref target="H8181">8181</ref>]</xr></etym>; <def><hi rend="italic">male goat, buck</hi></def>:― <usg>goat(6), goat*(1), goats(3), male(25), male goat(9), male goats(1).</usg></entryFree><entryFree><orth xml:lang="he">ריעִשָׂ</orth> <pron>sair (<xr type="xref"><ref target="BDB:972d">972d</ref></xr>)</pron>; <etym>from the same as <xr type="see">[<ref target="H8181">8181</ref>]</xr></etym>; <def><hi rend="italic">a satyr, demon</hi></def>:― <usg>demons(1), satyrs(1).</usg></entryFree></superentry>
<entryFree id="H8163a" key="H8163a"><orth xml:lang="he">ריעִשָׂ</orth> <pron>sair</pron> or</pron><orth xml:lang="he">רעִשָׂ</orth> <pron>sair (<xr type="xref"><ref target="BDB:972c">972c</ref></xr>)</pron>; <etym>from the same as <xr type="see">[<ref target="H8181">8181</ref>]</xr></etym>; <def><hi rend="italic">hairy</hi></def>:― <usg>hairy(3), shaggy(2).</usg></entryFree>
<entryFree id="H8163b" key="H8163b"><orth xml:lang="he">ריעִשָׂ</orth> <pron>sair (<xr type="xref"><ref target="BDB:972c">972c</ref></xr>)</pron>; <etym>from the same as <xr type="see">[<ref target="H8181">8181</ref>]</xr></etym>; <def><hi rend="italic">male goat, buck</hi></def>:― <usg>goat(6), goat*(1), goats(3), male(25), male goat(9), male goats(1).</usg></entryFree>
<entryFree id="H8163c" key="H8163c"><orth xml:lang="he">ריעִשָׂ</orth> <pron>sair (<xr type="xref"><ref target="BDB:972d">972d</ref></xr>)</pron>; <etym>from the same as <xr type="see">[<ref target="H8181">8181</ref>]</xr></etym>; <def><hi rend="italic">a satyr, demon</hi></def>:― <usg>demons(1), satyrs(1).</usg></entryFree>
On Jan 6, 2016, at 5:04 PM, Troy A. Griffitts <scr...@crosswire.org> wrote:I hesitate to even respond to this thread, as none of this kicks the can down the road, but... I believe some of the issue has to do with typical open source volunteer problems. Specifically, in this case, none of the pumpkin holders was satisfied to build on their predecessors' code. I originally made the initial co version in C++. My script is versioned in the sword-tools repo. I'm not sure what Chris did. I know DM rewrote the conversion in Java, and it sounds like Greg has again rewritten the conversion in Python. It is not a matter of perfection before release. It is a matter of basic satisfaction of the three items I have listed and we have not attainted basic satisfaction yet.
Troy
On January 6, 2016 2:51:55 PM MST, "Matěj Cepl" <mc...@cepl.eu> wrote:On 2016-01-06, 18:53 GMT, Troy A. Griffitts wrote:This is a commercial module to be sold by Lockman. That is
a different scenario from other modules. For this module,
I have reasonably asked:
I didn’t like Karl’s tone last time the flamewar went around,
but I have to admit he is right. Whatever you say is suspicious
because of one argument: “Twelve years”.
1) That we have a scripted, reproducible way to transform
their data from their pristine source to a module.
Yes, what’s the problem? Whom you asked for help (e.g., I have
developed completely automatic conversion of CzeCSP from one XML
to OSIS, and it didn’t take me twelve years to do it)? Twelve
years.
2) That we support their entire dataset which they have given
us for this module (base text + footnotes / crossrefs
+ lexica)
Yes, I have CzeCSP with footnotes, crossrefs, and notes. Twelve
years.
3) That the result works generally in all major SWORD/JSword
frontends.
What are the problems? Where are the bugs? Where is the progress
on development of the module recorded? I would be willing to buy
the module, if that was required to work on it. Twelve years.
It is not as simple as-- just release it and fix it later.
This is to be sold by Lockman.
What do you mean? I work for Red Hat. We sell software in tune
of some, let's say, two billions of USD. Of course, we don’t
expect it to absolutely perfect and bug-free. If there are bugs
in the module, we can certainly provide a fix. Where is the
alpha version, how do you plan to make QA working? Twelve years.
Historically, we have had at least 4 people own this effort
over the years. It is not simply that one person has sat on
this and hasn't finished it for 12 years.
Yes, so where are products of work of all these people? What did
they do? I mean, I honestly believe that some work was done, but
without some presentation of the results, how can we know what's
done? Here “Twelve years” makes it even more difficult to be
persuaded.
I think we are close. In my mind, the current owner (Greg)
simply needs to have a list of outstanding items which keep us
from satisfying 1-3 and push each of them down the road until
they are done.
And where is that list? That is my question.
I don't know what those items are. I am just concerned that
we meet 1-3 before we give the data to Lockman to sell and
I feel these 3 items are reasonable requests.
I don't think Lockman expects the work to be ever done at this
point, but that's another thing. If they do, they have my
admiration (or something else).
However, if you (or Lockman) expect that you will hand over
finished absolutely prefect module and Lockman will never ever
see you (or anybody from the Sword project) again, than I think
you are sorely mistaken. Unless of course they are prepared to
maintain the module themselves. After all, even NASB itself is
(according to Wikipedia) in its tenth edition.
Blessings,
Matěj
--
Sent from my Android device with K-9 Mail. Please excuse my brevity._______________________________________________
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
