-> <h1> >> rather than >> <title> -> <b><br /> >> >> <transChange type="added"> -> <span class="tcAdded"> >> rather than >> <transChange type="added"> -> <i> >> >> etc. >> >> I believe this will solve a number of issues and possibly get the BT and >> MacSword teams onboard to using the same HTML output filters as the >> other projects involve (or at least subclassing them and using the >> majority of their functionality). > > I think this is our pretty well accepted premise. The current filters > stink to various degrees and currently no one is willing to step up > and tackle them. > >> >> >> Now, as to the other issue of using XSLT internally in the engine to >> process OSIS -> HTML >> >> I will throw a few melons into the air for target practice, and let the >> shooting commence. >> >> _____________________________ >> *Multiple Language* >> >> XSLT is a programming language in the same sense that C++ is a >> programming language. >> >> The SWORD Project C++ engine is written in C++. It is not a Python >> engine; it is not a Perl engine; it is not a Java engine; it is C++. >> >> One might say, "Well, you can use XSLT from C++. Doesn't JSword do this >> from Java?" Well, yes, of course you can, and DM can comment, if he >> feels the desire to recommend his decision to encorporate an XSLT engine >> into the JSword logic flow. But simply because one CAN doesn't mean one >> SHOULD. We COULD encorporate a Perl text processing engine in our C++ >> code, or an Awk processing engine... that doesn't mean we SHOULD. I'm >> sure some would say we SHOULD. And obviously DM has thought he SHOULD >> encorporate XSLT processing for JSword, so I'm not intending to say it >> is a BAD decision, just that it is not a decision I would make; in the >> same way as our projects each chose C++ vs. Java to implement our objective. > > If a developer is going to develop OSIS -> HTML filters, for instance, > we are already assuming they know OSIS and HTML. OSIS is XML and HTML > is SGML (though most of our work is probably targetting a more > XML-dialect of HTML). XSLT is also XML. Formally, it is not even a > programming language, but just a set of formatting/processing > instructions in XML. > > Any developer using XML who is worth their salt should at least be > familiar with the basics of XSL - they may not be a guru of XPath > expressions or have every attribute of XSL memorized - and would > probably expect a library which handles XML as its preferred input > method to utilize one of the standard XML processing methods. I know > I'm not the only person who was surprised to look in the library > filters and see neither DOM, SAX nor XSLT technologies in use. That > was when I first ran and hid. > > Of course, this portion of the discussion is only relevant for the > from-OSIS filters. > >> >> _______________________ >> *XSLT better than C++* >> >> One might say, "well, XSLT is better suited to process XML than C++." >> That's a loaded and unquantified statement. >> >> Certainly the C++ language specification doesn't include facilities to >> easily process XML, but that doesn't mean a plethora of C++ libraries >> don't exists for assisting in this task. >> >> The SWORD engine includes classes like XMLTag and SWBasicFilter which >> implement a SAX processing model. >> >> The current filters do not all use SWBasicFilter, nor XMLTag. They've >> been written over 15 years and many before these classes existed. Some >> are ugly and need to be rewritten for readability, certainly. But not >> necessarily in a different programming language. > > XSLT being "better" is, yes, a matter of complete subjectivity. And, > as I mentioned above, is only useful when our source is XML to begin > with. For GBF or Plaintext sources, XSLT is clearly not even > applicable. > > But the current C++ is so good that you seem the only person willing > to touch it. Peter just mentioned he tried once and couldn't get it. > I have gone into the filters before with a singular goal in mind and > was able to produce my desired changes, but it was long, drawn-out and > painful. Doing the same tasks in XSL would have taken me mere > seconds. I know a few other people, at least, have said they would > know how to do a task if XSLT was used instead of C++. Of course, > that is a hypothetical - I can't know that they would have done so, > but that was their claim at the time. > > Our recent discussion about the use of the "n" attribute for footnotes > in ThML is a perfect example. Maintaining the attribute in XSL would > have been a trivial task I could have handled in seconds. Instead, it > required you, myself and Karl and took about 10 days to get fixed. > You had to alert Karl and me to presence of the attributes, I provided > him a preliminary patch to incorporate the values, then he had to > heavily modify the patch to operate correctly in non-ThML source and a > few other corner cases. And, in the end, the fix is only in Xiphos' > code base - I would have to go through 2 of those three steps again in > Bibletime, BPBible, MacSword and any other applications I wanted to > see proper behavior in. Alternatively I could tackle the filters - > but I'm not really inclined to do so. > > Is XSLT "better"? For me, it would be better because I could more > easily modify its behavior based on the fact that I know XML and could > easily locate the necessary processing directive. For you, maybe not. > Are there things you simply cannot do in XSL that C++ can? Yes. IMO > the benefits of XSL outweigh the benefits of C++ for this task, but > you clearly disagree. :) I would also say that DOM or SAX processing > would be better for all the same reasons - it shields the user from > having to see the XML parsing and handle inconsistencies in > whitespace, validation, etc and is still a decently well-known > technology among XML users (even if it's slightly less well-known than > XSL). And with a DOM or SAX parser, you could still happily employ > the full power of C++. > >> >> ________________________ >> *COMPLEXITY* >> >> The task of enumerating all types of OSIS <title> tags, and deciding >> what to do with each, and how to classify all <title> tags from all >> possible OSIS documents into our enumeration is still going to be a >> complex task using XSLT. <title> is a complex example, but certainly >> not the most complex. >> >> It is a tall task to generalize all elements of all documents from all >> publishers into one conceptual model with one chosen output for a >> frontend-- whether that be for an audience on the Desktop, web-based, or >> a handheld. >> >> The complex processing required by the engine will require long, complex >> XSLT-- which likely will encorporate callbacks to C++. It will not be >> more simple-- only mixed language. > > I could also argue that the XSL would not require a developer to > mentally filter out the code that just identifies and locates XML > elements and attributes and parses them from the code that transforms > them and generates the output. Thus yes, it might include some > extension functions into C++ but it would be simpler. And it would > also be more expressive. > > The enumeration of every OSIS <title> tag is a moot point for the > decision. You need to enumerate them all in C++ as well and decide > what to do with them. That doesn't change in the XSL - just the > method used. An XSL match along the lines of <xsl:template > match="title[@type=psalm]"> still has to be done in C++ with some sort > of if(tag.name() == "title && tag.attr("type") == "psalm") or whatever > the syntax is. And that is assuming the current filter is using > XMLTag and isn't comparing character strings directly. > >> _______________________ >> *Semantic vs. Display* >> >> Some will say (and have), "well, let everything be display oriented and >> let the publisher decide". Fine, then you lose 2 things: the ability to >> display differently per user preference, per display device; and you >> also give up the promise to actually do any interesting research on the >> text. When you lose semantic markup, then you lose all interesting >> information about WHAT is being marked up. > > I just want to be clear that I'm not advocating the use of display > over semantics as a general choice. My statements are strictly based > around my specific task and the fact that OSIS support in SWORD and > the front ends is not as good as the support of ThML. Largely this is > because most applications display in HTML and my required task is > framed entirely in terms of the presentation and display - not the > semantics. I would love and prefer to use OSIS for this task, but I > simply cannot accomplish it with the state of SWORD at this time. > >> >> _______________________ >> *More than a Rending Engine* >> >> The SWORD C++ Engine is more than simply a text rendering engine-- it is >> a Biblical text research engine. >> >> If I'd like to know the morphology of word 3 in 2Thes 2.13 of the WHNU >> Greek text, the entire program to do such is: >> >> SWMgr library; >> SWModule *whnu = library.getModule("WHNU"); >> whnu->setKey("2th.2.13"); >> whnu->RenderText(); >> >> cout << "The morphology of word three is: " << >> whnu->getEntryAttributes()["Word"]["003"]["Morph"] << endl; >> >> >> That reads nice (at least in my opinion). I don't need to know about >> XML, XSLT, care what markup the WHNU module uses, I don't even have to >> know how to make a SWORD filter. The current filters do all the work of >> breaking out these attributes and making them available in a nice and >> interesting map. > > I'd like to be clear again, that XSL would only be useful for material > already in OSIS formats (or in valid ThML - I think TEI is also an XML > format?). I doubt many modules in ThML are strictly valid at their > import times, so XSL wouldn't be very useful, and GBF is a monster > unto itself. Doing the above in XSL from an OSIS source would not be > much different in complexity than what you have listed there. > > <xsl:template match="verse[@osisID='2thes.2.13']/w[@n=3]"> > The morphology of word three is: <xsl:value-of select="@morph" /> > </xsl:template> > > Or something similar (my knowledge of exact OSIS attribute names and > values wanes and it's been two or three weeks since I wrote an XPath > expression). > > Of course, the string processing portion of SWORD would continue to be > of great importance for any modules in GBF format or similar to bring > them into a useful form. In that way, SWORD would continue to be more > than just a text rendering engine. It would continue to offer all of > its features, its buffering from the system and from the format, its > indexing, its module fetching and storing, etc. > >> ______________________ >> >> >> And finally, if bullets aren't flying already, I'll stir the heat up with... >> >> XSLT sucks. A good C++ programmer can do anything in C++ better than >> any XSLT programmer. >> >> >> :) > > A C++ programmer can definitely do more, since C++ is actually a > programming language and XSLT is a set of processing instructions. > Better? That depends on what the criteria is. For me, in my current > role as a module creator, the use of C++ is not currently better > because it is less flexible and extensible. For you, as the library > maintainer, perhaps C++ is better because it's what you are already > comfortable with and because it has largely been your hand in the > filters. > >> >> *duck* >> Have fun. >> >> Troy >> >> PS. In summary, I understand the current filters are sometimes overly >> complex and need cleanup, standardization, etc. It comes down to the >> fact that they mostly work, and other things which don't get priority, >> so they don't get much attention. But honestly, I think one might be >> oversimplifying the problem at hand without realizing it, if one simply >> thinks switching to XSLT will make things easier. > > I think one is also oversimplifying the options. My dreamlist is that > SWORD produce a well-formed, valid, complete OSIS document for an > arbitrary KeyList that I pass it with FMT_OSIS set. That basically > boils down to getting the *OSIS filters up to snuff and standardized. > The second item on the list is a readily extensible mechanism for > SWORD outputting HTML from that OSIS. If that choice is providing an > XSL stylesheet with the library, a C++ SAX processor that a front-end > can readily extend, a DOM interface that can be easily customized is > immaterial to me. I like all three of those, and can easily > understand and extend all of them. > > I think any of those technologies would be an improvement over all > in-house C++ for the second half of any such processing. If we are > using XML in Open Source Software, let's leverage the work of others > who have happily given us permission to use their libraries! > > --Greg > > _______________________________________________ > 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 From refdoc at gmx.net Wed Dec 1 05:37:26 2010 From: refdoc at gmx.net (Peter von Kaehne) Date: Wed, 01 Dec 2010 13:37:26 +0100 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <4CF63DA3.4030306@crosswire.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTi=sDGZzwzAzmnuv24rgHw7gL0F78PD5RyorVzmL@mail.gmail.com> <4CF63DA3.4030306@crosswire.org> Message-ID: <20101201123726.108380@gmx.net> > Von: "Troy A. Griffitts" <scribe at crosswire.org> > The current processing model is dark magic and I apologize for this. It > should be well documented and easy to modify. I will attempt to improve > the dissemination of knowledge of exactly WHAT our Forms are, how we > impose those Forms on publishers' texts and improve the documentation > and code to help others understand and have the ability to improve the > code. > > I'll attempt to post a few easy to swallow SWORD 101 classes in email, > which will help us gather our thoughts and documents on how all this > works. Great! I am looking forward to that. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail From mjdenham at gmail.com Wed Dec 1 05:50:28 2010 From: mjdenham at gmail.com (Martin Denham) Date: Wed, 1 Dec 2010 12:50:28 +0000 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <4CF63DA3.4030306@crosswire.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTi=sDGZzwzAzmnuv24rgHw7gL0F78PD5RyorVzmL@mail.gmail.com> <4CF63DA3.4030306@crosswire.org> Message-ID: <AANLkTimTEX1mT0TfXU2iinHmqu1x69kLSH4w4ngGNT=P@mail.gmail.com> Excuse me for being pure Java and not knowing Sword C++ at all but can I add (perhaps obviously) that an XSLT framework will perform noticeably slower than a SAX-like framework. Here <http://java.sun.com/developer/technicalArticles/xml/JavaTechandXML_part2/>are some performance comparisons. They are old and Java-centric and so XSLT performance may have improved but these tests show that in the worst case XSLT was 3 times slower than SAX and a good SAX processor was twice as fast as a good XSLT processor. If pages are parsed at the chapter level then users may notice a delay turning pages on smaller machines like mobile phones. Martin On 1 December 2010 12:20, Troy A. Griffitts <scribe at crosswire.org> wrote: > The logic to get from any Publisher Source Document to rendered HTML is > a very complex task to solve. > > We conceptually create Plato's Form of, say, a Bible, and try to fit > imperfect Publisher markup into this concept. A Bible has verses, > headings between verses, chapter intros, footnotes, crossrefs, lemma > information, etc. > > If we do not do this, then we become a PDF reader-- there are already > PDF readers and we lose the ability to do Bible specific things with our > software. For example, if we didn't normalize the concept of crossref > across all Books, then we couldn't turn them on and off; we couldn't > provide a crossref panel in the reader which fills according to which > crossref is hovered over, etc. Same with notes, strongs, headings, etc. > > This causes us to impose our Form onto a publisher's text. I understand > why some people may not like this, but it is very much to our end users' > benefit that we do this. Without this, we become a web-browser or a PDF > reader. Which are fine for their purpose, but we intend to provide > common, familiar, and sometimes novel Bible study aides to our reader. > > The current processing model is dark magic and I apologize for this. It > should be well documented and easy to modify. I will attempt to improve > the dissemination of knowledge of exactly WHAT our Forms are, how we > impose those Forms on publishers' texts and improve the documentation > and code to help others understand and have the ability to improve the > code. > > I'll attempt to post a few easy to swallow SWORD 101 classes in email, > which will help us gather our thoughts and documents on how all this works. > > > Troy > > > > On 12/01/2010 12:09 AM, Greg Hellings wrote: > > On Tue, Nov 30, 2010 at 1:08 PM, Troy A. Griffitts <scribe at crosswire.org> > wrote: > >> Having finally returned from a hectic 2 weeks of conferences, and lots > >> to do before leaving for Christmas, I'm not sure I'm up for a heated, > >> passionate debate about technologies right now, but by all means, please > >> commence the public discussion. > >> > >> Let me start by saying that everyone (I believe) agrees that we would > >> like to have an HTML output from the engine which is more generic and > >> would allow CSS to be applied if a frontend would like to do this. > >> Currently HTMLHREF output from the engine is used by the widest number > >> of frontends (to my knowledge) and would benefit everyone involved by > >> becoming much more generic. e.g., > >> > >> <title> -> <h1> > >> rather than > >> <title> -> <b><br /> > >> > >> <transChange type="added"> -> <span class="tcAdded"> > >> rather than > >> <transChange type="added"> -> <i> > >> > >> etc. > >> > >> I believe this will solve a number of issues and possibly get the BT and > >> MacSword teams onboard to using the same HTML output filters as the > >> other projects involve (or at least subclassing them and using the > >> majority of their functionality). > > > > I think this is our pretty well accepted premise. The current filters > > stink to various degrees and currently no one is willing to step up > > and tackle them. > > > >> > >> > >> Now, as to the other issue of using XSLT internally in the engine to > >> process OSIS -> HTML > >> > >> I will throw a few melons into the air for target practice, and let the > >> shooting commence. > >> > >> _____________________________ > >> *Multiple Language* > >> > >> XSLT is a programming language in the same sense that C++ is a > >> programming language. > >> > >> The SWORD Project C++ engine is written in C++. It is not a Python > >> engine; it is not a Perl engine; it is not a Java engine; it is C++. > >> > >> One might say, "Well, you can use XSLT from C++. Doesn't JSword do this > >> from Java?" Well, yes, of course you can, and DM can comment, if he > >> feels the desire to recommend his decision to encorporate an XSLT engine > >> into the JSword logic flow. But simply because one CAN doesn't mean one > >> SHOULD. We COULD encorporate a Perl text processing engine in our C++ > >> code, or an Awk processing engine... that doesn't mean we SHOULD. I'm > >> sure some would say we SHOULD. And obviously DM has thought he SHOULD > >> encorporate XSLT processing for JSword, so I'm not intending to say it > >> is a BAD decision, just that it is not a decision I would make; in the > >> same way as our projects each chose C++ vs. Java to implement our > objective. > > > > If a developer is going to develop OSIS -> HTML filters, for instance, > > we are already assuming they know OSIS and HTML. OSIS is XML and HTML > > is SGML (though most of our work is probably targetting a more > > XML-dialect of HTML). XSLT is also XML. Formally, it is not even a > > programming language, but just a set of formatting/processing > > instructions in XML. > > > > Any developer using XML who is worth their salt should at least be > > familiar with the basics of XSL - they may not be a guru of XPath > > expressions or have every attribute of XSL memorized - and would > > probably expect a library which handles XML as its preferred input > > method to utilize one of the standard XML processing methods. I know > > I'm not the only person who was surprised to look in the library > > filters and see neither DOM, SAX nor XSLT technologies in use. That > > was when I first ran and hid. > > > > Of course, this portion of the discussion is only relevant for the > > from-OSIS filters. > > > >> > >> _______________________ > >> *XSLT better than C++* > >> > >> One might say, "well, XSLT is better suited to process XML than C++." > >> That's a loaded and unquantified statement. > >> > >> Certainly the C++ language specification doesn't include facilities to > >> easily process XML, but that doesn't mean a plethora of C++ libraries > >> don't exists for assisting in this task. > >> > >> The SWORD engine includes classes like XMLTag and SWBasicFilter which > >> implement a SAX processing model. > >> > >> The current filters do not all use SWBasicFilter, nor XMLTag. They've > >> been written over 15 years and many before these classes existed. Some > >> are ugly and need to be rewritten for readability, certainly. But not > >> necessarily in a different programming language. > > > > XSLT being "better" is, yes, a matter of complete subjectivity. And, > > as I mentioned above, is only useful when our source is XML to begin > > with. For GBF or Plaintext sources, XSLT is clearly not even > > applicable. > > > > But the current C++ is so good that you seem the only person willing > > to touch it. Peter just mentioned he tried once and couldn't get it. > > I have gone into the filters before with a singular goal in mind and > > was able to produce my desired changes, but it was long, drawn-out and > > painful. Doing the same tasks in XSL would have taken me mere > > seconds. I know a few other people, at least, have said they would > > know how to do a task if XSLT was used instead of C++. Of course, > > that is a hypothetical - I can't know that they would have done so, > > but that was their claim at the time. > > > > Our recent discussion about the use of the "n" attribute for footnotes > > in ThML is a perfect example. Maintaining the attribute in XSL would > > have been a trivial task I could have handled in seconds. Instead, it > > required you, myself and Karl and took about 10 days to get fixed. > > You had to alert Karl and me to presence of the attributes, I provided > > him a preliminary patch to incorporate the values, then he had to > > heavily modify the patch to operate correctly in non-ThML source and a > > few other corner cases. And, in the end, the fix is only in Xiphos' > > code base - I would have to go through 2 of those three steps again in > > Bibletime, BPBible, MacSword and any other applications I wanted to > > see proper behavior in. Alternatively I could tackle the filters - > > but I'm not really inclined to do so. > > > > Is XSLT "better"? For me, it would be better because I could more > > easily modify its behavior based on the fact that I know XML and could > > easily locate the necessary processing directive. For you, maybe not. > > Are there things you simply cannot do in XSL that C++ can? Yes. IMO > > the benefits of XSL outweigh the benefits of C++ for this task, but > > you clearly disagree. :) I would also say that DOM or SAX processing > > would be better for all the same reasons - it shields the user from > > having to see the XML parsing and handle inconsistencies in > > whitespace, validation, etc and is still a decently well-known > > technology among XML users (even if it's slightly less well-known than > > XSL). And with a DOM or SAX parser, you could still happily employ > > the full power of C++. > > > >> > >> ________________________ > >> *COMPLEXITY* > >> > >> The task of enumerating all types of OSIS <title> tags, and deciding > >> what to do with each, and how to classify all <title> tags from all > >> possible OSIS documents into our enumeration is still going to be a > >> complex task using XSLT. <title> is a complex example, but certainly > >> not the most complex. > >> > >> It is a tall task to generalize all elements of all documents from all > >> publishers into one conceptual model with one chosen output for a > >> frontend-- whether that be for an audience on the Desktop, web-based, or > >> a handheld. > >> > >> The complex processing required by the engine will require long, complex > >> XSLT-- which likely will encorporate callbacks to C++. It will not be > >> more simple-- only mixed language. > > > > I could also argue that the XSL would not require a developer to > > mentally filter out the code that just identifies and locates XML > > elements and attributes and parses them from the code that transforms > > them and generates the output. Thus yes, it might include some > > extension functions into C++ but it would be simpler. And it would > > also be more expressive. > > > > The enumeration of every OSIS <title> tag is a moot point for the > > decision. You need to enumerate them all in C++ as well and decide > > what to do with them. That doesn't change in the XSL - just the > > method used. An XSL match along the lines of <xsl:template > > match="title[@type=psalm]"> still has to be done in C++ with some sort > > of if(tag.name() == "title && tag.attr("type") == "psalm") or whatever > > the syntax is. And that is assuming the current filter is using > > XMLTag and isn't comparing character strings directly. > > > >> _______________________ > >> *Semantic vs. Display* > >> > >> Some will say (and have), "well, let everything be display oriented and > >> let the publisher decide". Fine, then you lose 2 things: the ability to > >> display differently per user preference, per display device; and you > >> also give up the promise to actually do any interesting research on the > >> text. When you lose semantic markup, then you lose all interesting > >> information about WHAT is being marked up. > > > > I just want to be clear that I'm not advocating the use of display > > over semantics as a general choice. My statements are strictly based > > around my specific task and the fact that OSIS support in SWORD and > > the front ends is not as good as the support of ThML. Largely this is > > because most applications display in HTML and my required task is > > framed entirely in terms of the presentation and display - not the > > semantics. I would love and prefer to use OSIS for this task, but I > > simply cannot accomplish it with the state of SWORD at this time. > > > >> > >> _______________________ > >> *More than a Rending Engine* > >> > >> The SWORD C++ Engine is more than simply a text rendering engine-- it is > >> a Biblical text research engine. > >> > >> If I'd like to know the morphology of word 3 in 2Thes 2.13 of the WHNU > >> Greek text, the entire program to do such is: > >> > >> SWMgr library; > >> SWModule *whnu = library.getModule("WHNU"); > >> whnu->setKey("2th.2.13"); > >> whnu->RenderText(); > >> > >> cout << "The morphology of word three is: " << > >> whnu->getEntryAttributes()["Word"]["003"]["Morph"] << endl; > >> > >> > >> That reads nice (at least in my opinion). I don't need to know about > >> XML, XSLT, care what markup the WHNU module uses, I don't even have to > >> know how to make a SWORD filter. The current filters do all the work of > >> breaking out these attributes and making them available in a nice and > >> interesting map. > > > > I'd like to be clear again, that XSL would only be useful for material > > already in OSIS formats (or in valid ThML - I think TEI is also an XML > > format?). I doubt many modules in ThML are strictly valid at their > > import times, so XSL wouldn't be very useful, and GBF is a monster > > unto itself. Doing the above in XSL from an OSIS source would not be > > much different in complexity than what you have listed there. > > > > <xsl:template match="verse[@osisID='2thes.2.13']/w[@n=3]"> > > The morphology of word three is: <xsl:value-of select="@morph" /> > > </xsl:template> > > > > Or something similar (my knowledge of exact OSIS attribute names and > > values wanes and it's been two or three weeks since I wrote an XPath > > expression). > > > > Of course, the string processing portion of SWORD would continue to be > > of great importance for any modules in GBF format or similar to bring > > them into a useful form. In that way, SWORD would continue to be more > > than just a text rendering engine. It would continue to offer all of > > its features, its buffering from the system and from the format, its > > indexing, its module fetching and storing, etc. > > > >> ______________________ > >> > >> > >> And finally, if bullets aren't flying already, I'll stir the heat up > with... > >> > >> XSLT sucks. A good C++ programmer can do anything in C++ better than > >> any XSLT programmer. > >> > >> > >> :) > > > > A C++ programmer can definitely do more, since C++ is actually a > > programming language and XSLT is a set of processing instructions. > > Better? That depends on what the criteria is. For me, in my current > > role as a module creator, the use of C++ is not currently better > > because it is less flexible and extensible. For you, as the library > > maintainer, perhaps C++ is better because it's what you are already > > comfortable with and because it has largely been your hand in the > > filters. > > > >> > >> *duck* > >> Have fun. > >> > >> Troy > >> > >> PS. In summary, I understand the current filters are sometimes overly > >> complex and need cleanup, standardization, etc. It comes down to the > >> fact that they mostly work, and other things which don't get priority, > >> so they don't get much attention. But honestly, I think one might be > >> oversimplifying the problem at hand without realizing it, if one simply > >> thinks switching to XSLT will make things easier. > > > > I think one is also oversimplifying the options. My dreamlist is that > > SWORD produce a well-formed, valid, complete OSIS document for an > > arbitrary KeyList that I pass it with FMT_OSIS set. That basically > > boils down to getting the *OSIS filters up to snuff and standardized. > > The second item on the list is a readily extensible mechanism for > > SWORD outputting HTML from that OSIS. If that choice is providing an > > XSL stylesheet with the library, a C++ SAX processor that a front-end > > can readily extend, a DOM interface that can be easily customized is > > immaterial to me. I like all three of those, and can easily > > understand and extend all of them. > > > > I think any of those technologies would be an improvement over all > > in-house C++ for the second half of any such processing. If we are > > using XML in Open Source Software, let's leverage the work of others > > who have happily given us permission to use their libraries! > > > > --Greg > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101201/c573ccfd/attachment-0001.html> From karl at kleinpaste.org Wed Dec 1 05:58:02 2010 From: karl at kleinpaste.org (Karl Kleinpaste) Date: Wed, 01 Dec 2010 07:58:02 -0500 Subject: [sword-devel] Config file for thml module In-Reply-To: <4CF57AEA.5090001@crosswire.org> (Chris Little's message of "Tue, 30 Nov 2010 14:30:02 -0800") References: <AANLkTimXhEr51QRu8kpYOUo1zzAsjWSwrbxEeR1chVmy@mail.gmail.com> <Pine.LNX.4.44.1011291854140.28824-100000@suneidesis> <AANLkTinJ8bSgwSXC2jRz6wk1FZaZLmON55_kKPuoXF+q@mail.gmail.com> <4CF47F50.6030804@crosswire.org> <AANLkTi=5mhqruXejFVrGkiVmvE4bmg3jHOP_rAaadLhL@mail.gmail.com> <4CF57AEA.5090001@crosswire.org> Message-ID: <vxkr5e1ejl1.fsf@awol.kleinpaste.org> Chris Little <chrislit at crosswire.org> writes: > I really wouldn't say that the collective output of people producing > content in ThML for the Xiphos repository has any chance of countering the > trend of OSIS/TEI content produced for CrossWire (numerically speaking). It is not and never was any kind of competition. It is simply the objective fact that ThML is preferred for a lot of really very good reasons in rather a lot of cases, and it's not going away. Some non-trivial number of us continue to use ThML because It Just Works in ways that OSIS seems unlikely ever to achieve. From jonmmorgan at gmail.com Wed Dec 1 06:40:32 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Thu, 2 Dec 2010 00:40:32 +1100 Subject: [sword-devel] Markup Options In-Reply-To: <vxkipzesqwz.fsf@awol.kleinpaste.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <vxkipzesqwz.fsf@awol.kleinpaste.org> Message-ID: <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> From dfhmch at googlemail.com Wed Dec 1 07:05:38 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 1 Dec 2010 06:05:38 -0800 (PST) Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <4CF63DA3.4030306@crosswire.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTi=sDGZzwzAzmnuv24rgHw7gL0F78PD5RyorVzmL@mail.gmail.com> <4CF63DA3.4030306@crosswire.org> Message-ID: <1291212338801-3067336.post@n4.nabble.com> Troy, "I'll attempt to post a few easy to swallow SWORD 101 classes in email, which will help us gather our thoughts and documents on how all this works. " Why not straight to the http://crosswire.org/wiki/ wiki ? David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Markup-Options-was-Re-Config-file-for-thml-module-tp3065508p3067336.html Sent from the SWORD Dev mailing list archive at Nabble.com. From jonmmorgan at gmail.com Wed Dec 1 07:13:53 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Thu, 2 Dec 2010 01:13:53 +1100 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <4CF54BBC.7080301@crosswire.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> Message-ID: <AANLkTim0Tj4knNEKP1ibeHy1SyCg4oodTetK02Q8U4hK@mail.gmail.com> 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). 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. 3. It allows developers to use sources that are outside the document being transformed. This has had some issues for us (from memory, the filter code isn't re-entrant), but we use this functionality to do things like expanding a list of cross-references in the user's locale, looking up the headwords for Strong's Numbers, and looking up the text in the current version for a passage in a harmony. By contrast, unless we have some good way to call into C++/Python from XSLT we will not be able to use sources outside the current document unless we do some complex post-processing. If we do have such a way it could just increase complexity. 4. It allows us to share common functionality between the ThML filters and the OSIS filters (which we do). I think this proposal would have us still using C++ ThML filters while moving the OSIS filters to XSLT, which would make the results further apart. 5. I would be concerned if performance dropped at all, as I suspect it would (especially if calls into C++ were involved as well). 6. Currently our rendering works on a verse-by-verse basis. I'm not sure what it would look like if we were trying to do something like a chapter at once. Do we run through the chapter in one go? What kind of well formed OSIS document can we get from a single verse or collection of verses to pass into an XSLT? Is there much cost to fire up an XSLT engine just for the one verse we have in our search preview? What would you do if you wanted to have a discontinuous range of verses or to show versions in parallel verse-by-verse? We also surround each verse and a rendered section with other extra stuff which varies depending on the context. I'm not sure where this would fit in the XSLT (if at all). In short, as a BPBible developer I much prefer implementation in C++ because it allows us to do things we want to do much more easily than with XSLT (though if Troy or anyone else wants to improve the present implementation they are welcome to). I cannot speak for the pros and cons from a module creator point of view. Jon On Wed, Dec 1, 2010 at 6:08 AM, Troy A. Griffitts <scribe at crosswire.org>wrote: > Having finally returned from a hectic 2 weeks of conferences, and lots > to do before leaving for Christmas, I'm not sure I'm up for a heated, > passionate debate about technologies right now, but by all means, please > commence the public discussion. > > Let me start by saying that everyone (I believe) agrees that we would > like to have an HTML output from the engine which is more generic and > would allow CSS to be applied if a frontend would like to do this. > Currently HTMLHREF output from the engine is used by the widest number > of frontends (to my knowledge) and would benefit everyone involved by > becoming much more generic. e.g., > > <title> -> <h1> > rather than > <title> -> <b><br /> > > <transChange type="added"> -> <span class="tcAdded"> > rather than > <transChange type="added"> -> <i> > > etc. > > I believe this will solve a number of issues and possibly get the BT and > MacSword teams onboard to using the same HTML output filters as the > other projects involve (or at least subclassing them and using the > majority of their functionality). > > > Now, as to the other issue of using XSLT internally in the engine to > process OSIS -> HTML > > I will throw a few melons into the air for target practice, and let the > shooting commence. > > _____________________________ > *Multiple Language* > > XSLT is a programming language in the same sense that C++ is a > programming language. > > The SWORD Project C++ engine is written in C++. It is not a Python > engine; it is not a Perl engine; it is not a Java engine; it is C++. > > One might say, "Well, you can use XSLT from C++. Doesn't JSword do this > from Java?" Well, yes, of course you can, and DM can comment, if he > feels the desire to recommend his decision to encorporate an XSLT engine > into the JSword logic flow. But simply because one CAN doesn't mean one > SHOULD. We COULD encorporate a Perl text processing engine in our C++ > code, or an Awk processing engine... that doesn't mean we SHOULD. I'm > sure some would say we SHOULD. And obviously DM has thought he SHOULD > encorporate XSLT processing for JSword, so I'm not intending to say it > is a BAD decision, just that it is not a decision I would make; in the > same way as our projects each chose C++ vs. Java to implement our > objective. > > _______________________ > *XSLT better than C++* > > One might say, "well, XSLT is better suited to process XML than C++." > That's a loaded and unquantified statement. > > Certainly the C++ language specification doesn't include facilities to > easily process XML, but that doesn't mean a plethora of C++ libraries > don't exists for assisting in this task. > > The SWORD engine includes classes like XMLTag and SWBasicFilter which > implement a SAX processing model. > > The current filters do not all use SWBasicFilter, nor XMLTag. They've > been written over 15 years and many before these classes existed. Some > are ugly and need to be rewritten for readability, certainly. But not > necessarily in a different programming language. > > ________________________ > *COMPLEXITY* > > The task of enumerating all types of OSIS <title> tags, and deciding > what to do with each, and how to classify all <title> tags from all > possible OSIS documents into our enumeration is still going to be a > complex task using XSLT. <title> is a complex example, but certainly > not the most complex. > > It is a tall task to generalize all elements of all documents from all > publishers into one conceptual model with one chosen output for a > frontend-- whether that be for an audience on the Desktop, web-based, or > a handheld. > > The complex processing required by the engine will require long, complex > XSLT-- which likely will encorporate callbacks to C++. It will not be > more simple-- only mixed language. > _______________________ > *Semantic vs. Display* > > Some will say (and have), "well, let everything be display oriented and > let the publisher decide". Fine, then you lose 2 things: the ability to > display differently per user preference, per display device; and you > also give up the promise to actually do any interesting research on the > text. When you lose semantic markup, then you lose all interesting > information about WHAT is being marked up. > > _______________________ > *More than a Rending Engine* > > The SWORD C++ Engine is more than simply a text rendering engine-- it is > a Biblical text research engine. > > If I'd like to know the morphology of word 3 in 2Thes 2.13 of the WHNU > Greek text, the entire program to do such is: > > SWMgr library; > SWModule *whnu = library.getModule("WHNU"); > whnu->setKey("2th.2.13"); > whnu->RenderText(); > > cout << "The morphology of word three is: " << > whnu->getEntryAttributes()["Word"]["003"]["Morph"] << endl; > > > That reads nice (at least in my opinion). I don't need to know about > XML, XSLT, care what markup the WHNU module uses, I don't even have to > know how to make a SWORD filter. The current filters do all the work of > breaking out these attributes and making them available in a nice and > interesting map. > > ______________________ > > > And finally, if bullets aren't flying already, I'll stir the heat up > with... > > XSLT sucks. A good C++ programmer can do anything in C++ better than > any XSLT programmer. > > > :) > > *duck* > Have fun. > > Troy > > PS. In summary, I understand the current filters are sometimes overly > complex and need cleanup, standardization, etc. It comes down to the > fact that they mostly work, and other things which don't get priority, > so they don't get much attention. But honestly, I think one might be > oversimplifying the problem at hand without realizing it, if one simply > thinks switching to XSLT will make things easier. > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/c3996a40/attachment-0001.html> From scribe at crosswire.org Wed Dec 1 07:29:10 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Wed, 01 Dec 2010 14:29:10 +0000 Subject: [sword-devel] Why You Should Love SWORD 101 - Text Processing Flow Message-ID: <4CF65BB6.3080204@crosswire.org> EXAMPLE TEXT PROCESSING FLOW ____________________ *Publisher's Document* / Chaos and Unrest / ____________________ | osis2mod v ____________________ *SWORD Storage* / Unrest / Markup normalized Document partitioned into user-referencable, tasty bite-sized chunks ____________________ | option filters v ____________________ *Stage 1 Processed* / Some Rest / Entity focused classes each have processed their 'concept': notes, lemma, crossref, etc. Interesting attributes registered to EntryAttributes map Some editorial decisions made, like removing inlining of notes, pre-verse headers Features turned on or off based on user preference ____________________ | render filters V ____________________ *HTML output* / Peace and Tranquility / Markup converted to HTML Where inlining was removed, the residual marker tags now have direct pointers back to their EntryAttributes section enabling the frontend to do what they'd like on events like hover-over ____________________ *NB: There are additional stages of processing: encoding stage, decipher stage, strip/normalize for search stage, etc., but this is a 100 level course. From dmsmith at crosswire.org Wed Dec 1 07:34:29 2010 From: dmsmith at crosswire.org (DM Smith) Date: Wed, 1 Dec 2010 09:34:29 -0500 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <4CF63DA3.4030306@crosswire.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTi=sDGZzwzAzmnuv24rgHw7gL0F78PD5RyorVzmL@mail.gmail.com> <4CF63DA3.4030306@crosswire.org> Message-ID: <5C668ADB-2191-4CE1-9BDB-DF4292BEDC05@crosswire.org> I like Plato's Chair analogy. But not the conclusions drawn from it. I think we all agree that some level of structural markup is necessary to identify: books, chapters, verses, titles, intros, words of Christ, footnotes, cross-references, and anything else we might want to treat specially beyond just presentation. I like deep structural markup that goes beyond what we currently use, e.g. markup of names and place names, so that we are not limited by what we have done, but what we can envision later. Some structural markup, such as poetry markup, today is used as merely presentational. As a result, it often is not structurally meaningful. This is a problem of the module maker creating something that looks nice but of which there is no value to software processing (e.g. getNextPoetryBlock() just won't get the desired results. The problem with the Plato's Chair analogy is that SWORD is not merely an idea, but *an* implementation of that chair. I'd say it looks rather like a 1980's dinette chair constructed of steel tubing and vinyl cushions. The biggest problem I see with the modules and the filters is that they are lossy and/or incomplete. I'll keep my remarks to the OSIS process as that is what I am most familiar, and since it is *a* chair, it is not too far removed from ThML's chair. Regarding the modules, of necessity, we transform BSP OSIS (aka Book, Section, Paragraph with verse markers) into BCV (Book, Chapter, Verse) without verse markers. (ThML, GBF, PlainText readily lend themselves to BCV directly. I'm going to guess that is *a* major motivation for ThML.) The purpose of osis2mod is to transform the publishers' chairs into SWORD's chairs. The shortcoming of using IMP or VPL to import OSIS (or any other module type) is that it bypasses such a transformation and puts the burden on the module maker to construct SWORD's chair directly. Regarding the filters, there is an agreement that they need help. The problem with the OSIS to HTML filters is that they are not written to display what is defined by the OSIS spec, but only what the filter author thought was important. Some examples: OSIS allows for a title to be within a title, that is, to have sub-titles. OSIS allows rich markup within titles, such as footnotes, cross-references, divine name, etc. OSIS allows for significant content between verses. Words of Christ in verses can be punctuated by other words. These were or are problematic to these filters. The second problem with these filters is that they are lossy. The filters only look for a subset of the OSIS tags and attributes. Examples: the "n" attribute on footnotes. Of the various types of <hi> bold is handled well, but everything else gets italic (line-through, acrostic, illuminated, small-caps, sub, super). Table, row and cell are ignored (these could easily be in genbooks). And lots more.... This is a community effort and we all have different skill sets. I'm particularly weak in doing C++ coding as I have been away from it for too long (I started with C++ 1.0 and moved to something else just before 3.0 was released). Otherwise, I'd have tackled the lossy-ness of the filters. As I look at the code, the essential part of the SWORD chair seems to be how it pulls out of line various components into easily addressed structures: titles, footnotes, ..... I've tried but I don't understand this at all. Within the osishtmlhref filter there are various notions that are necessary to understand but are entirely baffling to me: suspendTextPassThru, suspendLevel, lastSuspendSegment, supressAdjacentWhitespace, <!P>, <!/P>. So, if one were to write a new OSIS filter from scratch, I'd like to know what has to be done to meet/match SWORD's ideal chair. In Him, DM On Dec 1, 2010, at 7:20 AM, Troy A. Griffitts wrote: > The logic to get from any Publisher Source Document to rendered HTML is > a very complex task to solve. > > We conceptually create Plato's Form of, say, a Bible, and try to fit > imperfect Publisher markup into this concept. A Bible has verses, > headings between verses, chapter intros, footnotes, crossrefs, lemma > information, etc. > > If we do not do this, then we become a PDF reader-- there are already > PDF readers and we lose the ability to do Bible specific things with our > software. For example, if we didn't normalize the concept of crossref > across all Books, then we couldn't turn them on and off; we couldn't > provide a crossref panel in the reader which fills according to which > crossref is hovered over, etc. Same with notes, strongs, headings, etc. > > This causes us to impose our Form onto a publisher's text. I understand > why some people may not like this, but it is very much to our end users' > benefit that we do this. Without this, we become a web-browser or a PDF > reader. Which are fine for their purpose, but we intend to provide > common, familiar, and sometimes novel Bible study aides to our reader. > > The current processing model is dark magic and I apologize for this. It > should be well documented and easy to modify. I will attempt to improve > the dissemination of knowledge of exactly WHAT our Forms are, how we > impose those Forms on publishers' texts and improve the documentation > and code to help others understand and have the ability to improve the code. > > I'll attempt to post a few easy to swallow SWORD 101 classes in email, > which will help us gather our thoughts and documents on how all this works. > > > Troy > > > > On 12/01/2010 12:09 AM, Greg Hellings wrote: >> On Tue, Nov 30, 2010 at 1:08 PM, Troy A. Griffitts <scribe at crosswire.org> wrote: >>> Having finally returned from a hectic 2 weeks of conferences, and lots >>> to do before leaving for Christmas, I'm not sure I'm up for a heated, >>> passionate debate about technologies right now, but by all means, please >>> commence the public discussion. >>> >>> Let me start by saying that everyone (I believe) agrees that we would >>> like to have an HTML output from the engine which is more generic and >>> would allow CSS to be applied if a frontend would like to do this. >>> Currently HTMLHREF output from the engine is used by the widest number >>> of frontends (to my knowledge) and would benefit everyone involved by >>> becoming much more generic. e.g., >>> >>> <title> -> <h1> >>> rather than >>> <title> -> <b><br /> >>> >>> <transChange type="added"> -> <span class="tcAdded"> >>> rather than >>> <transChange type="added"> -> <i> >>> >>> etc. >>> >>> I believe this will solve a number of issues and possibly get the BT and >>> MacSword teams onboard to using the same HTML output filters as the >>> other projects involve (or at least subclassing them and using the >>> majority of their functionality). >> >> I think this is our pretty well accepted premise. The current filters >> stink to various degrees and currently no one is willing to step up >> and tackle them. >> >>> >>> >>> Now, as to the other issue of using XSLT internally in the engine to >>> process OSIS -> HTML >>> >>> I will throw a few melons into the air for target practice, and let the >>> shooting commence. >>> >>> _____________________________ >>> *Multiple Language* >>> >>> XSLT is a programming language in the same sense that C++ is a >>> programming language. >>> >>> The SWORD Project C++ engine is written in C++. It is not a Python >>> engine; it is not a Perl engine; it is not a Java engine; it is C++. >>> >>> One might say, "Well, you can use XSLT from C++. Doesn't JSword do this >>> from Java?" Well, yes, of course you can, and DM can comment, if he >>> feels the desire to recommend his decision to encorporate an XSLT engine >>> into the JSword logic flow. But simply because one CAN doesn't mean one >>> SHOULD. We COULD encorporate a Perl text processing engine in our C++ >>> code, or an Awk processing engine... that doesn't mean we SHOULD. I'm >>> sure some would say we SHOULD. And obviously DM has thought he SHOULD >>> encorporate XSLT processing for JSword, so I'm not intending to say it >>> is a BAD decision, just that it is not a decision I would make; in the >>> same way as our projects each chose C++ vs. Java to implement our objective. >> >> If a developer is going to develop OSIS -> HTML filters, for instance, >> we are already assuming they know OSIS and HTML. OSIS is XML and HTML >> is SGML (though most of our work is probably targetting a more >> XML-dialect of HTML). XSLT is also XML. Formally, it is not even a >> programming language, but just a set of formatting/processing >> instructions in XML. >> >> Any developer using XML who is worth their salt should at least be >> familiar with the basics of XSL - they may not be a guru of XPath >> expressions or have every attribute of XSL memorized - and would >> probably expect a library which handles XML as its preferred input >> method to utilize one of the standard XML processing methods. I know >> I'm not the only person who was surprised to look in the library >> filters and see neither DOM, SAX nor XSLT technologies in use. That >> was when I first ran and hid. >> >> Of course, this portion of the discussion is only relevant for the >> from-OSIS filters. >> >>> >>> _______________________ >>> *XSLT better than C++* >>> >>> One might say, "well, XSLT is better suited to process XML than C++." >>> That's a loaded and unquantified statement. >>> >>> Certainly the C++ language specification doesn't include facilities to >>> easily process XML, but that doesn't mean a plethora of C++ libraries >>> don't exists for assisting in this task. >>> >>> The SWORD engine includes classes like XMLTag and SWBasicFilter which >>> implement a SAX processing model. >>> >>> The current filters do not all use SWBasicFilter, nor XMLTag. They've >>> been written over 15 years and many before these classes existed. Some >>> are ugly and need to be rewritten for readability, certainly. But not >>> necessarily in a different programming language. >> >> XSLT being "better" is, yes, a matter of complete subjectivity. And, >> as I mentioned above, is only useful when our source is XML to begin >> with. For GBF or Plaintext sources, XSLT is clearly not even >> applicable. >> >> But the current C++ is so good that you seem the only person willing >> to touch it. Peter just mentioned he tried once and couldn't get it. >> I have gone into the filters before with a singular goal in mind and >> was able to produce my desired changes, but it was long, drawn-out and >> painful. Doing the same tasks in XSL would have taken me mere >> seconds. I know a few other people, at least, have said they would >> know how to do a task if XSLT was used instead of C++. Of course, >> that is a hypothetical - I can't know that they would have done so, >> but that was their claim at the time. >> >> Our recent discussion about the use of the "n" attribute for footnotes >> in ThML is a perfect example. Maintaining the attribute in XSL would >> have been a trivial task I could have handled in seconds. Instead, it >> required you, myself and Karl and took about 10 days to get fixed. >> You had to alert Karl and me to presence of the attributes, I provided >> him a preliminary patch to incorporate the values, then he had to >> heavily modify the patch to operate correctly in non-ThML source and a >> few other corner cases. And, in the end, the fix is only in Xiphos' >> code base - I would have to go through 2 of those three steps again in >> Bibletime, BPBible, MacSword and any other applications I wanted to >> see proper behavior in. Alternatively I could tackle the filters - >> but I'm not really inclined to do so. >> >> Is XSLT "better"? For me, it would be better because I could more >> easily modify its behavior based on the fact that I know XML and could >> easily locate the necessary processing directive. For you, maybe not. >> Are there things you simply cannot do in XSL that C++ can? Yes. IMO >> the benefits of XSL outweigh the benefits of C++ for this task, but >> you clearly disagree. :) I would also say that DOM or SAX processing >> would be better for all the same reasons - it shields the user from >> having to see the XML parsing and handle inconsistencies in >> whitespace, validation, etc and is still a decently well-known >> technology among XML users (even if it's slightly less well-known than >> XSL). And with a DOM or SAX parser, you could still happily employ >> the full power of C++. >> >>> >>> ________________________ >>> *COMPLEXITY* >>> >>> The task of enumerating all types of OSIS <title> tags, and deciding >>> what to do with each, and how to classify all <title> tags from all >>> possible OSIS documents into our enumeration is still going to be a >>> complex task using XSLT. <title> is a complex example, but certainly >>> not the most complex. >>> >>> It is a tall task to generalize all elements of all documents from all >>> publishers into one conceptual model with one chosen output for a >>> frontend-- whether that be for an audience on the Desktop, web-based, or >>> a handheld. >>> >>> The complex processing required by the engine will require long, complex >>> XSLT-- which likely will encorporate callbacks to C++. It will not be >>> more simple-- only mixed language. >> >> I could also argue that the XSL would not require a developer to >> mentally filter out the code that just identifies and locates XML >> elements and attributes and parses them from the code that transforms >> them and generates the output. Thus yes, it might include some >> extension functions into C++ but it would be simpler. And it would >> also be more expressive. >> >> The enumeration of every OSIS <title> tag is a moot point for the >> decision. You need to enumerate them all in C++ as well and decide >> what to do with them. That doesn't change in the XSL - just the >> method used. An XSL match along the lines of <xsl:template >> match="title[@type=psalm]"> still has to be done in C++ with some sort >> of if(tag.name() == "title && tag.attr("type") == "psalm") or whatever >> the syntax is. And that is assuming the current filter is using >> XMLTag and isn't comparing character strings directly. >> >>> _______________________ >>> *Semantic vs. Display* >>> >>> Some will say (and have), "well, let everything be display oriented and >>> let the publisher decide". Fine, then you lose 2 things: the ability to >>> display differently per user preference, per display device; and you >>> also give up the promise to actually do any interesting research on the >>> text. When you lose semantic markup, then you lose all interesting >>> information about WHAT is being marked up. >> >> I just want to be clear that I'm not advocating the use of display >> over semantics as a general choice. My statements are strictly based >> around my specific task and the fact that OSIS support in SWORD and >> the front ends is not as good as the support of ThML. Largely this is >> because most applications display in HTML and my required task is >> framed entirely in terms of the presentation and display - not the >> semantics. I would love and prefer to use OSIS for this task, but I >> simply cannot accomplish it with the state of SWORD at this time. >> >>> >>> _______________________ >>> *More than a Rending Engine* >>> >>> The SWORD C++ Engine is more than simply a text rendering engine-- it is >>> a Biblical text research engine. >>> >>> If I'd like to know the morphology of word 3 in 2Thes 2.13 of the WHNU >>> Greek text, the entire program to do such is: >>> >>> SWMgr library; >>> SWModule *whnu = library.getModule("WHNU"); >>> whnu->setKey("2th.2.13"); >>> whnu->RenderText(); >>> >>> cout << "The morphology of word three is: " << >>> whnu->getEntryAttributes()["Word"]["003"]["Morph"] << endl; >>> >>> >>> That reads nice (at least in my opinion). I don't need to know about >>> XML, XSLT, care what markup the WHNU module uses, I don't even have to >>> know how to make a SWORD filter. The current filters do all the work of >>> breaking out these attributes and making them available in a nice and >>> interesting map. >> >> I'd like to be clear again, that XSL would only be useful for material >> already in OSIS formats (or in valid ThML - I think TEI is also an XML >> format?). I doubt many modules in ThML are strictly valid at their >> import times, so XSL wouldn't be very useful, and GBF is a monster >> unto itself. Doing the above in XSL from an OSIS source would not be >> much different in complexity than what you have listed there. >> >> <xsl:template match="verse[@osisID='2thes.2.13']/w[@n=3]"> >> The morphology of word three is: <xsl:value-of select="@morph" /> >> </xsl:template> >> >> Or something similar (my knowledge of exact OSIS attribute names and >> values wanes and it's been two or three weeks since I wrote an XPath >> expression). >> >> Of course, the string processing portion of SWORD would continue to be >> of great importance for any modules in GBF format or similar to bring >> them into a useful form. In that way, SWORD would continue to be more >> than just a text rendering engine. It would continue to offer all of >> its features, its buffering from the system and from the format, its >> indexing, its module fetching and storing, etc. >> >>> ______________________ >>> >>> >>> And finally, if bullets aren't flying already, I'll stir the heat up with... >>> >>> XSLT sucks. A good C++ programmer can do anything in C++ better than >>> any XSLT programmer. >>> >>> >>> :) >> >> A C++ programmer can definitely do more, since C++ is actually a >> programming language and XSLT is a set of processing instructions. >> Better? That depends on what the criteria is. For me, in my current >> role as a module creator, the use of C++ is not currently better >> because it is less flexible and extensible. For you, as the library >> maintainer, perhaps C++ is better because it's what you are already >> comfortable with and because it has largely been your hand in the >> filters. >> >>> >>> *duck* >>> Have fun. >>> >>> Troy >>> >>> PS. In summary, I understand the current filters are sometimes overly >>> complex and need cleanup, standardization, etc. It comes down to the >>> fact that they mostly work, and other things which don't get priority, >>> so they don't get much attention. But honestly, I think one might be >>> oversimplifying the problem at hand without realizing it, if one simply >>> thinks switching to XSLT will make things easier. >> >> I think one is also oversimplifying the options. My dreamlist is that >> SWORD produce a well-formed, valid, complete OSIS document for an >> arbitrary KeyList that I pass it with FMT_OSIS set. That basically >> boils down to getting the *OSIS filters up to snuff and standardized. >> The second item on the list is a readily extensible mechanism for >> SWORD outputting HTML from that OSIS. If that choice is providing an >> XSL stylesheet with the library, a C++ SAX processor that a front-end >> can readily extend, a DOM interface that can be easily customized is >> immaterial to me. I like all three of those, and can easily >> understand and extend all of them. >> >> I think any of those technologies would be an improvement over all >> in-house C++ for the second half of any such processing. If we are >> using XML in Open Source Software, let's leverage the work of others >> who have happily given us permission to use their libraries! >> >> --Greg >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 From greg.hellings at gmail.com Wed Dec 1 07:51:07 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 1 Dec 2010 08:51:07 -0600 Subject: [sword-devel] Markup Options In-Reply-To: <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <vxkipzesqwz.fsf@awol.kleinpaste.org> <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> Message-ID: <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> On Wed, Dec 1, 2010 at 7:40 AM, Jonathan Morgan <jonmmorgan at gmail.com> wrote: > From an application developer's point of view, I'm not convinced that per > module CSS is a good idea.? Here are some reasons: > 1. I'm not convinced of "well-defined use of HTML+CSS classes".? Some things > may be well-defined, but I know BPBible does a lot of customisation of the > SWORD generated HTML and uses a lot of custom CSS, and some or all of these > things might break CSS designed for other apps (and vice versa).? I also do > not like the idea that my changes to either the HTML generated or the CSS > breaks the display of a module I have never seen. 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. 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. > > 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. I remember Jaak voicing this complaint when I brought up CSS stylesheets in BibleTime. This is actually an argument FOR having external stylesheets. I don't see why either of you would think our case is any different from a web browser in this regard. CSS was designed specifically to handle exactly the situation you bring up. In web browsers styles will cascade downwards with earlier styles overwriting later ones in the following order: 1) User-Agent stylesheet 2) External stylesheets 3) Internal stylesheets 4) Inline styles Often times a user can insert their own styles for accessibility reasons and I believe those are usually placed at priority 3.5 in that list. Currently SWORD applications only support (1) and (4). BibleTime's offer of themes simply changes the values of the User-Agent stylesheet. My first attempt at creating SWORD modules way back when I thought that (2) and (3) would be supported since the library documentation claimed to support ThML, but it ends up the entire header of the document gets thrown away during import but inline styles remain intact. As a result, (3) would be difficult to handle in SWORD without major changes to the entire library and import system but (2) would be very easy to add simply by honoring a config option. Since the stylesheets within each level cascade with later ones overriding earlier ones, in order to maintain the specified order, the following in the HTML header would be all that is required: <link rel="stylesheet" type="text/css" href="/usr/share/bpbible/css/default.css" /> <link rel="stylesheet" type="text/css" href="modules/ztext/mymodule/css/module.css" /> <link rel="stylesheet" type="text/css" href="~/.bpbible/css/user-overrides.css" /> 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? Currently the only way to get styles through to the display layer are through number 4 - inline styles. As it is, I can already mess with every one of those settings you're worried about me messing up and the user can do nothing about it (unless, of course, BPBible strips the style attribute from ThML sources). So by providing me the ability to set an external stylesheet, you would actually be fixing what is currently a usability bug in apps. Thus both you and Jaak are correct to worry about this issue, but the result of your worrying should be to enable external styles not disable them. > > 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. Of course, this depends on how you allow styles to be defined. I think, again, this is actually an argument _for_ having external styles available for each module. Currently I can only put my styles inline on an element. Therefore no matter what you do, without stripping off the style attribute, I can easily break the display of your parallel Bibles. If I were permitted an external stylesheet which I could apply to well defined HTML classes, then the user-agent could decide what to do based on its own method for parallel display. BibleTime, IIRC, uses a <table> with each verse in a new <tr> and each version displayed side-by-side within a <td>. It is likely that BibleTime would simply not include the external stylesheet of either module at this point; alternatively they could be included in some deterministic order - reverse order of their addition to the display, for instance, that way the version which has been there longest takes precedence. If a display were using a frameset or iframes, then it might opt to include the stylesheets. 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). Of course all of this ignores BibleCS, which I personally don't mind. But it probably doesn't honor inline styles any more than external styles, so I have no interest in it. :) --Greg From greg.hellings at gmail.com Wed Dec 1 08:19:23 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 1 Dec 2010 09:19:23 -0600 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <AANLkTim0Tj4knNEKP1ibeHy1SyCg4oodTetK02Q8U4hK@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTim0Tj4knNEKP1ibeHy1SyCg4oodTetK02Q8U4hK@mail.gmail.com> Message-ID: <AANLkTi=3GdojiO+DMNpj0ba5V2kgxNfyyKdSNiJZUbuf@mail.gmail.com> On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan <jonmmorgan at 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. > > 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. In XSLT I can import another XSL file and provide overrides - no need to merge in changes from someone else and maintain identical copies, etc. When I'm creating my current set of modules I have 2 XSL files that go from the proprietary SGML to HTML and ThML. Obviously there is a lot of overlap between those two. The ThML stylesheet simply imports the HTML stylesheet and overrides a few of the templates to produce <scripRef> and other ThML-specific elements. That way, if there is a bug in how I translate a table display, for instance, I can change it in the HTML stylesheet and I get the fix for free in my ThML without touching anything. SAX is simply an API in any desired language. If I want to override the behavior of a single element, I just override the processing method and check something like if(is element to override) doOverride(); else callSuperclassMethod(); All the discussion for XSL above applies to SAX processing as well. > > 3. It allows developers to use sources that are outside the document being > transformed.? This has had some issues for us (from memory, the filter code > isn't re-entrant), but we use this functionality to do things like expanding > a list of cross-references in the user's locale, looking up the headwords > for Strong's Numbers, and looking up the text in the current version for a > passage in a harmony.? By contrast, unless we have some good way to call > into C++/Python from XSLT we will not be able to use sources outside the > current document unless we do some complex post-processing.? If we do have > such a way it could just increase complexity. A SAX model, of course, is able to handle the full range of what your programming language of choice has, so you're all set there. XSL has many ways of bringing in data from the outside. Arguements and variables can be passed in by the caller (man xsltproc and you'll see the argument --param PARAMNAME PARAMVALUE. Programmatic invocation of XSL can use the same parameter mechanism), values can be pulled out of static XML files which the XSL can include, and there is a rather straightforward way of creating custom functions in your invoking language. When I am using XSL to parse my SGML files, I have a number of custom functions written in Python which I invoke from XSL to do any type of processing raw XSL can't handle (example: transforming inline RTF styles into inline CSS styles). Increasing complexity? That really depends on the methods used and whether they are appropriate. > > 4. It allows us to share common functionality between the ThML filters and > the OSIS filters (which we do).? I think this proposal would have us still > using C++ ThML filters while moving the OSIS filters to XSLT, which would > make the results further apart. The same can be done with XSL simply be factoring the shared functionality into a single stylesheet which the ThML and OSIS-specific stylesheets include. SAX... well, I think you get the idea there. > > 5. I would be concerned if performance dropped at all, as I suspect it would > (especially if calls into C++ were involved as well). Calls into the parent language don't really slow down XSL unless they invoke a method which is excruciatingly slow. Of course, no one really has implementations of both technologies currently in place for us to compare SWORD's performance at present. apt-cache showpkg libxml2 shows me around 1000 libraries and applications in Ubuntu which currently depend directly on libxml2 including things as diverse as Pidgin, PHP, Postgres, VMWare, rpm2html, strigi, nautilus, Gnome, gstreamer, abiword, xscreensaver and so on. Performance of that library is apparently good enough for some people. There are even two sets of bindings in Python (python-libxml2 and python-lxml) both of which I have used with great success. To give an idea of how quickly it processes, I am able to load, parse, render and write out XML files up to a few megs each faster than my harddrive can keep up. And that is using the Python bindings and XSL - both of which are slower than directly invoking a SAX processor through C or C++. Slower than SWORD's filters? Maybe - I don't know how to directly test that at present. Slow enough to matter, especially for the size of a chapter or even just a single book? Definitely not. > > 6. Currently our rendering works on a verse-by-verse basis.? I'm not sure > what it would look like if we were trying to do something like a chapter at > once.? Do we run through the chapter in one go?? What kind of well formed > OSIS document can we get from a single verse or collection of verses to pass > into an XSLT?? Is there much cost to fire up an XSLT engine just for the one > verse we have in our search preview?? What would you do if you wanted to > have a discontinuous range of verses or to show versions in parallel > verse-by-verse?? We also surround each verse and a rendered section with > other extra stuff which varies depending on the context.? I'm not sure where > this would fit in the XSLT (if at all). Creating a wellf-formed and valid OSIS document for a single verse, chapter, book or the entire work is no different. Create the header, add the verses, write the footer. JSword already does it. And then the XSL knows how to handle each element it encounters - a SAX processor would need to be so programmed if that was selected instead - with no real care for whether it is seeing one verse or 50,000 of them. Discontinuous is also no problem. As well as the document is well formed and valid, the XML processing can handle it. --Greg From benpmorgan at gmail.com Wed Dec 1 08:25:09 2010 From: benpmorgan at gmail.com (Ben Morgan) Date: Thu, 2 Dec 2010 02:25:09 +1100 Subject: [sword-devel] Markup Options In-Reply-To: <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <vxkipzesqwz.fsf@awol.kleinpaste.org> <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> Message-ID: <AANLkTi=ATkZLPca6phvJrhE8xxoqeqAZtpO95HNyq1jx@mail.gmail.com> Hi Greg, On Thu, Dec 2, 2010 at 1:51 AM, Greg Hellings <greg.hellings at gmail.com>wrote: > > 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 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. 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/da9c6db9/attachment.html> From benpmorgan at gmail.com Wed Dec 1 08:42:00 2010 From: benpmorgan at gmail.com (Ben Morgan) Date: Thu, 2 Dec 2010 02:42:00 +1100 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <AANLkTi=3GdojiO+DMNpj0ba5V2kgxNfyyKdSNiJZUbuf@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTim0Tj4knNEKP1ibeHy1SyCg4oodTetK02Q8U4hK@mail.gmail.com> <AANLkTi=3GdojiO+DMNpj0ba5V2kgxNfyyKdSNiJZUbuf@mail.gmail.com> Message-ID: <AANLkTikcLJPUSCCmKcYd6sQqmZQtARrAcm45EMWTg+kS@mail.gmail.com> Hi Greg, On Thu, Dec 2, 2010 at 2:19 AM, Greg Hellings <greg.hellings at gmail.com>wrote: > On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan <jonmmorgan at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/2d1e359c/attachment-0001.html> From refdoc at gmx.net Wed Dec 1 09:29:21 2010 From: refdoc at gmx.net (Peter von Kaehne) Date: Wed, 01 Dec 2010 17:29:21 +0100 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <5C668ADB-2191-4CE1-9BDB-DF4292BEDC05@crosswire.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTi=sDGZzwzAzmnuv24rgHw7gL0F78PD5RyorVzmL@mail.gmail.com> <4CF63DA3.4030306@crosswire.org> <5C668ADB-2191-4CE1-9BDB-DF4292BEDC05@crosswire.org> Message-ID: <20101201162921.12060@gmx.net> > So, if one were to write a new OSIS filter from scratch, > I'd like to know what has to be done to meet/match SWORD's ideal chair. I think the single most relevant requirement is easy expandability. I am looking - totally different example - at usfm2osis.pl and about 180 or so lines are now mine. But I would not have been able to do anything with it in its old form. Since Chris rewrote it, commented it extensively and made it alotgether a logical affair it is so easy to add whenever I find a USFM tag unsupported/poorly supported to just ad a line or ten. If the filtyers were ever at that place - I would be delighted. -- GRATIS! Movie-FLAT mit ?ber 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome From dmsmith at crosswire.org Wed Dec 1 11:08:56 2010 From: dmsmith at crosswire.org (DM Smith) Date: Wed, 01 Dec 2010 13:08:56 -0500 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <4CF63DA3.4030306@crosswire.org> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> <AANLkTi=sDGZzwzAzmnuv24rgHw7gL0F78PD5RyorVzmL@mail.gmail.com> <4CF63DA3.4030306@crosswire.org> Message-ID: <4CF68F38.9040303@crosswire.org> Not so much regarding Troy's comment about Plato's Form. Rather about the model that JSword uses. It is meant for illumination. JSword converts ThML, GBF, PlainText and OSIS on a verse by verse basis into well-defined fragments of XML. These fragments use the tags of OSIS, but might not produce a valid fragment. For ease of explanation, we say that it is converted into OSIS. If for some reason a verse in ThML or OSIS is not well-formed, it is hacked by successively stripping out xml parts until it parses or until only the text remains. This hack is rather unfortunate and should be removed or improved. E.g. notes and xrefs should never be inlined as plain text if they are marked up properly. Though it can, JSword does not use XSLT on a verse by verse basis to render a verse. Rather it gathers all the verses as XML fragments into an XML document. Typically this is a chapter of verses, but it might also be the set of verses returned from a search result, specified by the user, or given as a cross-reference. JSword will also collect verses from several modules into the document for parallel display. It is this document that is rendered. How this document is rendered is up to the application. It could use SAX. It could walk the DOM. But Bible Desktop uses XSLT and many other JSword front-ends do so as well. In answer to an earlier question, the XSLT is read once and reused for all rendering of modules. It is way to expensive to do this frequently. Once per run or only when the underlying file changes is sufficient. An aspect that JSword dictates on a processor of the document. All rendering/filtering happens within it. The BD style sheet is parametrized for each render option. Using these it shows/hides notes, xrefs, strongs, and morph; does verse per line; changes in the representation of the verse number; and so forth. There are several values in rendering a chapter as a whole. There are many constructs that can include more than one verse. One can start a tag in the middle of one verse and close it in another. If one only rendered verse-by-verse the start and end might not be matched up correctly. For example, SWORD's osishtmlhref filter has a quote stack and a highlight stack. If a quote starts in one verse and ends in another, the stack is reset going from one verse to another. So the quote marks might not match up. (Note: osis2mod is aware of this shortcoming and adjusts for it. However, if the module maker uses imp2mod or vpl2mod it can happen). For the <hi> tag when an opening tag is found, it is pushed on a stack (allowing for nesting). When an end tag is found, the stack is consulted to see what it was the start tag was. If it were bold then it closes bold, otherwise it closes italics. However, if the stack is empty, it closes italics. This spanning problem affects JSword's rendering of a collection of arbitrary verses. A tag can be open in one verse, but because the verse is not show in context, it is never closed. There is also an advantage of using XSLT over SAX, it is not limited to a single pass of the document. For example, this is used in Bible Desktop to show margin notes. Regarding TEI, JSword pretends it is OSIS. This is not a far stretch since OSIS was influenced by TEI. The XSLT has a few entries to be able to display key elements. Since TEI is rather open, and in flux, not all of what we will use will be found in it. I haven't looked at it but Chris has a TEI schema he uses for validation. That could be used to improve the XSLT or for TEI modules to have their own XSLT. Regarding ThML, JSword would do well to not convert it to OSIS but have XSLT for it as well. Regarding the speed of XSLT vs SAX vs SWORDs renderers. Except for handhelds (pda, phone, ...) it is a moot point. I figure that 5-6 years is the maximum useful lifespan of a computer. The processing power of a computer in these years, even a netbook, is sufficient to run XSLT fast enough over a chapter's worth of verses to satisfy end users. I have an old 486, Windows 98 laptop with limited memory that runs it acceptably. Even my OLPC (one laptop per child) is fast enough. Beyond JSword and how it could be used in SWORD with out much change to the current library: I'm not sure, but I think any SWORD front-end can try out XSLT if they like on OSIS documents using the osisosis.cpp filter. The filter does not attempt to do too much except reconstruct verses. It might need to be modified to output milestoned verse markers instead of the begin/end tags it does now. Using begin/end tags makes the assumption that a verse is a well-formed fragment. Just use it to "render" a chapter and then pass that chapter to xslt. I'm hearing that lots of people won't seriously look at XSLT. It has a steep but short learning curve. Kind of like Perl. There are two basic programming models using XSLT: one that understands the containment model of the schema. The other handles the tags as they appear, not caring whether the document is structured correctly. They have their pros and cons. (BD's XSLT uses the latter model.) But there are more and more systems that are using xpath notation and people are becoming more familiar with it. I think the audience of users that fairly easily buy into XSLT are those that work with XML and DOM all the time. This includes web developers. As more and more of our front-ends are targeting browser engines for display, it is or will become feasible for the transformation to be done directly by the browser. Today, all current browsers (IE, FireFox, Safari, Chrome, WebKit, Opera) can directly do the transformations. For an example see: http://www.w3schools.com/XSL/xsl_transformation.asp I imagine it is possible, but I don't know how to pass parameters to the stylesheet when done this way. I don't know if it works with embedded browsers (xulrunner, webkit, ie), but I'd guess it does. There may be no need for SWORD to have html render filters. Just transform the module into well-formed xml, feed it to a browser along with a stylesheet. Some things are hard to do in XSLT. Some are not possible/feasible. Some are way too slow. So there will always be a need for a pre-processor to do some up front work. Or for the XSLT to call out to another program. Hope this is helpful. In Him, DM On 12/01/2010 07:20 AM, Troy A. Griffitts wrote: > The logic to get from any Publisher Source Document to rendered HTML is > a very complex task to solve. > > We conceptually create Plato's Form of, say, a Bible, and try to fit > imperfect Publisher markup into this concept. A Bible has verses, > headings between verses, chapter intros, footnotes, crossrefs, lemma > information, etc. > > If we do not do this, then we become a PDF reader-- there are already > PDF readers and we lose the ability to do Bible specific things with our > software. For example, if we didn't normalize the concept of crossref > across all Books, then we couldn't turn them on and off; we couldn't > provide a crossref panel in the reader which fills according to which > crossref is hovered over, etc. Same with notes, strongs, headings, etc. > > This causes us to impose our Form onto a publisher's text. I understand > why some people may not like this, but it is very much to our end users' > benefit that we do this. Without this, we become a web-browser or a PDF > reader. Which are fine for their purpose, but we intend to provide > common, familiar, and sometimes novel Bible study aides to our reader. > > The current processing model is dark magic and I apologize for this. It > should be well documented and easy to modify. I will attempt to improve > the dissemination of knowledge of exactly WHAT our Forms are, how we > impose those Forms on publishers' texts and improve the documentation > and code to help others understand and have the ability to improve the code. > > I'll attempt to post a few easy to swallow SWORD 101 classes in email, > which will help us gather our thoughts and documents on how all this works. > > > Troy > > > > On 12/01/2010 12:09 AM, Greg Hellings wrote: >> On Tue, Nov 30, 2010 at 1:08 PM, Troy A. Griffitts<scribe at crosswire.org> wrote: >>> Having finally returned from a hectic 2 weeks of conferences, and lots >>> to do before leaving for Christmas, I'm not sure I'm up for a heated, >>> passionate debate about technologies right now, but by all means, please >>> commence the public discussion. >>> >>> Let me start by saying that everyone (I believe) agrees that we would >>> like to have an HTML output from the engine which is more generic and >>> would allow CSS to be applied if a frontend would like to do this. >>> Currently HTMLHREF output from the engine is used by the widest number >>> of frontends (to my knowledge) and would benefit everyone involved by >>> becoming much more generic. e.g., >>> >>> <title> -> <h1> >>> rather than >>> <title> -> <b><br /> >>> >>> <transChange type="added"> -> <span class="tcAdded"> >>> rather than >>> <transChange type="added"> -> <i> >>> >>> etc. >>> >>> I believe this will solve a number of issues and possibly get the BT and >>> MacSword teams onboard to using the same HTML output filters as the >>> other projects involve (or at least subclassing them and using the >>> majority of their functionality). >> I think this is our pretty well accepted premise. The current filters >> stink to various degrees and currently no one is willing to step up >> and tackle them. >> >>> >>> Now, as to the other issue of using XSLT internally in the engine to >>> process OSIS -> HTML >>> >>> I will throw a few melons into the air for target practice, and let the >>> shooting commence. >>> >>> _____________________________ >>> *Multiple Language* >>> >>> XSLT is a programming language in the same sense that C++ is a >>> programming language. >>> >>> The SWORD Project C++ engine is written in C++. It is not a Python >>> engine; it is not a Perl engine; it is not a Java engine; it is C++. >>> >>> One might say, "Well, you can use XSLT from C++. Doesn't JSword do this >>> from Java?" Well, yes, of course you can, and DM can comment, if he >>> feels the desire to recommend his decision to encorporate an XSLT engine >>> into the JSword logic flow. But simply because one CAN doesn't mean one >>> SHOULD. We COULD encorporate a Perl text processing engine in our C++ >>> code, or an Awk processing engine... that doesn't mean we SHOULD. I'm >>> sure some would say we SHOULD. And obviously DM has thought he SHOULD >>> encorporate XSLT processing for JSword, so I'm not intending to say it >>> is a BAD decision, just that it is not a decision I would make; in the >>> same way as our projects each chose C++ vs. Java to implement our objective. >> If a developer is going to develop OSIS -> HTML filters, for instance, >> we are already assuming they know OSIS and HTML. OSIS is XML and HTML >> is SGML (though most of our work is probably targetting a more >> XML-dialect of HTML). XSLT is also XML. Formally, it is not even a >> programming language, but just a set of formatting/processing >> instructions in XML. >> >> Any developer using XML who is worth their salt should at least be >> familiar with the basics of XSL - they may not be a guru of XPath >> expressions or have every attribute of XSL memorized - and would >> probably expect a library which handles XML as its preferred input >> method to utilize one of the standard XML processing methods. I know >> I'm not the only person who was surprised to look in the library >> filters and see neither DOM, SAX nor XSLT technologies in use. That >> was when I first ran and hid. >> >> Of course, this portion of the discussion is only relevant for the >> from-OSIS filters. >> >>> _______________________ >>> *XSLT better than C++* >>> >>> One might say, "well, XSLT is better suited to process XML than C++." >>> That's a loaded and unquantified statement. >>> >>> Certainly the C++ language specification doesn't include facilities to >>> easily process XML, but that doesn't mean a plethora of C++ libraries >>> don't exists for assisting in this task. >>> >>> The SWORD engine includes classes like XMLTag and SWBasicFilter which >>> implement a SAX processing model. >>> >>> The current filters do not all use SWBasicFilter, nor XMLTag. They've >>> been written over 15 years and many before these classes existed. Some >>> are ugly and need to be rewritten for readability, certainly. But not >>> necessarily in a different programming language. >> XSLT being "better" is, yes, a matter of complete subjectivity. And, >> as I mentioned above, is only useful when our source is XML to begin >> with. For GBF or Plaintext sources, XSLT is clearly not even >> applicable. >> >> But the current C++ is so good that you seem the only person willing >> to touch it. Peter just mentioned he tried once and couldn't get it. >> I have gone into the filters before with a singular goal in mind and >> was able to produce my desired changes, but it was long, drawn-out and >> painful. Doing the same tasks in XSL would have taken me mere >> seconds. I know a few other people, at least, have said they would >> know how to do a task if XSLT was used instead of C++. Of course, >> that is a hypothetical - I can't know that they would have done so, >> but that was their claim at the time. >> >> Our recent discussion about the use of the "n" attribute for footnotes >> in ThML is a perfect example. Maintaining the attribute in XSL would >> have been a trivial task I could have handled in seconds. Instead, it >> required you, myself and Karl and took about 10 days to get fixed. >> You had to alert Karl and me to presence of the attributes, I provided >> him a preliminary patch to incorporate the values, then he had to >> heavily modify the patch to operate correctly in non-ThML source and a >> few other corner cases. And, in the end, the fix is only in Xiphos' >> code base - I would have to go through 2 of those three steps again in >> Bibletime, BPBible, MacSword and any other applications I wanted to >> see proper behavior in. Alternatively I could tackle the filters - >> but I'm not really inclined to do so. >> >> Is XSLT "better"? For me, it would be better because I could more >> easily modify its behavior based on the fact that I know XML and could >> easily locate the necessary processing directive. For you, maybe not. >> Are there things you simply cannot do in XSL that C++ can? Yes. IMO >> the benefits of XSL outweigh the benefits of C++ for this task, but >> you clearly disagree. :) I would also say that DOM or SAX processing >> would be better for all the same reasons - it shields the user from >> having to see the XML parsing and handle inconsistencies in >> whitespace, validation, etc and is still a decently well-known >> technology among XML users (even if it's slightly less well-known than >> XSL). And with a DOM or SAX parser, you could still happily employ >> the full power of C++. >> >>> ________________________ >>> *COMPLEXITY* >>> >>> The task of enumerating all types of OSIS<title> tags, and deciding >>> what to do with each, and how to classify all<title> tags from all >>> possible OSIS documents into our enumeration is still going to be a >>> complex task using XSLT.<title> is a complex example, but certainly >>> not the most complex. >>> >>> It is a tall task to generalize all elements of all documents from all >>> publishers into one conceptual model with one chosen output for a >>> frontend-- whether that be for an audience on the Desktop, web-based, or >>> a handheld. >>> >>> The complex processing required by the engine will require long, complex >>> XSLT-- which likely will encorporate callbacks to C++. It will not be >>> more simple-- only mixed language. >> I could also argue that the XSL would not require a developer to >> mentally filter out the code that just identifies and locates XML >> elements and attributes and parses them from the code that transforms >> them and generates the output. Thus yes, it might include some >> extension functions into C++ but it would be simpler. And it would >> also be more expressive. >> >> The enumeration of every OSIS<title> tag is a moot point for the >> decision. You need to enumerate them all in C++ as well and decide >> what to do with them. That doesn't change in the XSL - just the >> method used. An XSL match along the lines of<xsl:template >> match="title[@type=psalm]"> still has to be done in C++ with some sort >> of if(tag.name() == "title&& tag.attr("type") == "psalm") or whatever >> the syntax is. And that is assuming the current filter is using >> XMLTag and isn't comparing character strings directly. >> >>> _______________________ >>> *Semantic vs. Display* >>> >>> Some will say (and have), "well, let everything be display oriented and >>> let the publisher decide". Fine, then you lose 2 things: the ability to >>> display differently per user preference, per display device; and you >>> also give up the promise to actually do any interesting research on the >>> text. When you lose semantic markup, then you lose all interesting >>> information about WHAT is being marked up. >> I just want to be clear that I'm not advocating the use of display >> over semantics as a general choice. My statements are strictly based >> around my specific task and the fact that OSIS support in SWORD and >> the front ends is not as good as the support of ThML. Largely this is >> because most applications display in HTML and my required task is >> framed entirely in terms of the presentation and display - not the >> semantics. I would love and prefer to use OSIS for this task, but I >> simply cannot accomplish it with the state of SWORD at this time. >> >>> _______________________ >>> *More than a Rending Engine* >>> >>> The SWORD C++ Engine is more than simply a text rendering engine-- it is >>> a Biblical text research engine. >>> >>> If I'd like to know the morphology of word 3 in 2Thes 2.13 of the WHNU >>> Greek text, the entire program to do such is: >>> >>> SWMgr library; >>> SWModule *whnu = library.getModule("WHNU"); >>> whnu->setKey("2th.2.13"); >>> whnu->RenderText(); >>> >>> cout<< "The morphology of word three is: "<< >>> whnu->getEntryAttributes()["Word"]["003"]["Morph"]<< endl; >>> >>> >>> That reads nice (at least in my opinion). I don't need to know about >>> XML, XSLT, care what markup the WHNU module uses, I don't even have to >>> know how to make a SWORD filter. The current filters do all the work of >>> breaking out these attributes and making them available in a nice and >>> interesting map. >> I'd like to be clear again, that XSL would only be useful for material >> already in OSIS formats (or in valid ThML - I think TEI is also an XML >> format?). I doubt many modules in ThML are strictly valid at their >> import times, so XSL wouldn't be very useful, and GBF is a monster >> unto itself. Doing the above in XSL from an OSIS source would not be >> much different in complexity than what you have listed there. >> >> <xsl:template match="verse[@osisID='2thes.2.13']/w[@n=3]"> >> The morphology of word three is:<xsl:value-of select="@morph" /> >> </xsl:template> >> >> Or something similar (my knowledge of exact OSIS attribute names and >> values wanes and it's been two or three weeks since I wrote an XPath >> expression). >> >> Of course, the string processing portion of SWORD would continue to be >> of great importance for any modules in GBF format or similar to bring >> them into a useful form. In that way, SWORD would continue to be more >> than just a text rendering engine. It would continue to offer all of >> its features, its buffering from the system and from the format, its >> indexing, its module fetching and storing, etc. >> >>> ______________________ >>> >>> >>> And finally, if bullets aren't flying already, I'll stir the heat up with... >>> >>> XSLT sucks. A good C++ programmer can do anything in C++ better than >>> any XSLT programmer. >>> >>> >>> :) >> A C++ programmer can definitely do more, since C++ is actually a >> programming language and XSLT is a set of processing instructions. >> Better? That depends on what the criteria is. For me, in my current >> role as a module creator, the use of C++ is not currently better >> because it is less flexible and extensible. For you, as the library >> maintainer, perhaps C++ is better because it's what you are already >> comfortable with and because it has largely been your hand in the >> filters. >> >>> *duck* >>> Have fun. >>> >>> Troy >>> >>> PS. In summary, I understand the current filters are sometimes overly >>> complex and need cleanup, standardization, etc. It comes down to the >>> fact that they mostly work, and other things which don't get priority, >>> so they don't get much attention. But honestly, I think one might be >>> oversimplifying the problem at hand without realizing it, if one simply >>> thinks switching to XSLT will make things easier. >> I think one is also oversimplifying the options. My dreamlist is that >> SWORD produce a well-formed, valid, complete OSIS document for an >> arbitrary KeyList that I pass it with FMT_OSIS set. That basically >> boils down to getting the *OSIS filters up to snuff and standardized. >> The second item on the list is a readily extensible mechanism for >> SWORD outputting HTML from that OSIS. If that choice is providing an >> XSL stylesheet with the library, a C++ SAX processor that a front-end >> can readily extend, a DOM interface that can be easily customized is >> immaterial to me. I like all three of those, and can easily >> understand and extend all of them. >> >> I think any of those technologies would be an improvement over all >> in-house C++ for the second half of any such processing. If we are >> using XML in Open Source Software, let's leverage the work of others >> who have happily given us permission to use their libraries! >> >> --Greg >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 From dfhmch at googlemail.com Wed Dec 1 11:34:17 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 1 Dec 2010 10:34:17 -0800 (PST) Subject: [sword-devel] cipherraw In-Reply-To: <4CE31D33.1040508@gmx.net> References: <4CE31D33.1040508@gmx.net> Message-ID: <1291228457944-3067825.post@n4.nabble.com> No-one has answered Peter yet. O Come all ye experts! David -- View this message in context: http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html Sent from the SWORD Dev mailing list archive at Nabble.com. From greg.hellings at gmail.com Wed Dec 1 11:38:22 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 1 Dec 2010 12:38:22 -0600 Subject: [sword-devel] cipherraw In-Reply-To: <1291228457944-3067825.post@n4.nabble.com> References: <4CE31D33.1040508@gmx.net> <1291228457944-3067825.post@n4.nabble.com> Message-ID: <AANLkTikEX1kGENEQP+oBdQ0SKOOs60=EGn021KrA2XmE@mail.gmail.com> This is not true. He was answered on IRC. On Wed, Dec 1, 2010 at 12:34 PM, David Haslam <dfhmch at googlemail.com> wrote: > > No-one has answered Peter yet. ?O Come all ye experts! > > David > -- > View this message in context: http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html > Sent from the SWORD Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 > From dmsmith at crosswire.org Wed Dec 1 12:24:58 2010 From: dmsmith at crosswire.org (DM Smith) Date: Wed, 01 Dec 2010 14:24:58 -0500 Subject: [sword-devel] cipherraw In-Reply-To: <AANLkTikEX1kGENEQP+oBdQ0SKOOs60=EGn021KrA2XmE@mail.gmail.com> References: <4CE31D33.1040508@gmx.net> <1291228457944-3067825.post@n4.nabble.com> <AANLkTikEX1kGENEQP+oBdQ0SKOOs60=EGn021KrA2XmE@mail.gmail.com> Message-ID: <4CF6A10A.9030603@crosswire.org> Was it a bug or a usage problem. If it is a bug, I'll submit a bug report in Jira for it. On 12/01/2010 01:38 PM, Greg Hellings wrote: > This is not true. He was answered on IRC. > > On Wed, Dec 1, 2010 at 12:34 PM, David Haslam<dfhmch at googlemail.com> wrote: >> No-one has answered Peter yet. O Come all ye experts! >> >> David >> -- >> View this message in context: http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html >> Sent from the SWORD Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 >> > _______________________________________________ > 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 From greg.hellings at gmail.com Wed Dec 1 12:28:45 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 1 Dec 2010 13:28:45 -0600 Subject: [sword-devel] cipherraw In-Reply-To: <4CF6A10A.9030603@crosswire.org> References: <4CE31D33.1040508@gmx.net> <1291228457944-3067825.post@n4.nabble.com> <AANLkTikEX1kGENEQP+oBdQ0SKOOs60=EGn021KrA2XmE@mail.gmail.com> <4CF6A10A.9030603@crosswire.org> Message-ID: <AANLkTikTkF=Laz-8RrdLFPhMUVAV4ddPxM8OA1OnahtL@mail.gmail.com> I believe he had to switch to using mod2zmod. Some time ago when I was working with ciphered modules, I had to switch to mod2zmod, as I never could get raw modules to encrypt. That might be a bug with cipherraw, it might be a bug with the engine, or it might be design. Not sure. --Greg On Wed, Dec 1, 2010 at 1:24 PM, DM Smith <dmsmith at crosswire.org> wrote: > Was it a bug or a usage problem. If it is a bug, I'll submit a bug report in > Jira for it. > > On 12/01/2010 01:38 PM, Greg Hellings wrote: >> >> This is not true. ?He was answered on IRC. >> >> On Wed, Dec 1, 2010 at 12:34 PM, David Haslam<dfhmch at googlemail.com> >> ?wrote: >>> >>> No-one has answered Peter yet. ?O Come all ye experts! >>> >>> David >>> -- >>> View this message in context: >>> http://sword-dev.350566.n4.nabble.com/cipherraw-tp3045962p3067825.html >>> Sent from the SWORD Dev mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 > From greg.hellings at gmail.com Wed Dec 1 15:48:11 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 1 Dec 2010 16:48:11 -0600 Subject: [sword-devel] Bible/Commentary headings Message-ID: <AANLkTikcRmW55fsMeYUqvvbVobcpdRODxWOPXDMAtmZj@mail.gmail.com> 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 From benpmorgan at gmail.com Wed Dec 1 15:56:28 2010 From: benpmorgan at gmail.com (Ben Morgan) Date: Thu, 2 Dec 2010 09:56:28 +1100 Subject: [sword-devel] Bible/Commentary headings In-Reply-To: <AANLkTikcRmW55fsMeYUqvvbVobcpdRODxWOPXDMAtmZj@mail.gmail.com> References: <AANLkTikcRmW55fsMeYUqvvbVobcpdRODxWOPXDMAtmZj@mail.gmail.com> Message-ID: <AANLkTim+d97mSiD8oDtK48r4DcaWUiugUQiOfXBjpqcx@mail.gmail.com> 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.hellings at gmail.com>wrote: > 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 at crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/2f9132c0/attachment.html> From greg.hellings at gmail.com Wed Dec 1 15:59:22 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 1 Dec 2010 16:59:22 -0600 Subject: [sword-devel] Bible/Commentary headings In-Reply-To: <AANLkTim+d97mSiD8oDtK48r4DcaWUiugUQiOfXBjpqcx@mail.gmail.com> References: <AANLkTikcRmW55fsMeYUqvvbVobcpdRODxWOPXDMAtmZj@mail.gmail.com> <AANLkTim+d97mSiD8oDtK48r4DcaWUiugUQiOfXBjpqcx@mail.gmail.com> Message-ID: <AANLkTintSwf8Pt9tB3J37=npk9ou4enca0LOiqpXr8qX@mail.gmail.com> That appears to have done it. Thanks. --Greg On Wed, Dec 1, 2010 at 4:56 PM, Ben Morgan <benpmorgan at gmail.com> wrote: > 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.hellings at gmail.com> > wrote: >> >> 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 at 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 at crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > From greg.hellings at gmail.com Wed Dec 1 21:32:04 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 1 Dec 2010 22:32:04 -0600 Subject: [sword-devel] Markup Options In-Reply-To: <AANLkTi=ATkZLPca6phvJrhE8xxoqeqAZtpO95HNyq1jx@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <vxkipzesqwz.fsf@awol.kleinpaste.org> <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> <AANLkTi=ATkZLPca6phvJrhE8xxoqeqAZtpO95HNyq1jx@mail.gmail.com> Message-ID: <AANLkTi=gAh_MBYWRM6=DP6qRRNo5EjTBPGV45cLzGuBc@mail.gmail.com> On Wed, Dec 1, 2010 at 9:25 AM, Ben Morgan <benpmorgan at gmail.com> wrote: > Hi Greg, > 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. 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. 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. > 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. --Greg From benpmorgan at gmail.com Thu Dec 2 02:08:19 2010 From: benpmorgan at gmail.com (Ben Morgan) Date: Thu, 2 Dec 2010 20:08:19 +1100 Subject: [sword-devel] Markup Options In-Reply-To: <AANLkTi=gAh_MBYWRM6=DP6qRRNo5EjTBPGV45cLzGuBc@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <vxkipzesqwz.fsf@awol.kleinpaste.org> <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> <AANLkTi=ATkZLPca6phvJrhE8xxoqeqAZtpO95HNyq1jx@mail.gmail.com> <AANLkTi=gAh_MBYWRM6=DP6qRRNo5EjTBPGV45cLzGuBc@mail.gmail.com> Message-ID: <AANLkTi=G2ecDyT1LbSZYNG3pZDT627cmcDz8dL3w4dnN@mail.gmail.com> Hi Greg, On Thu, Dec 2, 2010 at 3:32 PM, Greg Hellings <greg.hellings at gmail.com>wrote: > > 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/4f3184fd/attachment.html> From dmitrij.ledkov at ubuntu.com Thu Dec 2 02:38:40 2010 From: dmitrij.ledkov at ubuntu.com (Dmitrijs Ledkovs) Date: Thu, 2 Dec 2010 09:38:40 +0000 Subject: [sword-devel] Bits from Debian Crosswire Packaging Team Message-ID: <AANLkTin76szkR=JPWP4w8f_6jZCVqvWFgnB1m590Lb_b@mail.gmail.com> Hello everyone! Here are some updates from Debian Crosswire Packaging team. We have three PPA's. Stable, Developer Preview and Daily Builds. All three of these are now build automatically by launchpad using recipes. All recipes can be viewed here: https://code.launchpad.net/~pkgcrosswire/+recipes = Developer preview PPA = * Preview the latest available Work-in-progress packaging * Uses released versions of upstream software (possibly patched) * Builds for currently supported Ubuntu Releases * Build are automatic Example is sword-stable recipe here: https://code.launchpad.net/~pkgcrosswire/+recipe/sword-stable You can clearly see which branches are used (just our packaging branch lp:sword/debian aka lp:~pkgcrosswire/sword/main) as well as the build results for each Ubuntu Release and architecture. When we are packaging software we only need to do `$ bzr push` and launchpad will build updated packages for all four currently supported Ubuntu releases. No need to manually change package versions, recreate debian source packages and uploading them to launchpad. Huray =) = Daily Builds = * Automatically does daily builds of upstream svn trunk * Uses latest available, "official" packaging * Builds for all currently supported Ubuntu Releases * Builds are not tested and not supported Example is sword-daily recipe here https://code.launchpad.net/~pkgcrosswire/+recipe/sword-daily This recipe is based on lp:sword - a bzr mirror of sword svn trunk (pulled multiples times a day) and it is merged with our packaging. A "bridge" branch is used to set correct ancestry and it will eventually go away when launchpad will support nest-part command. On this page you can see latest build results for Ubuntu releases and supported architectures. = Stable PPA = * Manually transitioned packages from Developer-Preview * Well Tested * Use "official" packaging * Builds for all currently supported Ubuntu Releases * Limited support available on best effort basis This stays as it is, except that it is much easier for us to update now. We can simply perform a manual build request from the stable recipe page web-page. = What pages should you look at? = Sword Code Import: https://code.launchpad.net/~sword-devel/sword/trunk Daily Builds (latest): https://code.launchpad.net/~pkgcrosswire/+recipe/sword-daily Developer Preview (latest): https://code.launchpad.net/~pkgcrosswire/+recipe/sword-stable Xiphos Code Import: https://code.launchpad.net/~xiphos-devel/xiphos/trunk Daily Builds (latest): https://code.launchpad.net/~pkgcrosswire/+recipe/xiphos-daily Developer Preview (latest): https://code.launchpad.net/~pkgcrosswire/+recipe/xiphos-stable BibleTime Code Import: https://code.launchpad.net/~bibletime/bibletime/gitorious Daily Builds (latest): https://code.launchpad.net/~pkgcrosswire/+recipe/bibletime-daily (NOT ENABLED YET) Developer Preview (latest): https://code.launchpad.net/~pkgcrosswire/+recipe/bibletime-stable PPA build results: Daily (all): https://launchpad.net/~pkgcrosswire/+archive/daily/+packages Developer-Preview (all): https://launchpad.net/~pkgcrosswire/+archive/developer-testing/+packages Stable (all): https://launchpad.net/~pkgcrosswire/+archive/ppa/+packages How to add these PPA: Daily (all): $ sudo add-apt-repository ppa:pkgcrosswire/daily Developer-Preview (all): $ sudo add-apt-repository ppa:pkgcrosswire/developer-testing Stable (all): $ sudo add-apt-repository ppa:pkgcrosswire/ppa = About Debian Pkgcrosswire Packaging Team = We are packaging Bible study related packages based on SWORD API and Crosswire Bible Society repository of Bible texts. We are official maintainers of these packages in Debian and Ubuntu. We provide regular backports updates to Ubuntu via PPA as well as offering work-in-progress packages. Our packages adhere to Debian Packaging Policy. All our builds provide debug (-dbg) packages as well to help with troubleshooting From jonmmorgan at gmail.com Thu Dec 2 06:13:47 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Fri, 3 Dec 2010 00:13:47 +1100 Subject: [sword-devel] Markup Options In-Reply-To: <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <vxkipzesqwz.fsf@awol.kleinpaste.org> <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> Message-ID: <AANLkTikh88k7wT=yy4SLkHd4yO_bxvQqe49WSOSjOAw7@mail.gmail.com> On Thu, Dec 2, 2010 at 1:51 AM, Greg Hellings <greg.hellings at gmail.com>wrote: > On Wed, Dec 1, 2010 at 7:40 AM, Jonathan Morgan <jonmmorgan at gmail.com> > wrote: > > From an application developer's point of view, I'm not convinced that per > > module CSS is a good idea. Here are some reasons: > > 1. I'm not convinced of "well-defined use of HTML+CSS classes". Some > things > > may be well-defined, but I know BPBible does a lot of customisation of > the > > SWORD generated HTML and uses a lot of custom CSS, and some or all of > these > > things might break CSS designed for other apps (and vice versa). I also > do > > not like the idea that my changes to either the HTML generated or the CSS > > breaks the display of a module I have never seen. > > 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. > > 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. > We use different structure, not just different classes. > > > 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. > > I remember Jaak voicing this complaint when I brought up CSS > stylesheets in BibleTime. This is actually an argument FOR having > external stylesheets. I don't see why either of you would think our > case is any different from a web browser in this regard.CSS was > designed specifically to handle exactly the situation you bring up. > In web browsers styles will cascade downwards with earlier styles > overwriting later ones in the following order: > > 1) User-Agent stylesheet > 2) External stylesheets > 3) Internal stylesheets > 4) Inline styles > > Often times a user can insert their own styles for accessibility > reasons and I believe those are usually placed at priority 3.5 in that > list. Currently SWORD applications only support (1) and (4). > BibleTime's offer of themes simply changes the values of the > User-Agent stylesheet. My first attempt at creating SWORD modules way > back when I thought that (2) and (3) would be supported since the > library documentation claimed to support ThML, but it ends up the > entire header of the document gets thrown away during import but > inline styles remain intact. As a result, (3) would be difficult to > handle in SWORD without major changes to the entire library and import > system but (2) would be very easy to add simply by honoring a config > option. > > Since the stylesheets within each level cascade with later ones > overriding earlier ones, in order to maintain the specified order, the > following in the HTML header would be all that is required: > > <link rel="stylesheet" type="text/css" > href="/usr/share/bpbible/css/default.css" /> > <link rel="stylesheet" type="text/css" > href="modules/ztext/mymodule/css/module.css" /> > <link rel="stylesheet" type="text/css" > href="~/.bpbible/css/user-overrides.css" /> > > 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? > It seems to me a given that when you introduce more sources of styles you introduce more potential for conflict. The reason this is different from what is on the web is that the default browser CSS is fairly similar across all browsers. I know there are differences in text size and padding levels and that some people go to the trouble of using browser reset stylesheets, etc., etc., but that's still a fairly small difference. Here we have multiple applications and I don't think it's reasonable to assume that the base CSS is fairly similar across apps in the same way as it is across browsers. While it is true that users can apply custom stylesheets, I suspect the number that actually do so is fairly minimal, so web developers just have to test on a stock-standard browser build (and do). If we had HTML modules then I would expect it to be exactly the same as on the web. Since we have higher-level constructs and more rendering options, it is much more likely that there will be transformations that radically affect presentation without affecting text, and module CSS can interfere with this. [If browsers showed as much difference between renderings of the same text as some frontends do, I would be very worried]. Currently the only way to get styles through to the display layer are > through number 4 - inline styles. As it is, I can already mess with > every one of those settings you're worried about me messing up and the > user can do nothing about it (unless, of course, BPBible strips the > style attribute from ThML sources). So by providing me the ability to > set an external stylesheet, you would actually be fixing what is > currently a usability bug in apps. Thus both you and Jaak are correct > to worry about this issue, but the result of your worrying should be > to enable external styles not disable them. > So what you are saying is that you use something that might break it more so we should officially support something that might break it a bit less? > 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. > > Of course, this depends on how you allow styles to be defined. I > think, again, this is actually an argument _for_ having external > styles available for each module. Currently I can only put my styles > inline on an element. Therefore no matter what you do, without > stripping off the style attribute, I can easily break the display of > your parallel Bibles. If I were permitted an external stylesheet > which I could apply to well defined HTML classes, then the user-agent > could decide what to do based on its own method for parallel display. > BibleTime, IIRC, uses a <table> with each verse in a new <tr> and each > version displayed side-by-side within a <td>. It is likely that > BibleTime would simply not include the external stylesheet of either > module at this point; alternatively they could be included in some > deterministic order - reverse order of their addition to the display, > for instance, that way the version which has been there longest takes > precedence. If a display were using a frameset or iframes, then it > might opt to include the stylesheets. > Which bears out my original point: if the display in the CSS is ever required to make the module look right, then it will end up broken in some views where we can't/won't include it. 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). > All I'm pointing out is that more control is not always a good thing, and often doesn't come for free as much as people think/hope it will. Jon Of course all of this ignores BibleCS, which I personally don't mind. > But it probably doesn't honor inline styles any more than external > styles, so I have no interest in it. :) > > --Greg > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101203/a6742f80/attachment.html> From greg.hellings at gmail.com Thu Dec 2 08:19:35 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Thu, 2 Dec 2010 09:19:35 -0600 Subject: [sword-devel] Markup Options In-Reply-To: <AANLkTi=G2ecDyT1LbSZYNG3pZDT627cmcDz8dL3w4dnN@mail.gmail.com> References: <AANLkTimRyeWM3nfcrFX_XZQbQr5WaA_0xbouZCrp6x9W@mail.gmail.com> <vxkipzesqwz.fsf@awol.kleinpaste.org> <AANLkTimHNjM8QnCmtQ0B2qDWH0wm-YrnALkZs5u=M88B@mail.gmail.com> <AANLkTi=pGbsxA9yUVYBSSyxD+6+0H4+zE_jc5D8uqMai@mail.gmail.com> <AANLkTi=ATkZLPca6phvJrhE8xxoqeqAZtpO95HNyq1jx@mail.gmail.com> <AANLkTi=gAh_MBYWRM6=DP6qRRNo5EjTBPGV45cLzGuBc@mail.gmail.com> <AANLkTi=G2ecDyT1LbSZYNG3pZDT627cmcDz8dL3w4dnN@mail.gmail.com> Message-ID: <AANLkTimkzsOvnFSJrCYFwVHPKnJhcrv3Q3J61RYqb6jd@mail.gmail.com> On Thu, Dec 2, 2010 at 3:08 AM, Ben Morgan <benpmorgan at gmail.com> wrote: > Hi Greg, > 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). So then you want per-module, per-user stylesheets? And why would the module not be allowed to provide its own default to keep the user from having to download the module's stylesheet from yet another source and install it? What you propose there is identical to my proposal with one exception: your proposal requires extra steps be done manually by the user which mine would remove the need for (but still leave as an option). > 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... To be clear, I'm not actually talking about Bibles. I'm talking about commentaries, Lexica and general books - though the changes I propose could also be used in Bibles if desired. The formatting need of a Bible is pretty minimal - line and paragraph breaks, possibly italic or bold font, small caps/divine name, possibly headings. (Yes, there are exceptions of picture Bibles or similar, but the actual text of the Bible in most of those cases is supplemented by commentary-like or footnote-like material. And I'm aware of no such instances among Crosswire modules.) The formatting needs of an arbitrary text are not so minimal - tables, borders, floating images or other figures, margins, padding, font size, alignment of blocks of text to make a passage clear, etc. I'm content to just say "We disagree" over customizing displays of Bibles, but I think the same "no formatting here" stance towards the other types of works we support is simply incorrect. > 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. And that is my point. We provide this mechanism (perhaps unconsciously or unawares), so why not provide it consciously and correctly? I loathe the inline mechanism that I am forced to support. But unless we are going to start allowing external stylesheets and/or custom per-module OSIS->HTML transforms (not saying this second option is at all desirable, only that would be a second mechanism that allows me to accomplish my task) or something similar, I'm going to be stuck doing this. > 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)? At least we agree on the premise of the argument: presentation and formatting is vitally important to on-screen text displays. Ergo, we both wish to control as much of it as possible - the application programmer and the content creator. To that end your statement that "OSIS...is easier to work for a lot of things than ThML" is a one-sided statement. For you, as the application programmer, it is much easier because you can easily control the look and be in absolute command of the module's appearance. For me, as the module creator, it absolutely sucks presently because I am unable to even hint at anything more complicated than "bold here, italics there". This is not a limitation of OSIS at all, but a limitation in SWORD's willingness to provide the standard transformational and presentational tools the XML content provider expects. I like XML because of its ease of use for the programmer and for the presenter. SWORD effectively presents a choice to the module creator: either use OSIS/XML and be smiled upon by the repository maintainers and have your work easily able to be processed programmatically OR use HTML/ThML fragments with inline styling so your module looks the way you want but is atrocious to try and do anything other than display to the user. I am just wanting to close the gap and provide a way for OSIS/XML to be put into the system to satisfy the experts who might use SWORD tools for advanced study and still give the module creator the ability to format their text by means they are already comfortable with. I would like to think this is in line with Troy and Chris and DM's (and others') advocacy of the semantic nature of OSIS divorced from presentational directives. I'm fully on board with that objective, I'm just giving the requirements that I would need before I could make OSIS a reality for my own work. As to what types of styling I'm doing now, most of them boil down to basic CSS1, AFAIK: bold/italic/underline/strikethrough (some of which is possible with OSIS already) font size borders, margin, padding floating, sizing and positioning of images Sometimes specifying the font to use with foreign texts that might use codepoints out of the range of normal fonts (remember, my modules come from Wycliffe, who has the possibility of using some very arcane and even novel combinations of characters and combining diacritics and the like) Nothing terribly earth shattering. In one instance per module we also do the background color (teal) for the title of each work, but I have not noticed any other such background colors. It's not like I want to move heaven and earth with the CSS styling and break everything. :) --Greg From scribe at crosswire.org Thu Dec 2 08:56:21 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Thu, 02 Dec 2010 15:56:21 +0000 Subject: [sword-devel] Why You Should Love SWORD 102 - XML Basics Message-ID: <4CF7C1A5.30207@crosswire.org> XMLTag is a wonderful class for working with.... XML Tags! For example. If you have the tag: <verse osisID="John.1.1" type='test type' yeah = "stuff" /> You can do handy things like: cout << tag.getAttribute("type"); $ test type tag.setAttribute("type", "changedType"); tag.setAttribute("subtype", "newSubtype"); cout << tag.getName(); $ verse cout << tag.isEmpty(); $ true cout << tag.isEndTag(); $ false cout << XMLTag("</verse>").isEndTag(); $ true cout << tag.toString(); $ <verse osisID="John.1.1" subtype="newSubtype" type="changedType" yeah="stuff"/> ___________________ XMLTag even helps you parse list attributes like: <reference osisRef="John.3.16 John.3.22-25 Act.4.12"> int count = tag.getAttributePartCount("osisRef", ' '); for (int i = 0; i < count; ++i) { cout << x.getAttribute("osisRef", i, ' '); } $ John.3.16 $ John.3.22-25 $ Acts.4.12 ___________________ And it mostly figures things out for you, even when the XML isn't exactly valid (which we quite often find in imported modules) For a wild and crazy show see: http://crosswire.org/svn/sword/trunk/tests/xmltest.cpp From chris at burrell.me.uk Thu Dec 2 11:53:26 2010 From: chris at burrell.me.uk (Chris Burrell) Date: Thu, 2 Dec 2010 18:53:26 +0000 Subject: [sword-devel] Anyone used the Greenhopper plugin within JIRA Message-ID: <AANLkTim7c19znegCDhN1jUk158AB8P8yUSmdw5jVSnW0@mail.gmail.com> Hi All Greenhopper is a very useful AJAX plugin for JIRA. I was wondering if there would be interest in installing this? I use it at work all the time. The main advantages I see for Crosswire/projects hosted by Crosswire would be: - drag and drop prioritisation of items (i.e. you can drag an item up and down, and the order represents their priority) - drag and drop into the fix versions as issues are scheduled to be fixed - drag and drop between the various states (to be done, in progress, done) which changes the current status of the bug/improvement/feature/etc. After installation a simple AJAX tab is added to the UI. It also does a whole load of burn down charts for agile management, which I guess wouldn't be so useful here - probably. It's done by Atlassian (now - they purchased it) and so follows the same licensing scheme as the main JIRA installation. (Happy to install it if people want - I've done this recently for work - but I guess I'd need write permissions to the installed-plugins directory). Cheers Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/f0cf0cc8/attachment.html> From scribe at crosswire.org Fri Dec 3 08:19:52 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Fri, 03 Dec 2010 15:19:52 +0000 Subject: [sword-devel] Why You Should Love SWORD 103 - What Is A Filters Message-ID: <4CF90A98.2040602@crosswire.org> *The anatomy of an SWFilter* ____________________________ At the most basic level, a SWORD filter performs some distinct and concise transformation to the data stream. The actual signature of a filter is very minimal, and looking at the SWFilter interface itself... http://crosswire.org/svn/sword/trunk/include/swfilter.h ... there is simply 1 method you need to implemented to create a filter: char SWFilter::processText( SWBuf &text, const SWKey *key = 0, const SWModule *module = 0) = 0; Basically, you're sent a buffer of text, possibly along with some context in the form of an SWKey and SWModule-- in case you care, and then you make some small change to the buffer. Easy, right? Well, sortof. Anyone can write a filter. The great thing about filters is that they partition up a very complicated task: processing a complex document, into tiny manageable chunks that anyone can tackle. "Handle <title> tags in a buffer? Sure, I can do that! That's easy.... Wait.... What should I _DO_ with a <title> tag?" That's when the real world hits and things get more complex. A SWORD filter is an easy to grasp, easy to code against, abstract concept. How filters are orchestrated together inside the SWORD engine-- what distinct roles they are expected to fill, when, and in what order-- is hidden knowledge that for years only few have been privy to yield... Stay tuned for "The Red Pill" coming soon to a listserv near you. From greg.hellings at gmail.com Fri Dec 3 08:52:07 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Fri, 3 Dec 2010 09:52:07 -0600 Subject: [sword-devel] Why You Should Love SWORD 103 - What Is A Filters In-Reply-To: <4CF90A98.2040602@crosswire.org> References: <4CF90A98.2040602@crosswire.org> Message-ID: <AANLkTin_1sX_Nq=uurkKz+Xn4fu+KGkf1qz8tCU6zHuS@mail.gmail.com> I realize we're on #3 already, I just wanted to say "thanks" for this set of "SWORD 10*" emails. And I hope our Wiki Czar find the time to translate these into a nice series of intro/tutorials that we can maintain and update as some of us use these to dive deeper into the codebase that has supported us for so many year now. :) --Greg On Fri, Dec 3, 2010 at 9:19 AM, Troy A. Griffitts <scribe at crosswire.org> wrote: > *The anatomy of an SWFilter* > ____________________________ > > > At the most basic level, a SWORD filter performs some distinct and > concise transformation to the data stream. > > The actual signature of a filter is very minimal, and looking at the > SWFilter interface itself... > > http://crosswire.org/svn/sword/trunk/include/swfilter.h > > ... there is simply 1 method you need to implemented to create a filter: > > char SWFilter::processText( > ? ? ? ? ? ? ? ?SWBuf ? ? ? ? ? &text, > ? ? ? ?const ? SWKey ? ? ? ? ? *key ? ?= 0, > ? ? ? ?const ? SWModule ? ? ? ?*module = 0) = 0; > > > Basically, you're sent a buffer of text, possibly along with some > context in the form of an SWKey and SWModule-- in case you care, and > then you make some small change to the buffer. > > Easy, right? ?Well, sortof. > > Anyone can write a filter. ?The great thing about filters is that they > partition up a very complicated task: processing a complex document, > into tiny manageable chunks that anyone can tackle. > > "Handle <title> tags in a buffer? ?Sure, I can do that! ?That's easy.... > ?Wait.... ?What should I _DO_ with a <title> tag?" > > That's when the real world hits and things get more complex. ?A SWORD > filter is an easy to grasp, easy to code against, abstract concept. > > How filters are orchestrated together inside the SWORD engine-- what > distinct roles they are expected to fill, when, and in what order-- is > hidden knowledge that for years only few have been privy to yield... > > Stay tuned for "The Red Pill" coming soon to a listserv near you. > > > _______________________________________________ > 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 > From dfhmch at googlemail.com Fri Dec 3 09:20:07 2010 From: dfhmch at googlemail.com (David Haslam) Date: Fri, 3 Dec 2010 08:20:07 -0800 (PST) Subject: [sword-devel] osis2mod and NT heading? Message-ID: <1291393207209-3071316.post@n4.nabble.com> Is there a bug perhaps in the way that osis2mod processes the bookGroup title for the New Testament? I have a valid OSIS XML file which uses BCV structure, with the body content modeled according to the example shown http://crosswire.org/wiki/OSIS_Bibles#Body here in the wiki. The start of the NT division is coded like this<div type="bookGroup"> <title>El Nuevo Testamento

El Santo Evangelio seg?n Mateo Mateo 1 El libro de la generaci?n de Jesucristo, hijo de David, hijo de Abraham. When displayed in Xiphos, the title El Nuevo Testamento is appended to the last verse of Malachi 4. Running mod2imp on the module that I made outputs a raw IMP file containing the following lines: $$$Malachi 4:6 ?l convertir? el coraz?n de los padres hacia los hijos, y el coraz?n de los hijos hacia los padres; no sea que yo venga y hiera la tierra con maldici?n.

El Nuevo Testamento $$$[ Testament 2 Heading ] $$$Matthew 0:0

with a type of section will be taken as surrounding verses. // A of type other than main, chapter or sub, will be taken as a title for the verse. // Once one of these conditions is met, the division between chapter introduction and pre-verse is set. // 3) Between verses, the material is split between the prior verse and the next verse. // Basically, while end and empty tags are found, they belong to the prior verse. // Once a begin tag is found, it belongs to the next verse. "Is there a bug perhaps in the way that osis2mod processes the bookGroup title for the New Testament? I have a valid OSIS XML file which uses BCV structure, with the body content modeled according to the example shown http://crosswire.org/wiki/OSIS_Bibles#Body here in the wiki. The start of the NT division is coded like this<div type="bookGroup"> <title>El Nuevo Testamento

El Nuevo Testamento $$$[ Testament 2 Heading ] $$$Matthew 0:0

El Santo Evangelio seg?n Mateo $$$Matthew 1:0 Mateo 1 $$$Matthew 1:1 El libro de la generaci?n de Jesucristo, hijo de David, hijo de Abraham. Observe that $$$[ Testament 2 Heading ] occurs AFTER the second bookGroup title rather than BEFORE, which strongly suggests that the module was made incorrectly. I was running osis2mod: $Rev: 2562 $ downloaded from http://www.crosswire.org/ftpmirror/pub/sword/utils/win32/sword-utilities-1.6.2.zip http://www.crosswire.org/ftpmirror/pub/sword/utils/win32/sword-utilities-1.6.2.zip Has this been observed by anyone else? Is this a known bug that has already been fixed by a later version? Best regards, David" From dfhmch at googlemail.com Sat Dec 4 01:39:22 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 4 Dec 2010 00:39:22 -0800 (PST) Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <893744.70426.qm@web113417.mail.gq1.yahoo.com> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> Message-ID: <1291451962026-3072203.post@n4.nabble.com> Troy Pulk's reply describes how osis2mod currently compiles a module, but it does not explain why it fails to conform to the OSIS example of basic structure as described in the wiki. The title of a bookGroup division structured as the New Testament should appear at the head of the NT, before the book title of Matthew. It makes no sense for it to be appended to Malachi 4:6 which is at the end of the previous bookGroup division. The description of how other pre-verse headings are implemented is a sideshow to this basic issue. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072203.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Sat Dec 4 02:01:06 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 4 Dec 2010 01:01:06 -0800 (PST) Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <1291451962026-3072203.post@n4.nabble.com> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> Message-ID: <1291453266234-3072215.post@n4.nabble.com> Therefore I have just added this as a new issue in JIRA. http://www.crosswire.org/bugs/browse/API-136 http://www.crosswire.org/bugs/browse/API-136 David -- View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072215.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dmsmith at crosswire.org Sat Dec 4 05:23:04 2010 From: dmsmith at crosswire.org (DM Smith) Date: Sat, 4 Dec 2010 07:23:04 -0500 Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <1291453266234-3072215.post@n4.nabble.com> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> <1291453266234-3072215.post@n4.nabble.com> Message-ID: <027BAD56-21C0-4B7D-8612-B826D39ECD44@crosswire.org> Thanks David. I haven't had the time to look at this, to properly reply to you. There's another bug in the handling of titles that is wrong also and should be opened as a second issue: Osis2mod no longer marks titles as pre-verse. Due to this, SWORD will put the verse number in the wrong place. I'll be opening an issue for that soon. With each osis2mod issue, it would be good to attach a sample of OSIS that demonstrates the problem, with expected output. This then could be used to write a validator for changes to the program. In Him, DM On Dec 4, 2010, at 4:01 AM, David Haslam wrote: > > Therefore I have just added this as a new issue in JIRA. > > http://www.crosswire.org/bugs/browse/API-136 > http://www.crosswire.org/bugs/browse/API-136 > > David > -- > View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072215.html > Sent from the SWORD Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 From dmsmith at crosswire.org Sat Dec 4 06:37:37 2010 From: dmsmith at crosswire.org (DM Smith) Date: Sat, 4 Dec 2010 08:37:37 -0500 Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <1291451962026-3072203.post@n4.nabble.com> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> Message-ID: <7E9252BF-95D9-4FA1-8788-6711E3B4AB3F@crosswire.org> The problem is that osis2mod has never tried to handle testament titles or introductions at all. Nor does it handle a title or introduction for the work as a whole. I'll need some help from Troy to know how to do this. In Him, DM On Dec 4, 2010, at 3:39 AM, David Haslam wrote: > > Troy Pulk's reply describes how osis2mod currently compiles a module, but it > does not explain why it fails to conform to the OSIS example of basic > structure as described in the wiki. > > The title of a bookGroup division structured as the New Testament should > appear at the head of the NT, before the book title of Matthew. > It makes no sense for it to be appended to Malachi 4:6 which is at the end > of the previous bookGroup division. > > The description of how other pre-verse headings are implemented is a > sideshow to this basic issue. > > David > -- > View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072203.html > Sent from the SWORD Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 From dfhmch at googlemail.com Sat Dec 4 06:51:32 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 4 Dec 2010 05:51:32 -0800 (PST) Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <027BAD56-21C0-4B7D-8612-B826D39ECD44@crosswire.org> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> <1291453266234-3072215.post@n4.nabble.com> <027BAD56-21C0-4B7D-8612-B826D39ECD44@crosswire.org> Message-ID: <1291470692873-3072408.post@n4.nabble.com> I have sent a private reply to DM in response to his request to access the OSIS XML file. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072408.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Sat Dec 4 07:02:44 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 4 Dec 2010 06:02:44 -0800 (PST) Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <7E9252BF-95D9-4FA1-8788-6711E3B4AB3F@crosswire.org> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> <7E9252BF-95D9-4FA1-8788-6711E3B4AB3F@crosswire.org> Message-ID: <1291471364833-3072420.post@n4.nabble.com> Hi DM, Well that is strange, because osis2mod does handle the title for the first bookGroup. Here is what Xiphos displays above Gen 1:1. Spanish Reina Valera G?mez 2010 Chapter 1 El Antiguo Testamento El libro de G?nesis (Primer libro de Mois?s) G?nesis 1 1 En el principio cre? Dios el cielo y la tierra. The first two titles are how Xiphos displays the module description and the currently selected chapter (these are centred on the pane) the word chapter being an aspect of the current locale. From dfhmch at googlemail.com Sat Dec 4 07:17:23 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 4 Dec 2010 06:17:23 -0800 (PST) Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <1291471364833-3072420.post@n4.nabble.com> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> <7E9252BF-95D9-4FA1-8788-6711E3B4AB3F@crosswire.org> <1291471364833-3072420.post@n4.nabble.com> Message-ID: <1291472243573-3072434.post@n4.nabble.com> From dmsmith at crosswire.org Sat Dec 4 08:07:10 2010 From: dmsmith at crosswire.org (DM Smith) Date: Sat, 4 Dec 2010 10:07:10 -0500 Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <1291472243573-3072434.post@n4.nabble.com> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> <7E9252BF-95D9-4FA1-8788-6711E3B4AB3F@crosswire.org> <1291471364833-3072420.post@n4.nabble.com> <1291472243573-3072434.post@n4.nabble.com> Message-ID: <53628A33-29FD-4B50-A56E-4989F2B8E710@crosswire.org> Sent from my phone so theer mite be tipos. ;) On Dec 4, 2010, at 9:17 AM, David Haslam wrote: > > From the same module, running mod2imp gives the following output as the first > few lines. > $$$[ Module Heading ] Your module doesn't have these. But if it did nothing would show up here. > > $$$[ Testament 1 Heading ] > The milestone should be in the module heading. Not here. But it doesn't matter. > $$$Genesis 0:0 >

El Antiguo > Testamento This title should not be here. The reason it is: it was appended to the last verse, which was initialize at the start of the program to Gen 0:0. Since it was empty, the append put it first. In the case of a New testament heading the prior known verse is typically in Malachi. (might be something else depending on av11n.) >

type="book"/> ?El libro de G?nesis (?Primer libro de > Mois?s) > $$$Genesis 1:0 > G?nesis 1 > $$$Genesis 1:1 > En el principio cre? Dios el cielo y la tierra. > This provides evidence that it does process the first bookGroup title - > though whether this is ideally placed is not for me to judge. > At least it processes it better than it does the second bookGroup title. > > Observe that I'm following the OSIS example in the wiki page, using

type="bookGroup" canonical="true"> rather than using

type="x-testament">, which is what gets output by the infamous mod2osis > utility. > -- > View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072434.html > Sent from the SWORD Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 From dmsmith at crosswire.org Sat Dec 4 08:25:36 2010 From: dmsmith at crosswire.org (DM Smith) Date: Sat, 4 Dec 2010 10:25:36 -0500 Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <53628A33-29FD-4B50-A56E-4989F2B8E710@crosswire.org> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> <7E9252BF-95D9-4FA1-8788-6711E3B4AB3F@crosswire.org> <1291471364833-3072420.post@n4.nabble.com> <1291472243573-3072434.post@n4.nabble.com> <53628A33-29FD-4B50-A56E-4989F2B8E710@crosswire.org> Message-ID: <53284B91-2FF7-4A0D-BDA0-D4C2733A70A1@crosswire.org> Hmm. I didn't finish the email before sending. More.... Cent from my fone so theer mite be tipos. ;) On Dec 4, 2010, at 10:07 AM, DM Smith wrote: > > > Sent from my phone so theer mite be tipos. ;) > > On Dec 4, 2010, at 9:17 AM, David Haslam wrote: > >> >> From the same module, running mod2imp gives the following output as the first >> few lines. >> $$$[ Module Heading ] > > Your module doesn't have these. But if it did nothing would show up here. > >> >> $$$[ Testament 1 Heading ] >> > The milestone should be in the module heading. Not here. But it doesn't matter. > >> $$$Genesis 0:0 >>

El Antiguo >> Testamento > This title should not be here. The reason it is: it was appended to the last verse, which was initialize at the start of the program to Gen 0:0. Since it was empty, the append put it first. > > In the case of a New testament heading the prior known verse is typically in Malachi. (might be something else depending on av11n.) I'm not sure how to detect a change in testament. Is there an osisID for work, ot, nt, deut? It'd make it a lot easier to detect. That aside, if a book is closed then it should be closed and nothing appended to it. > >>

> type="book"/> ?El libro de G?nesis (?Primer libro de >> Mois?s) This part was correctly placed. >> $$$Genesis 1:0 >> G?nesis 1 This was placed well too. >> $$$Genesis 1:1 >> En el principio cre? Dios el cielo y la tierra. This is good too. Had this had a section title it might have had a problem. >> This provides evidence that it does process the first bookGroup title - >> though whether this is ideally placed is not for me to judge. >> At least it processes it better than it does the second bookGroup title. >> >> Observe that I'm following the OSIS example in the wiki page, using

> type="bookGroup" canonical="true"> rather than using

> type="x-testament">, which is what gets output by the infamous mod2osis >> utility. Well that is a whole other can of worms. >> -- >> View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072434.html >> Sent from the SWORD Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 From dfhmch at googlemail.com Sat Dec 4 08:30:12 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 4 Dec 2010 07:30:12 -0800 (PST) Subject: [sword-devel] osis2mod and NT heading? In-Reply-To: <53628A33-29FD-4B50-A56E-4989F2B8E710@crosswire.org> References: <1291393207209-3071316.post@n4.nabble.com> <893744.70426.qm@web113417.mail.gq1.yahoo.com> <1291451962026-3072203.post@n4.nabble.com> <7E9252BF-95D9-4FA1-8788-6711E3B4AB3F@crosswire.org> <1291471364833-3072420.post@n4.nabble.com> <1291472243573-3072434.post@n4.nabble.com> <53628A33-29FD-4B50-A56E-4989F2B8E710@crosswire.org> Message-ID: <1291476612035-3072490.post@n4.nabble.com> Hi DM, Thanks for those observations. The output from MOD2IMP should be seen merely as circumstantial evidence as to what has happened after using OSIS2MOD to make the module. cf. Even MOD2IMP has a small amount of "lossyness", miniscule when compared to MOD2OSIS. These trivial quirks are a result of using http://crosswire.org/ftpmirror/pub/sword/utils/perl/imp2osis.pl imp2osis.pl on the IMP file that I had already created by other means from the supplied source text. It seemed sensible to me (after reading stuff from Chris) to move on from using IMP2VS to generating a proper OSIS XML file that I can then validate using XML Copy Editor. I am using imp2osis.pl with the -m option. Earlier I had tried it without this option, but I subsequently found that using the milestoned version solved some matters relating to displaying colophons. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-and-NT-heading-tp3071316p3072490.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Sat Dec 4 09:43:23 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 4 Dec 2010 08:43:23 -0800 (PST) Subject: [sword-devel] KJV.conf and Project KJV2006 ? Message-ID: <1291481003873-3072545.post@n4.nabble.com> The file KJV.conf refers to the Project KJV2003, but not to the successor http://www.crosswire.org/~dmsmith/kjv2006/ Project KJV2006 . Is there a reason for this? cf. Module KJV version 2.4 is dated 2009-09-25, which is well after KJV2006 took over KJV2003. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/KJV-conf-and-Project-KJV2006-tp3072545p3072545.html Sent from the SWORD Dev mailing list archive at Nabble.com. From jonmmorgan at gmail.com Sun Dec 5 05:06:44 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Sun, 5 Dec 2010 23:06:44 +1100 Subject: [sword-devel] Markup Options In-Reply-To: References:

Message-ID: On Fri, Dec 3, 2010 at 2:19 AM, Greg Hellings wrote: > On Thu, Dec 2, 2010 at 3:08 AM, Ben Morgan wrote: > > Hi Greg, > > 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). > > So then you want per-module, per-user stylesheets? And why would the > module not be allowed to provide its own default to keep the user from > having to download the module's stylesheet from yet another source and > install it? What you propose there is identical to my proposal with > one exception: your proposal requires extra steps be done manually by > the user which mine would remove the need for (but still leave as an > option). > > > 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... > > To be clear, I'm not actually talking about Bibles. I'm talking about > commentaries, Lexica and general books - though the changes I propose > could also be used in Bibles if desired. The formatting need of a > Bible is pretty minimal - line and paragraph breaks, possibly italic > or bold font, small caps/divine name, possibly headings. (Yes, there > are exceptions of picture Bibles or similar, but the actual text of > the Bible in most of those cases is supplemented by commentary-like or > footnote-like material. And I'm aware of no such instances among > Crosswire modules.) The formatting needs of an arbitrary text are not > so minimal - tables, borders, floating images or other figures, > margins, padding, font size, alignment of blocks of text to make a > passage clear, etc. > > I'm content to just say "We disagree" over customizing displays of > Bibles, but I think the same "no formatting here" stance towards the > other types of works we support is simply incorrect. > I agree that it is a little less important and likely to break (though don't under-estimate our ability to mix and match in weird and wonderful ways and break module CSS even in Genbooks). My biggest concern when dealing with arbitrary formatting for things like this is that people want to make it "just like a book", and I'm not convinced that leads to the best electronic reading experience. That being said, nor do I think a screen dump of text without any attempt at presenting it is very helpful. > > 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. > > And that is my point. We provide this mechanism (perhaps > unconsciously or unawares), so why not provide it consciously and > correctly? I loathe the inline mechanism that I am forced to support. > But unless we are going to start allowing external stylesheets and/or > custom per-module OSIS->HTML transforms (not saying this second option > is at all desirable, only that would be a second mechanism that allows > me to accomplish my task) or something similar, I'm going to be stuck > doing this. > > > 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)? > > At least we agree on the premise of the argument: presentation and > formatting is vitally important to on-screen text displays. Ergo, we > both wish to control as much of it as possible - the application > programmer and the content creator. To that end your statement that > "OSIS...is easier to work for a lot of things than ThML" is a > one-sided statement. For you, as the application programmer, it is > much easier because you can easily control the look and be in absolute > command of the module's appearance. > > For me, as the module creator, it absolutely sucks presently because I > am unable to even hint at anything more complicated than "bold here, > italics there". This is not a limitation of OSIS at all, but a > limitation in SWORD's willingness to provide the standard > transformational and presentational tools the XML content provider > expects. I like XML because of its ease of use for the programmer and > for the presenter. SWORD effectively presents a choice to the module > creator: either use OSIS/XML and be smiled upon by the repository > maintainers and have your work easily able to be processed > programmatically OR use HTML/ThML fragments with inline styling so > your module looks the way you want but is atrocious to try and do > anything other than display to the user. > > I am just wanting to close the gap and provide a way for OSIS/XML to > be put into the system to satisfy the experts who might use SWORD > tools for advanced study and still give the module creator the ability > to format their text by means they are already comfortable with. I > would like to think this is in line with Troy and Chris and DM's (and > others') advocacy of the semantic nature of OSIS divorced from > presentational directives. I'm fully on board with that objective, > I'm just giving the requirements that I would need before I could make > OSIS a reality for my own work. > > As to what types of styling I'm doing now, most of them boil down to > basic CSS1, AFAIK: > bold/italic/underline/strikethrough (some of which is possible with > OSIS already) > font size > borders, margin, padding > floating, sizing and positioning of images > Sizing and positioning of images potentially conflicts with programs like Xiphos that helpfully resize massive images to fit the screen size. It may also affect its display on devices with different form factors (e.g. iPhone and Android, which may not affect you, but also netbook resolutions). Do you want images to be displayed at a different size from their physical resolution ever? If so, why? My experience with floats tends to suggest that a float could accidentally break a layout, but at the same time they probably make sense. Sometimes specifying the font to use with foreign texts that might use > codepoints out of the range of normal fonts (remember, my modules come > from Wycliffe, who has the possibility of using some very arcane and > even novel combinations of characters and combining diacritics and the > like) > If it's something you need for the entire module, you might be better advised to use the Font config option, which is more designed to do that. I don't know which programs support it, though (I only found out about it very recently, and I don't think BPBible supports it). While I realise that strange codepoints may require strange fonts, I'm a little concerned about font being controlled by the module creator when it ends up inconsistent with everything else they have on screen and with their personal preference (for example, I would just about always have mine set to Verdana, which is a little ugly, but very readable). If you are doing it for sections of the text rather than the whole text there may also be places that look completely out of place. Nothing terribly earth shattering. In one instance per module we also > do the background color (teal) for the title of each work, but I have > not noticed any other such background colors. It's not like I want to > move heaven and earth with the CSS styling and break everything. :) > Sorry, we're software developers. Either it cannot break anything, or it has the potential to break something so we have to ban it because it probably will. :) Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfhmch at googlemail.com Sun Dec 5 05:54:40 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sun, 5 Dec 2010 04:54:40 -0800 (PST) Subject: [sword-devel] KJV.conf and Project KJV2006 ? In-Reply-To: <1291481003873-3072545.post@n4.nabble.com> References: <1291481003873-3072545.post@n4.nabble.com> Message-ID: <1291553680132-3073214.post@n4.nabble.com> KJV 2.4 is in the CrossWire beta repository. As Project KJV2003 seems to have been removed from the CrossWire server, all the more important to update references in the KJV.conf file to http://www.crosswire.org/~dmsmith/kjv2006/ KJV2006 instead. See http://www.crosswire.org/wiki/Modules_in_the_beta_repository#English_Bibles http://www.crosswire.org/wiki/Modules_in_the_beta_repository#English_Bibles David -- View this message in context: http://sword-dev.350566.n4.nabble.com/KJV-conf-and-Project-KJV2006-tp3072545p3073214.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dmsmith at crosswire.org Sun Dec 5 05:59:19 2010 From: dmsmith at crosswire.org (DM Smith) Date: Sun, 5 Dec 2010 07:59:19 -0500 Subject: [sword-devel] KJV.conf and Project KJV2006 ? In-Reply-To: <1291553680132-3073214.post@n4.nabble.com> References: <1291481003873-3072545.post@n4.nabble.com> <1291553680132-3073214.post@n4.nabble.com> Message-ID: David, The KJV2006 effort was a cleanup. Troy wanted to retain the name KJV2003. I think KJV1769 might be a better name. But I'll leave it up to Troy. DM On Dec 5, 2010, at 7:54 AM, David Haslam wrote: > > KJV 2.4 is in the CrossWire beta repository. > > As Project KJV2003 seems to have been removed from the CrossWire server, all > the more important to update references in the KJV.conf file to > http://www.crosswire.org/~dmsmith/kjv2006/ KJV2006 instead. > > See > http://www.crosswire.org/wiki/Modules_in_the_beta_repository#English_Bibles > http://www.crosswire.org/wiki/Modules_in_the_beta_repository#English_Bibles > > David > > > -- > View this message in context: http://sword-dev.350566.n4.nabble.com/KJV-conf-and-Project-KJV2006-tp3072545p3073214.html > Sent from the SWORD Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 From scribe at crosswire.org Sun Dec 5 06:12:48 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Sun, 05 Dec 2010 13:12:48 +0000 Subject: [sword-devel] KJV.conf and Project KJV2006 ? In-Reply-To: References: <1291481003873-3072545.post@n4.nabble.com> <1291553680132-3073214.post@n4.nabble.com> Message-ID: Well the logic behind the name was that the distinctness of our module was the inclusion of the interlinearization efforts of a large number of volunteers. Otherwise, I agree with DM that it should simply be the KJV1769. The date really has no significance. It was simply the easiest thing we could think of and had the bonus side effect of motivating the volunteers to finish in a year! But I would still like to keep the name as it gives us a name to point people to who want our unique interlinear data and honors the volunteers who did the laborious manual labor. Not that DM's laborious manual labor to update the markup isn't appreciated! Hope that makes sense or at least gives you an idea of why I prefer the name stay unchanged. "DM Smith" wrote: >David, >The KJV2006 effort was a cleanup. Troy wanted to retain the name >KJV2003. I think KJV1769 might be a better name. But I'll leave it up >to Troy. >DM > >On Dec 5, 2010, at 7:54 AM, David Haslam wrote: > >> >> KJV 2.4 is in the CrossWire beta repository. >> >> As Project KJV2003 seems to have been removed from the CrossWire >server, all >> the more important to update references in the KJV.conf file to >> http://www.crosswire.org/~dmsmith/kjv2006/ KJV2006 instead. >> >> See >> >http://www.crosswire.org/wiki/Modules_in_the_beta_repository#English_Bibles >> >http://www.crosswire.org/wiki/Modules_in_the_beta_repository#English_Bibles > >> >> David >> >> >> -- >> View this message in context: >http://sword-dev.350566.n4.nabble.com/KJV-conf-and-Project-KJV2006-tp3072545p3073214.html >> Sent from the SWORD Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > > >_______________________________________________ >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From dfhmch at googlemail.com Sun Dec 5 09:16:14 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sun, 5 Dec 2010 08:16:14 -0800 (PST) Subject: [sword-devel] KJV.conf and Project KJV2006 ? In-Reply-To: References: <1291481003873-3072545.post@n4.nabble.com> <1291553680132-3073214.post@n4.nabble.com>

Message-ID: <1291565774027-3073383.post@n4.nabble.com> Troy, I wasn't advocating a change of module name, merely observing that paragraphs in the .conf file refer to a KJV2003 project, which since has been superseded by KJV2006. Anyone reading the .conf file should be able to Google and find the project page, otherwise there is little point in naming it. There is even an email address kjv2003 at crosswire.org given in the .conf file. Does this still elicit a response from anyone, e.g. DM ? btw. I sent a test message to it yesterday. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/KJV-conf-and-Project-KJV2006-tp3072545p3073383.html Sent from the SWORD Dev mailing list archive at Nabble.com. From admin at remza.co.uk Mon Dec 6 04:00:24 2010 From: admin at remza.co.uk (David Hollands) Date: Mon, 6 Dec 2010 11:00:24 +0000 Subject: [sword-devel] XSLT vs. C++ In-Reply-To: <4CF54BBC.7080301@crosswire.org> References: <20101130151844.201750@gmx.net> <4CF54BBC.7080301@crosswire.org> Message-ID: Amen! http://hixie.ch/advocacy/xslt Love in Christ, David On 30 November 2010 19:08, Troy A. Griffitts wrote: > Having finally returned from a hectic 2 weeks of conferences, and lots > to do before leaving for Christmas, I'm not sure I'm up for a heated, > passionate debate about technologies right now, but by all means, please > commence the public discussion. > > Let me start by saying that everyone (I believe) agrees that we would > like to have an HTML output from the engine which is more generic and > would allow CSS to be applied if a frontend would like to do this. > Currently HTMLHREF output from the engine is used by the widest number > of frontends (to my knowledge) and would benefit everyone involved by > becoming much more generic. e.g., > > -> <h1> > rather than > <title> -> <b><br /> > > <transChange type="added"> -> <span class="tcAdded"> > rather than > <transChange type="added"> -> <i> > > etc. > > I believe this will solve a number of issues and possibly get the BT and > MacSword teams onboard to using the same HTML output filters as the > other projects involve (or at least subclassing them and using the > majority of their functionality). > > > Now, as to the other issue of using XSLT internally in the engine to > process OSIS -> HTML > > I will throw a few melons into the air for target practice, and let the > shooting commence. > > _____________________________ > *Multiple Language* > > XSLT is a programming language in the same sense that C++ is a > programming language. > > The SWORD Project C++ engine is written in C++. ?It is not a Python > engine; it is not a Perl engine; it is not a Java engine; it is C++. > > One might say, "Well, you can use XSLT from C++. ?Doesn't JSword do this > from Java?" ?Well, yes, of course you can, and DM can comment, if he > feels the desire to recommend his decision to encorporate an XSLT engine > into the JSword logic flow. ?But simply because one CAN doesn't mean one > SHOULD. ?We COULD encorporate a Perl text processing engine in our C++ > code, or an Awk processing engine... ?that doesn't mean we SHOULD. ?I'm > sure some would say we SHOULD. ?And obviously DM has thought he SHOULD > encorporate XSLT processing for JSword, so I'm not intending to say it > is a BAD decision, just that it is not a decision I would make; in the > same way as our projects each chose C++ vs. Java to implement our objective. > > _______________________ > *XSLT better than C++* > > One might say, "well, XSLT is better suited to process XML than C++." > That's a loaded and unquantified statement. > > Certainly the C++ language specification doesn't include facilities to > easily process XML, but that doesn't mean a plethora of C++ libraries > don't exists for assisting in this task. > > The SWORD engine includes classes like XMLTag and SWBasicFilter which > implement a SAX processing model. > > The current filters do not all use SWBasicFilter, nor XMLTag. ?They've > been written over 15 years and many before these classes existed. ?Some > are ugly and need to be rewritten for readability, certainly. ?But not > necessarily in a different programming language. > > ________________________ > *COMPLEXITY* > > The task of enumerating all types of OSIS <title> tags, and deciding > what to do with each, and how to classify all <title> tags from all > possible OSIS documents into our enumeration is still going to be a > complex task using XSLT. ?<title> is a complex example, but certainly > not the most complex. > > It is a tall task to generalize all elements of all documents from all > publishers into one conceptual model with one chosen output for a > frontend-- whether that be for an audience on the Desktop, web-based, or > a handheld. > > The complex processing required by the engine will require long, complex > XSLT-- which likely will encorporate callbacks to C++. ?It will not be > more simple-- only mixed language. > _______________________ > *Semantic vs. Display* > > Some will say (and have), "well, let everything be display oriented and > let the publisher decide". ?Fine, then you lose 2 things: the ability to > display differently per user preference, per display device; and you > also give up the promise to actually do any interesting research on the > text. ?When you lose semantic markup, then you lose all interesting > information about WHAT is being marked up. > > _______________________ > *More than a Rending Engine* > > The SWORD C++ Engine is more than simply a text rendering engine-- it is > a Biblical text research engine. > > If I'd like to know the morphology of word 3 in 2Thes 2.13 of the WHNU > Greek text, the entire program to do such is: > > SWMgr library; > SWModule *whnu = library.getModule("WHNU"); > whnu->setKey("2th.2.13"); > whnu->RenderText(); > > cout << "The morphology of word three is: " << > whnu->getEntryAttributes()["Word"]["003"]["Morph"] << endl; > > > That reads nice (at least in my opinion). ?I don't need to know about > XML, XSLT, care what markup the WHNU module uses, I don't even have to > know how to make a SWORD filter. ?The current filters do all the work of > breaking out these attributes and making them available in a nice and > interesting map. > > ______________________ > > > And finally, if bullets aren't flying already, I'll stir the heat up with... > > XSLT sucks. ?A good C++ programmer can do anything in C++ better than > any XSLT programmer. > > > :) > > *duck* > Have fun. > > Troy > > PS. ?In summary, I understand the current filters are sometimes overly > complex and need cleanup, standardization, etc. ?It comes down to the > fact that they mostly work, and other things which don't get priority, > so they don't get much attention. ?But honestly, I think one might be > oversimplifying the problem at hand without realizing it, if one simply > thinks switching to XSLT will make things easier. > > > _______________________________________________ > 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 > From jonathanbatteas at gmail.com Mon Dec 6 08:35:28 2010 From: jonathanbatteas at gmail.com (jonathan batteas) Date: Mon, 6 Dec 2010 10:35:28 -0500 Subject: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project Message-ID: <43939D32-72F0-40EE-A1CD-3BA229727021@gmail.com> I will try to keep this brief, I've been a member of this mailing list for years, and i'm really wanting to start working on a project that has been sitting in the back of my mind for quite a while. However, the programming is a little beyond my scope. I'm writing here to see if anyone would be interested in working on-or even simply discussing at greater detail- this project. It is basically an online system for the archiving and collaborative annotation and translation of high resolution digital images of original Scriptural Manuscripts, for the purpose of cross referencing different text types and collections. A brief overview, along with basic UI mockups can be seen here http://churchco.de/developing-a-platform-for- managing-editing-scriptural-documents/ I have shown this to many different people, including Bob Pritchett ceo at Logos Software. They all seem very interested, yet none have any resources to dedicate to the task at this time. So, now i am really trying to reach out to the open source community and see if anyone would be interested in helping with this in any way. Even just speaking with someone who has more experience programming in order to identify possible barriers, and discuss ways around them, would be incredibly useful. Thank you to anyone for your help and interest. Grace and Peace Jonathan Batteas http://pasceverbo.com From refdoc at gmx.net Mon Dec 6 09:29:40 2010 From: refdoc at gmx.net (Peter von Kaehne) Date: Mon, 06 Dec 2010 17:29:40 +0100 Subject: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project In-Reply-To: <43939D32-72F0-40EE-A1CD-3BA229727021@gmail.com> References: <43939D32-72F0-40EE-A1CD-3BA229727021@gmail.com> Message-ID: <20101206162940.74580@gmx.net> If you look into the archives you will see that Troy called for volunteers to do just that. There is an application and a group fo volunteers dealing with exactly this on the CrossWire community site Peter -------- Original-Nachricht -------- > Datum: Mon, 6 Dec 2010 10:35:28 -0500 > Von: jonathan batteas <jonathanbatteas at gmail.com> > An: sword-devel at crosswire.org > Betreff: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project > I will try to keep this brief, I've been a member of this mailing > list for years, and i'm really wanting to start working on a project > that has been sitting in the back of my mind for quite a while. > However, the programming is a little beyond my scope. I'm writing > here to see if anyone would be interested in working on-or even > simply discussing at greater detail- this project. It is basically an > online system for the archiving and collaborative annotation and > translation of high resolution digital images of original Scriptural > Manuscripts, for the purpose of cross referencing different text > types and collections. A brief overview, along with basic UI mockups > can be seen here http://churchco.de/developing-a-platform-for- > managing-editing-scriptural-documents/ > > I have shown this to many different people, including Bob Pritchett > ceo at Logos Software. They all seem very interested, yet none have > any resources to dedicate to the task at this time. So, now i am > really trying to reach out to the open source community and see if > anyone would be interested in helping with this in any way. Even just > speaking with someone who has more experience programming in order to > identify possible barriers, and discuss ways around them, would be > incredibly useful. Thank you to anyone for your help and interest. > Grace and Peace > Jonathan Batteas > http://pasceverbo.com > > _______________________________________________ > 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 -- GRATIS! Movie-FLAT mit ?ber 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome From scribe at crosswire.org Mon Dec 6 10:34:02 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Mon, 06 Dec 2010 17:34:02 +0000 Subject: [sword-devel] Google eBooks Message-ID: <4CFD1E8A.6080709@crosswire.org> Google Books-- what in its previous incarnation became http://print.google.com -- has been re-issued as an an online eBook store: http://books.google.com/help/ebooks/overview.html How does this affect us, and could we build a ModDrv for the Google eBook format for our engine so we could be a specialized Google eBook reader for Biblical material? Any thoughts? Troy From dfhmch at googlemail.com Mon Dec 6 12:02:07 2010 From: dfhmch at googlemail.com (David Haslam) Date: Mon, 6 Dec 2010 11:02:07 -0800 (PST) Subject: [sword-devel] Google eBooks In-Reply-To: <4CFD1E8A.6080709@crosswire.org> References: <4CFD1E8A.6080709@crosswire.org> Message-ID: <1291662127112-3075100.post@n4.nabble.com> Troy, Presumably you're thinking of the latter part of the sentence, "We offer the world's largest selection of ebooks -- hundreds of thousands of new titles for purchase, in addition to nearly 3 million free ebooks." ? I suppose that Google is doing this in direct competition with Amazon ? David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Google-eBooks-tp3074939p3075100.html Sent from the SWORD Dev mailing list archive at Nabble.com. From scribe at crosswire.org Mon Dec 6 16:25:27 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Mon, 06 Dec 2010 23:25:27 +0000 Subject: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project In-Reply-To: <43939D32-72F0-40EE-A1CD-3BA229727021@gmail.com> References: <43939D32-72F0-40EE-A1CD-3BA229727021@gmail.com> Message-ID: <4CFD70E7.2080806@crosswire.org> Dear Jonathan, Thank you for being interested! Yes, this is exactly what we'd like to build for INTF, ITSEE, CSNTM, and CNTTS (I trust people can google if they're not familiar with the acronyms above and below, but if you're interested in the TC world these are probably familiar to you) Where we are: The above mentioned organizations are the leading players in the NT TC world. They all have a good relationship with the others and are very willing to share in work together. ITSEE and INTF are partners on the ECM and IGNTP; CSNTM is happy to share images with anyone, including on the INTF's VMR; and CNTTS is working hard providing collations to ITSEE for the IGNTP. What they don't have is a collaborative online workspace and common standards to share their data easily. I am full time at ITSEE these days and trying to resolve some of these issues. We've only really just scratched the surface of what we want to do. My personal interest is 2-fold. First, CrossWire has hosted community collaboration projects in the past with great success, but the tools we built for the projects have been 'one-off, throw away' tools designed specifically for the projects. We'd like to build a community framework where we can host future projects for collaboration, e.g., more interlinearization projects like Arabic/Greek, which is high on our priority as we have an interested project leader. And second, I am interested in TC and would ultimately like to have a simple public site, http://ntmss.org which is similar to http://ntcanon.org (see their excellent [Table] link at the top) which does something similar by providing an easy to understand grid of the entire NT, book/chapter, with the oldest manuscript date in each chapters' square that attests to that chapter. Hovering over the cells would show a list of the oldest mss with their dates and clicking on the cell would take you to a detailed mss list with links to their images and transcriptions. We simply do not have the data available to do this. Most of the tools needed for this community will be custom tools. Not many people are doing this work (well, they are (google "interedition"), but not under the TC banner and they don't share many tools yet either). So, what we're planning, designing, and building are tools for: Volunteer and Project management Communication (listserv + chat) Specialized tools for: Image viewing, annotation, and discussion. (see http://labs.crosswire.org/papyritools.xpi) Image Indexing (see current CSNTM community project) Image Transcription (hardly anything yet at the ITSEE community project, but my daily work) Lots more have been in the back of our minds, but these are the immediate needs and we'll see where we go from here. Working at ITSEE gives us an ideal pilot project for these community tools; it contributes toward both my goals stated above. Jonathan, it sounds like God has given you a heart for just this kind of work. What are your talents and how would you like to contribute? I would love to work together with you; honestly, it has been quite lonely on this front as there isn't a huge interest from the current CrossWire engineers (/me ducks in hopes of getting a huge insurgence of response). Looking forward to sharing in work together, Troy On 12/06/2010 03:35 PM, jonathan batteas wrote: > I will try to keep this brief, I've been a member of this mailing list > for years, and i'm really wanting to start working on a project that has > been sitting in the back of my mind for quite a while. However, the > programming is a little beyond my scope. I'm writing here to see if > anyone would be interested in working on-or even simply discussing at > greater detail- this project. It is basically an online system for the > archiving and collaborative annotation and translation of high > resolution digital images of original Scriptural Manuscripts, for the > purpose of cross referencing different text types and collections. A > brief overview, along with basic UI mockups can be seen here > http://churchco.de/developing-a-platform-for-managing-editing-scriptural-documents/ > > > I have shown this to many different people, including Bob Pritchett ceo > at Logos Software. They all seem very interested, yet none have any > resources to dedicate to the task at this time. So, now i am really > trying to reach out to the open source community and see if anyone would > be interested in helping with this in any way. Even just speaking with > someone who has more experience programming in order to identify > possible barriers, and discuss ways around them, would be incredibly > useful. Thank you to anyone for your help and interest. > Grace and Peace > Jonathan Batteas > http://pasceverbo.com > > _______________________________________________ > 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 From chrislit at crosswire.org Mon Dec 6 23:11:27 2010 From: chrislit at crosswire.org (Chris Little) Date: Mon, 06 Dec 2010 22:11:27 -0800 Subject: [sword-devel] Google eBooks In-Reply-To: <4CFD1E8A.6080709@crosswire.org> References: <4CFD1E8A.6080709@crosswire.org> Message-ID: <4CFDD00F.7000301@crosswire.org> On 12/6/2010 9:34 AM, Troy A. Griffitts wrote: > Google Books-- what in its previous incarnation became > http://print.google.com -- has been re-issued as an an online eBook store: > > http://books.google.com/help/ebooks/overview.html > > How does this affect us, and could we build a ModDrv for the Google > eBook format for our engine so we could be a specialized Google eBook > reader for Biblical material? I've been working (on and off) at making some of our material available for eBook readers (in mobi/Kindle and EPUB formats) as well as POD. Google is using EPUB, as they have been for quite a while. Outputting modules to EPUB docs is essentially a matter of running them through the *HTML(HREF) filters and adding headers/footers/interstitials. This is essentially the work that my Diaspora program used to do. My own plan for converting our texts to EPUB, mobi, & PDF was to use the source docs, since they don't go through osis2mod, and apply some XSLT to generate XHTML & LaTeX. > Any thoughts? My general thoughts on the Google eBook store are that it has one significant advantage relative to Amazon & Apple, and that's their huge catalog of scanned PD texts, which come in the shape of PDFs. Since they're scanned pages (and not OCRed and reflowed), the PD works look great on an iPad or a computer screen. Personally, I don't want to read books on either of those devices. I want to read books on an E Ink reader, and those don't tend to be larger than 7". So all of Google's scanned PD ebooks will be pretty much unusable on the readers most people would want to use (dedicated ebook readers and smartphones) because the pages don't reflow, requiring scaling or scrolling. The best piece of hardware for Google eBooks would probably be the Kindle DX, but Kindles are specifically excluded from the Google store (though I realize that is mostly Amazon's fault). As far as selection of non-PD material goes, I'm not terribly impressed. Amazon, Apple, & Google each have different sets books available, but I believe Amazon still leads overall. Completely unscientifically: Of the four books being used for the class I'm teaching in spring, three are available in each of the stores, but Amazon has one set of three and Apple & Google share a different set of three. --Chris From greg.hellings at gmail.com Mon Dec 6 23:24:49 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Tue, 7 Dec 2010 00:24:49 -0600 Subject: [sword-devel] Google eBooks In-Reply-To: <4CFDD00F.7000301@crosswire.org> References: <4CFD1E8A.6080709@crosswire.org> <4CFDD00F.7000301@crosswire.org> Message-ID: <AANLkTinvywAZnmNsOYKtsT=jwV9SdZ4ASM9oetm2wS_x@mail.gmail.com> On Tue, Dec 7, 2010 at 12:11 AM, Chris Little <chrislit at crosswire.org> wrote: > On 12/6/2010 9:34 AM, Troy A. Griffitts wrote: > As far as selection of non-PD material goes, I'm not terribly impressed. > Amazon, Apple, & Google each have different sets books available, but I > believe Amazon still leads overall. Completely unscientifically: Of the four > books being used for the class I'm teaching in spring, three are available > in each of the stores, but Amazon has one set of three and Apple & Google > share a different set of three. One of the nice things that Apple has not (yet) done is block the Amazon Kindle app from its store. So a user of an iPad or iPhone can access their Amazon Kindle collection from their iDevice. They also have an application for Android users to do the same. I don't know if Google has an application like that or if their books are compatible with other ebook readers which might be available on those platforms - though their scans of the PD works would still suffer the scrolling issues. I'd be astounded if Apple's ebooks are useful on anything other than an iDevice without some major hacking. I would think some of the HTML widgets which our applications use might be use could potentially know how to handle an external application already to display a PDF (MacSword's embedding of Safari and possibly BT's embedding of QWebKit? Maybe Xiphos with Xulrunner? Would be an interesting trick to see if the widgets support the plugins on the system the way the full browsers do). For BibleCS, you're on your own, Troy. ;-) --Greg From ransom1982 at gmail.com Mon Dec 6 23:30:29 2010 From: ransom1982 at gmail.com (Matthew Talbert) Date: Tue, 7 Dec 2010 01:30:29 -0500 Subject: [sword-devel] Google eBooks In-Reply-To: <AANLkTinvywAZnmNsOYKtsT=jwV9SdZ4ASM9oetm2wS_x@mail.gmail.com> References: <4CFD1E8A.6080709@crosswire.org> <4CFDD00F.7000301@crosswire.org> <AANLkTinvywAZnmNsOYKtsT=jwV9SdZ4ASM9oetm2wS_x@mail.gmail.com> Message-ID: <AANLkTim=VwPA0Sfu4C9uh97K4mq+ABeCgLkk+WGbG+Dp@mail.gmail.com> > I would think some of the HTML widgets which our applications use > might be use could potentially know how to handle an external > application already to display a PDF (MacSword's embedding of Safari > and possibly BT's embedding of QWebKit? ?Maybe Xiphos with Xulrunner? > Would be an interesting trick to see if the widgets support the > plugins on the system the way the full browsers do). ?For BibleCS, > you're on your own, Troy. ;-) I'm still trying to parse that first sentence.... Google doesn't always allow retrieving the actual pdf, but I think Xiphos with xulrunner would be able to display the normal web-based reader already. Using the plugins in the widgets is not a straightforward thing; I think it varies from one to the other, but I think it would be difficult to get working on xulrunner. Matthew From chrislit at crosswire.org Tue Dec 7 01:36:35 2010 From: chrislit at crosswire.org (Chris Little) Date: Tue, 07 Dec 2010 00:36:35 -0800 Subject: [sword-devel] Google eBooks In-Reply-To: <AANLkTinvywAZnmNsOYKtsT=jwV9SdZ4ASM9oetm2wS_x@mail.gmail.com> References: <4CFD1E8A.6080709@crosswire.org> <4CFDD00F.7000301@crosswire.org> <AANLkTinvywAZnmNsOYKtsT=jwV9SdZ4ASM9oetm2wS_x@mail.gmail.com> Message-ID: <4CFDF213.8000705@crosswire.org> On 12/6/2010 10:24 PM, Greg Hellings wrote: > I don't know if Google has an application like that or if their books > are compatible with other ebook readers which might be available on > those platforms - though their scans of the PD works would still > suffer the scrolling issues. Google has apps for iOS & Android, plus support on desktops and Sony (recent, not the original, to my knowledge) & Nook readers, but not Kindle. But those scanned books would only look particularly good on an iPad or similar device with a 9"+ display, and personally I can't read books on the iPad, due to its weight and the glossy screen. > I'd be astounded if Apple's ebooks are useful on anything other than > an iDevice without some major hacking. Apple's ebooks are EPUB, but with the standard iTunes DRM that they used to apply to music and still apply to apps (Fairplay). So, without cracking the DRM, their ebooks are locked into iBooks on iOS. Nevertheless, iBooks can read unprotected EPUB & PDF content from non-Apple sources. So most of Google's PD content has already been available for use in iBooks for a long time now, not to mention on Kindle, via EPUB to mobi conversion. --Chris From greg.hellings at gmail.com Tue Dec 7 07:38:50 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Tue, 7 Dec 2010 08:38:50 -0600 Subject: [sword-devel] CMake Sample Scripts Message-ID: <AANLkTim3_u-YCFaVSrU3yWhYyH=G8W4zD0CudsFxkgG-@mail.gmail.com> All, For those who would like to try out the CMake build system, but you don't want to learn a new way to invoke the SWORD build process, I have added a pair of sample scripts to the cmake/ directory. Both of the samples will build the shared (.so) library, Perl and Python bindings, examples/cmdline and tests. One will build the debug version of the library prepped for installation to /usr/local and the other will build a release version of the library for installation to /opt/sword. To invoke the build, you can just camp in the top directory of the SWORD library and issue the call "$ cmake/build-debug.sh" or "$ cmake/build-release.sh". Both scripts will create a build/ directory, change into it, call CMake, call make with 5 parallel builds, change into the Perl directory, call make there, and then change into the python directory and call the build process there. It will then be up to the user to manually invoke the 'make install' in the build directory. I'm not particularly claiming this is the way you should invoke the CMake system, but more intending the scripts as a sample way of showing people how CMake is invoked and how to use some of its options. Also, have no fear if you prefer the autotools version of the library but you just want to take a look at CMake. CMake forces the build to be outside of the current source directory, so that none of its files come into collision with an autotools build of the library. In the example of the cmake/build-*.sh scripts, all the products of the CMake process are contained in the build/ directory, so if you mess something up you can just "$ rm -rf build/" and everything is back to the way it was before. --Greg From jonathanbatteas at gmail.com Tue Dec 7 12:20:07 2010 From: jonathanbatteas at gmail.com (jonathan batteas) Date: Tue, 7 Dec 2010 14:20:07 -0500 Subject: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project In-Reply-To: <mailman.368.1291711149.2051.sword-devel@crosswire.org> References: <mailman.368.1291711149.2051.sword-devel@crosswire.org> Message-ID: <5193E4AB-E7AB-4A8F-B0F8-C74818F03557@gmail.com> Dear Troy, It is great to speak with you. I'm not sure how I could have possibly missed this before, as I've been a member of this mailing list for at least 4 years now, and I've been thinking of this project for just as long. Oh well, God's timing. I am very excited to help with this project in any way that I can. I have general web dev experience, but nothing that could touch the level of programming this would require. I am mainly a UI and design guy. I am very interested in usability, because as I envision it, this could almost be like, wikipedia for scriptural translation and study, (error checking and quality control is important, as we are dealing with The Word of God) but in order to achieve this, the very complex systems of annotation etc. must be accessed though a very simple and intuitive interface. If this can be accomplished, I could see forming partnerships with seminaries, research institutes, etc. and having a constant flow of information into the system through students which would use it for class credit, and which would rotate every four years. I know my talents are possibly the least useful at this point in the project, but please, let me know what I can do. I can write emails, make phone calls, design mockups, give suggestions and thoughts. Anything I can do, I will. This project has been on my heart for a long time. It is very important to me, because it was through my study into these manuscripts that I came to really trust Christ. I even always called the project, "the ad fontes project. " Ad Fontes, of course, meaning "to the sources," or, "to the fountain." Anything I can do to help, please assign me a role, and I will work on it. I so believe in this project, that if you need someone to lick envelopes,...I will do it. Thank you. On Dec 7, 2010, at 3:39 AM, sword-devel-request at crosswire.org wrote: > > ------------------------------ > > Message: 2 > Date: Mon, 06 Dec 2010 23:25:27 +0000 > From: "Troy A. Griffitts" <scribe at crosswire.org> > To: sword-devel at crosswire.org > Subject: Re: [sword-devel] Looking for help/direction with Scriptural > Archiving Study Project > Message-ID: <4CFD70E7.2080806 at crosswire.org> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear Jonathan, > > Thank you for being interested! Yes, this is exactly what we'd > like to > build for INTF, ITSEE, CSNTM, and CNTTS (I trust people can google if > they're not familiar with the acronyms above and below, but if you're > interested in the TC world these are probably familiar to you) > > Where we are: > > The above mentioned organizations are the leading players in the NT TC > world. They all have a good relationship with the others and are very > willing to share in work together. ITSEE and INTF are partners on the > ECM and IGNTP; CSNTM is happy to share images with anyone, > including on > the INTF's VMR; and CNTTS is working hard providing collations to > ITSEE > for the IGNTP. > > What they don't have is a collaborative online workspace and common > standards to share their data easily. > > I am full time at ITSEE these days and trying to resolve some of these > issues. > > We've only really just scratched the surface of what we want to > do. My > personal interest is 2-fold. > > First, CrossWire has hosted community collaboration projects in the > past > with great success, but the tools we built for the projects have been > 'one-off, throw away' tools designed specifically for the projects. > We'd like to build a community framework where we can host future > projects for collaboration, e.g., more interlinearization projects > like > Arabic/Greek, which is high on our priority as we have an interested > project leader. > > And second, I am interested in TC and would ultimately like to have a > simple public site, http://ntmss.org which is similar to > http://ntcanon.org (see their excellent [Table] link at the top) which > does something similar by providing an easy to understand grid of the > entire NT, book/chapter, with the oldest manuscript date in each > chapters' square that attests to that chapter. Hovering over the > cells > would show a list of the oldest mss with their dates and clicking > on the > cell would take you to a detailed mss list with links to their images > and transcriptions. We simply do not have the data available to do > this. > > Most of the tools needed for this community will be custom tools. Not > many people are doing this work (well, they are (google > "interedition"), > but not under the TC banner and they don't share many tools yet > either). > > So, what we're planning, designing, and building are tools for: > > Volunteer and Project management > Communication (listserv + chat) > Specialized tools for: > Image viewing, annotation, and discussion. > (see http://labs.crosswire.org/papyritools.xpi) > Image Indexing (see current CSNTM community project) > Image Transcription > (hardly anything yet at the ITSEE community project, but my daily > work) > > Lots more have been in the back of our minds, but these are the > immediate needs and we'll see where we go from here. > > Working at ITSEE gives us an ideal pilot project for these community > tools; it contributes toward both my goals stated above. > > > Jonathan, it sounds like God has given you a heart for just this > kind of > work. What are your talents and how would you like to contribute? I > would love to work together with you; honestly, it has been quite > lonely > on this front as there isn't a huge interest from the current > CrossWire > engineers (/me ducks in hopes of getting a huge insurgence of > response). > > Looking forward to sharing in work together, > > Troy > > > > > > > > On 12/06/2010 03:35 PM, jonathan batteas wrote: >> I will try to keep this brief, I've been a member of this mailing >> list >> for years, and i'm really wanting to start working on a project >> that has >> been sitting in the back of my mind for quite a while. However, the >> programming is a little beyond my scope. I'm writing here to see if >> anyone would be interested in working on-or even simply discussing at >> greater detail- this project. It is basically an online system for >> the >> archiving and collaborative annotation and translation of high >> resolution digital images of original Scriptural Manuscripts, for the >> purpose of cross referencing different text types and collections. A >> brief overview, along with basic UI mockups can be seen here >> http://churchco.de/developing-a-platform-for-managing-editing- >> scriptural-documents/ >> >> >> I have shown this to many different people, including Bob >> Pritchett ceo >> at Logos Software. They all seem very interested, yet none have any >> resources to dedicate to the task at this time. So, now i am really >> trying to reach out to the open source community and see if anyone >> would >> be interested in helping with this in any way. Even just speaking >> with >> someone who has more experience programming in order to identify >> possible barriers, and discuss ways around them, would be incredibly >> useful. Thank you to anyone for your help and interest. >> Grace and Peace >> Jonathan Batteas >> http://pasceverbo.com >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101207/340324db/attachment-0001.html> From scribe at crosswire.org Tue Dec 7 13:13:01 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Tue, 07 Dec 2010 20:13:01 +0000 Subject: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project In-Reply-To: <5193E4AB-E7AB-4A8F-B0F8-C74818F03557@gmail.com> References: <mailman.368.1291711149.2051.sword-devel@crosswire.org> <5193E4AB-E7AB-4A8F-B0F8-C74818F03557@gmail.com> Message-ID: <4CFE954D.4050802@crosswire.org> On 12/07/2010 07:20 PM, jonathan batteas wrote: > ... I have general web dev experience, but nothing > that could touch the level of programming this would require. I am > mainly a UI and design guy. I am very interested in usability,... Jonathan, this is EXACTLY what we need right now. I am focusing on the functionality that the team here needs. Ask anyone on this list, I SUCK at aesthetics! Take the CSNTM indexing status page. If you login at http://community.crosswire.org, then go to Projects, then CSNTM Indexing, and look at the status page there, you'll see it is simply an HTML table with all the bits volunteers and managers need to see. It's functional but absolutely ugly. If you could design an HTML page with all the same features on it, I can encorporate your static html into my dynamic page which will produce the live data using your shiny new design. Does this sound like something that interests you? Troy From jonathanbatteas at gmail.com Tue Dec 7 16:41:37 2010 From: jonathanbatteas at gmail.com (Jonathanbatteas) Date: Tue, 7 Dec 2010 18:41:37 -0500 Subject: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project In-Reply-To: <AANLkTi=xrmG062jTW6zPbRMNMSSqLi_D+xAknZ_+DH4d@mail.gmail.com> References: <mailman.368.1291711149.2051.sword-devel@crosswire.org> <5193E4AB-E7AB-4A8F-B0F8-C74818F03557@gmail.com> <4CFE954D.4050802@crosswire.org> <AANLkTi=xrmG062jTW6zPbRMNMSSqLi_D+xAknZ_+DH4d@mail.gmail.com> Message-ID: <EAE1F0FE-AD20-4BEF-876B-C9CEB2F9BDA0@gmail.com> Troy I can definitely do that. However, I wanted to ask a couple quick questions. The specs for this project are pretty broad, and I could really see something like this leveraging a social network aspect, profile, chat, messaging, sharing studies, and keeping track of individual users' annotations. Has the option of using existing open source content management systems as a base for this application been discussed? There are literally thousands of them out there, many of which could fit the bill as a base for this system I am most familiar with Joomla, so I'll use that as an example. It is written in PHP, rather than JSP, but since most of the custom work is going to be done with JavaScript in the viewer, all of this work could be ported easily. Joomla has an open source, though not free, social network component called JomSocial, into which it would be fairly straight forward to created the viewer/annotation component as a plugin (would that be something you would consider working on Mike? You mentioned PHP). All that would be needed are some database tables to store the information and link that information to the users' profiles. User management and content (images for the manuscripts) management would already be built into the base system. Though this method might take a little extra work to learn the specifics of whatever system was chosen as a base, it still could take much less time than programming the entire thing from scratch. No pressure at all, but if we did want to go this direction, I have a domain license for JomSocial that I would be happy to give to this project. Consider it my small donation. Anyway, I'd be happy to work on some design for what you have so far, what would the best way of looking at what you have so far (source)? Or is it all located in the index file for the viewer? I'm away from my computer right now, so I haven't had a chance to check. Thanks. Talk to you later. On 12/07/2010 07:20 PM, jonathan batteas wrote: > ... I have general web dev experience, but nothing > that could touch the level of programming this would require. I am > mainly a UI and design guy. I am very interested in usability,... Jonathan, this is EXACTLY what we need right now. I am focusing on the functionality that the team here needs. Ask anyone on this list, I SUCK at aesthetics! Take the CSNTM indexing status page. If you login at http://community.crosswire.org, then go to Projects, then CSNTM Indexing, and look at the status page there, you'll see it is simply an HTML table with all the bits volunteers and managers need to see. It's functional but absolutely ugly. If you could design an HTML page with all the same features on it, I can encorporate your static html into my dynamic page which will produce the live data using your shiny new design. Does this sound like something that interests you? Troy Sent from my iPod On Dec 7, 2010, at 5:55 PM, Mike Hagedon <mike at cainscape.com> wrote: > Troy, > Thanks for reposting that... I had forgotten how to get there. > > Now that I am there, I can't remember how to attach the images to the records. I'm looking at ANA Fragment 12; my username is mike. > > Also, if you wanted any PHP work (I see it's JSP now), I'd be interested in that after my thesis is finished in May. Also, I can contribute jQuery help if that's needed. > > Mike Hagedon > Tucson, AZ > (Also a long-time lurker) > > On Tue, Dec 7, 2010 at 1:13 PM, Troy A. Griffitts <scribe at crosswire.org> wrote: > On 12/07/2010 07:20 PM, jonathan batteas wrote: > > ... I have general web dev experience, but nothing > > that could touch the level of programming this would require. I am > > mainly a UI and design guy. I am very interested in usability,... > > Jonathan, this is EXACTLY what we need right now. I am focusing on the > functionality that the team here needs. Ask anyone on this list, I SUCK > at aesthetics! > > Take the CSNTM indexing status page. If you login at > http://community.crosswire.org, then go to Projects, then CSNTM > Indexing, and look at the status page there, you'll see it is simply an > HTML table with all the bits volunteers and managers need to see. It's > functional but absolutely ugly. If you could design an HTML page with > all the same features on it, I can encorporate your static html into my > dynamic page which will produce the live data using your shiny new design. > > Does this sound like something that interests you? > > Troy > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101207/9f5bb1ec/attachment.html> From scribe at crosswire.org Tue Dec 7 19:49:02 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Wed, 08 Dec 2010 02:49:02 +0000 Subject: [sword-devel] Looking for help/direction with Scriptural Archiving Study Project In-Reply-To: <EAE1F0FE-AD20-4BEF-876B-C9CEB2F9BDA0@gmail.com> References: <mailman.368.1291711149.2051.sword-devel@crosswire.org> <5193E4AB-E7AB-4A8F-B0F8-C74818F03557@gmail.com> <4CFE954D.4050802@crosswire.org> <AANLkTi=xrmG062jTW6zPbRMNMSSqLi_D+xAknZ_+DH4d@mail.gmail.com> <EAE1F0FE-AD20-4BEF-876B-C9CEB2F9BDA0@gmail.com> Message-ID: <4CFEF21E.2070305@crosswire.org> Thanks for the comment Jonathan, Yes, we've discussed using a social networking system and are leaning toward opensocial right now because there are a number of projects in the humanities (members of interedition) who have built useful tools in disparate technologies who would like to collaborate. Here is a sample opensocial container showing pub/sub functionality between a client gadget and our image viewer as a gadget: http://community.crosswire.org/viewer.html http://crosswire.org/svn/community/trunk/webapp/viewer.html You'll see the source is very minimal and allows gadgets to be embedded from any number of other sites. There are a zillion opensocial gadgets already available for us to use (see http://igoogle.com) and there are containers written in a ton of different languages, so others can use our gadgets no matter what language they prefer. Hope this is convincing. Troy On 12/07/2010 11:41 PM, Jonathanbatteas wrote: > Troy I can definitely do that. > > However, I wanted to ask a couple quick questions. The specs for this project are pretty broad, and I could really see something like this leveraging a social network aspect, profile, chat, messaging, sharing studies, and keeping track of individual users' annotations. Has the option of using existing open source content management systems as a base for this application been discussed? There are literally thousands of them out there, many of which could fit the bill as a base for this system > > I am most familiar with Joomla, so I'll use that as an example. It is written in PHP, rather than JSP, but since most of the custom work is going to be done with JavaScript in the viewer, all of this work could be ported easily. Joomla has an open source, though not free, social network component called JomSocial, into which it would be fairly straight forward to created the viewer/annotation component as a plugin (would that be something you would consider working on Mike? You mentioned PHP). All that would be needed are some database tables to store the information and link that information to the users' profiles. User management and content (images for the manuscripts) management would already be built into the base system. > > Though this method might take a little extra work to learn the specifics of whatever system was chosen as a base, it still could take much less time than programming the entire thing from scratch. > > No pressure at all, but if we did want to go this direction, I have a domain license for JomSocial that I would be happy to give to this project. Consider it my small donation. > > Anyway, I'd be happy to work on some design for what you have so far, what would the best way of looking at what you have so far (source)? Or is it all located in the index file for the viewer? I'm away from my computer right now, so I haven't had a chance to check. Thanks. Talk to you later. > > On 12/07/2010 07:20 PM, jonathan batteas wrote: >>/ ... I have general web dev experience, but nothing > />/ that could touch the level of programming this would require. I am > />/ mainly a UI and design guy. I am very interested in usability,... > / > Jonathan, this is EXACTLY what we need right now. I am focusing on the > functionality that the team here needs. Ask anyone on this list, I SUCK > at aesthetics! > > Take the CSNTM indexing status page. If you login at > <http://community.crosswire.org,>http://community.crosswire.org, then go to Projects, then CSNTM > Indexing, and look at the status page there, you'll see it is simply an > HTML table with all the bits volunteers and managers need to see. It's > functional but absolutely ugly. If you could design an HTML page with > all the same features on it, I can encorporate your static html into my > dynamic page which will produce the live data using your shiny new design. > > Does this sound like something that interests you? > > Troy > > > > > Sent from my iPod > > On Dec 7, 2010, at 5:55 PM, Mike Hagedon <mike at cainscape.com > <mailto:mike at cainscape.com>> wrote: > >> Troy, >> Thanks for reposting that... I had forgotten how to get there. >> >> Now that I am there, I can't remember how to attach the images to the >> records. I'm looking at ANA Fragment 12; my username is mike. >> >> Also, if you wanted any PHP work (I see it's JSP now), I'd be >> interested in that after my thesis is finished in May. Also, I can >> contribute jQuery help if that's needed. >> >> Mike Hagedon >> Tucson, AZ >> (Also a long-time lurker) >> >> On Tue, Dec 7, 2010 at 1:13 PM, Troy A. Griffitts >> <<mailto:scribe at crosswire.org>scribe at crosswire.org >> <mailto:scribe at crosswire.org>> wrote: >> >> On 12/07/2010 07:20 PM, jonathan batteas wrote: >> > ... I have general web dev experience, but nothing >> > that could touch the level of programming this would require. I am >> > mainly a UI and design guy. I am very interested in usability,... >> >> Jonathan, this is EXACTLY what we need right now. I am focusing >> on the >> functionality that the team here needs. Ask anyone on this list, >> I SUCK >> at aesthetics! >> >> Take the CSNTM indexing status page. If you login at >> <http://community.crosswire.org>http://community.crosswire.org, >> then go to Projects, then CSNTM >> Indexing, and look at the status page there, you'll see it is >> simply an >> HTML table with all the bits volunteers and managers need to see. >> It's >> functional but absolutely ugly. If you could design an HTML page with >> all the same features on it, I can encorporate your static html >> into my >> dynamic page which will produce the live data using your shiny new >> design. >> >> Does this sound like something that interests you? >> >> Troy >> >> >> _______________________________________________ >> sword-devel mailing list: >> <mailto:sword-devel at crosswire.org>sword-devel at crosswire.org >> <mailto:sword-devel at 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 >> >> From dfhmch at googlemail.com Thu Dec 9 14:16:16 2010 From: dfhmch at googlemail.com (David Haslam) Date: Thu, 9 Dec 2010 13:16:16 -0800 (PST) Subject: [sword-devel] WBTI/BL modules in CrossWire Beta Message-ID: <1291929376154-3081010.post@n4.nabble.com> The 43 http://crosswire.org/wiki/WBTI_Bible_discussion modules we were given a long time ago do rather swamp the module manager when http://crosswire.org/wiki/Modules_in_the_beta_repository CrossWire Beta is selected. This makes it hard to see the wood for the trees. Ploughing past all those unusual language names is quite a chore. 43 / 109 is almost 40% of the beta repo. I suspect that few users would wish to install any of these, unless they happen to be involved in ministry in Central America or the Caribbean region. Thus they have a highly specialized focus. Would it not be a good idea to have these in a separate repository? What do others think? David -- View this message in context: http://sword-dev.350566.n4.nabble.com/WBTI-BL-modules-in-CrossWire-Beta-tp3081010p3081010.html Sent from the SWORD Dev mailing list archive at Nabble.com. From greg.hellings at gmail.com Thu Dec 9 14:54:31 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Thu, 9 Dec 2010 15:54:31 -0600 Subject: [sword-devel] WBTI/BL modules in CrossWire Beta In-Reply-To: <1291929376154-3081010.post@n4.nabble.com> References: <1291929376154-3081010.post@n4.nabble.com> Message-ID: <AANLkTikYdp=t_z3vC5h39ZQJ7+uadn1oH2M=9NbhTb1_@mail.gmail.com> Beta more or less is our "separate repository." In reality our end users shouldn't be in Beta. In the past modules have been known to get stuck in Beta for uncertain reasons. I'd take a guess the reasons involve some mixture of the following: 1) Very few people knowing exactly why a module was Beta - was it new? Was a bug fixed? Were new features added? Therefore there was little direction for the testers to take. 2) Most of our list, who are largely either developers or module creators to begin with, got in the habit of using the Beta repository while waiting, so we were not very vocal about goading people to release updated versions. And since we are most of the voices here and the voices of users tended not to know about the Beta, there was little incentive to move forward. 3) Often modules come in large dumps, like you're mentioning, and frankly I don't have the time or talents to learn 43 languages AND read through the Bible 43 times to test. And if we don't know anyone who does know that language, what are we to do while waiting for a "Hey, I read through that and it seemed well put together, let's publish it." 4) For a long time only Chris Little had rights to move from one repository to the other. This might still be the case. If so, only one person to process 109 modules, plus be responsible for creating them from source materials and probably fix the reported bugs is a massive undertaking. However, due to the exceedingly high standards for modules in CrossWire's repositories, very few other people would have Chris' attention to detail. If I go much farther I probably will end up getting into the numerous objections where some people prefer the "release early, release often" method and others prefer the "wait until it's perfect" method. CW repos tend to wait longer until release while Karl tends to do the quick iteration approach. As a result, using "Beta" became mainstream as a user would report "My module is broken in such-and-such a passage" and they would be told to try the version in Beta and they would say "All better, thanks." Thus a bad habit of pointing users to testing material led to "Beta" becoming used in production - observe the KJV 2.4 in Beta which nearly everyone ueses while 2.3 continues on in the "released" stream complete with all of its quirks and invalid OSIS from the old importer. --Greg On Thu, Dec 9, 2010 at 3:16 PM, David Haslam <dfhmch at googlemail.com> wrote: > > The 43 ?http://crosswire.org/wiki/WBTI_Bible_discussion modules ?we were > given a long time ago do rather swamp the module manager when > http://crosswire.org/wiki/Modules_in_the_beta_repository CrossWire Beta ?is > selected. > > This makes it hard to see the wood for the trees. Ploughing past all those > unusual language names is quite a chore. > > 43 ?/ 109 is almost 40% of the beta repo. > > I suspect that few users would wish to install any of these, unless they > happen to be involved in ministry in Central America or the Caribbean > region. Thus they have a highly specialized focus. > > Would it not be a good idea to have these in a separate repository? > > What do others think? > > David > -- > View this message in context: http://sword-dev.350566.n4.nabble.com/WBTI-BL-modules-in-CrossWire-Beta-tp3081010p3081010.html > Sent from the SWORD Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 > From dfhmch at googlemail.com Fri Dec 10 03:51:44 2010 From: dfhmch at googlemail.com (David Haslam) Date: Fri, 10 Dec 2010 02:51:44 -0800 (PST) Subject: [sword-devel] WBTI/BL modules in CrossWire Beta In-Reply-To: <AANLkTikYdp=t_z3vC5h39ZQJ7+uadn1oH2M=9NbhTb1_@mail.gmail.com> References: <1291929376154-3081010.post@n4.nabble.com> <AANLkTikYdp=t_z3vC5h39ZQJ7+uadn1oH2M=9NbhTb1_@mail.gmail.com> Message-ID: <1291978304640-3081740.post@n4.nabble.com> Thanks Greg, I spent several happy hours yesterday evening updating the wiki page. http://crosswire.org/wiki/Modules_in_the_beta_repository http://crosswire.org/wiki/Modules_in_the_beta_repository Not because I have any new testing results to report, but rather because the tables were poorly populated. Every row now has a date in the date column. Yes! Modules not now in the beta have been removed, with the cut entries pasted into a new section of the talk page. There are 105 modules listed, so I need to track down which are the four not yet in the tables. The same wiki page also has a section about CrossWire Experimental. IMHO, this should be moved to a separate page. It's confusing to have it in the beta page. And there are now many more experimental modules than are listed in this section. PS. Comparing KJV v2.4 to KJV v2.3 is another story. I sent an email to DM about this. The beta module is still in a pickle with some front-ends. Anyone who wishes to discuss this should start a separate thread. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/WBTI-BL-modules-in-CrossWire-Beta-tp3081010p3081740.html Sent from the SWORD Dev mailing list archive at Nabble.com. From niccarter at mac.com Sat Dec 11 02:16:51 2010 From: niccarter at mac.com (Nic Carter) Date: Sat, 11 Dec 2010 20:16:51 +1100 Subject: [sword-devel] WBTI/BL modules in CrossWire Beta In-Reply-To: <AANLkTikYdp=t_z3vC5h39ZQJ7+uadn1oH2M=9NbhTb1_@mail.gmail.com> References: <1291929376154-3081010.post@n4.nabble.com> <AANLkTikYdp=t_z3vC5h39ZQJ7+uadn1oH2M=9NbhTb1_@mail.gmail.com> Message-ID: <51AD4E61-2AA3-4208-A59C-BAA40DC7F2AD@mac.com> On 10/12/2010, at 8:54 AM, Greg Hellings wrote: > 2) Most of our list, who are largely either developers or module > creators to begin with, got in the habit of using the > Beta repository while waiting, so we were not very vocal about goading > people to release updated versions. And since we are most of the > voices here and the voices of users tended not to know about the Beta, > there was little incentive to move forward. As the Beta repo is included in the master repo list, most users will automatically have it presented to them in their download managers in the various frontends available. I know that there was a fair bit of pressure for PS to have Beta available, as there are several languages that only have Bibles available in Beta and not in the primary one (Japanese being one example), and so I did include it from v1.0, even though I renamed it to "CrossWire 2" (naming the primary one "CrossWire 1"). :) But, as we are talking about repositories again, it might be a nice time to hit the gong about pulling our av11n modules out of experimental and make them available for our users! I have had a few more requests since the last time I rang the gong... :) Thanks heaps, ybic nic... :) ps: My opinion is that frontends should have a means of sorting modules in their download managers by language, and so having a large number of modules in languages you don't understand shouldn't be a problem, as you simply look for modules in the languages you are after. :) In fact, I made the decision with PS (for v1.0) to only list modules from one language at a time, which may or may not be the best way to do things, but I picked that at the start and don't have time to go back and revisit it at this point... pps: As for "release early, release often", I'm of the opinion of: "if you?re not embarrassed when you ship your first version you waited too long." taken from http://ma.tt/2010/11/one-point-oh/ From dfhmch at googlemail.com Sat Dec 11 02:32:05 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sat, 11 Dec 2010 01:32:05 -0800 (PST) Subject: [sword-devel] WBTI/BL modules in CrossWire Beta In-Reply-To: <51AD4E61-2AA3-4208-A59C-BAA40DC7F2AD@mac.com> References: <1291929376154-3081010.post@n4.nabble.com> <AANLkTikYdp=t_z3vC5h39ZQJ7+uadn1oH2M=9NbhTb1_@mail.gmail.com> <51AD4E61-2AA3-4208-A59C-BAA40DC7F2AD@mac.com> Message-ID: <1292059925737-3083129.post@n4.nabble.com> Thanks for responding, Nic. Xiphos displays each language as a branch in the install manager tree, but after first choosing a repository. Yet it does seem rather daunting to be faced with 43 languages that many users will never come across, especially as many of these are near the top of the auto-sorted tree. This is the reason why, IMHO, it would make better sense to devote a separate repository for these WBTI/BL modules. For PS, you could easily call it CrossWire 3, assuming anyone else agrees with me, enough to take up my suggested action. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/WBTI-BL-modules-in-CrossWire-Beta-tp3081010p3083129.html Sent from the SWORD Dev mailing list archive at Nabble.com. From Technical at Tyndale.cam.ac.uk Mon Dec 13 07:50:46 2010 From: Technical at Tyndale.cam.ac.uk (David Instone-Brewer) Date: Mon, 13 Dec 2010 14:50:46 +0000 Subject: [sword-devel] How to log out Strongs modules for development Message-ID: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> Could you help a newbie find out how to help with development? I'd like to do some work on the Strong's Greek & Hebrew lexicons. Where can I download and upload modules, and do I have to log them out in some way? David Instone-Brewer From dfhmch at googlemail.com Mon Dec 13 09:13:29 2010 From: dfhmch at googlemail.com (David Haslam) Date: Mon, 13 Dec 2010 08:13:29 -0800 (PST) Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> Message-ID: <1292256809378-3085641.post@n4.nabble.com> Hi David, This wiki page describes http://crosswire.org/wiki/Module_Repositories module repositories . New/updated modules made by users are not uploaded directly, except by a competent CrossWire volunteer. They must be submitted by email, usually as a validated OSIS file. Refer to http://crosswire.org/wiki/DevTools:Modules http://crosswire.org/wiki/DevTools:Modules To download a module, the simplest way is to install one of the front-end applications, such as http://crosswire.org/wiki/Frontends:Xiphos Xiphos . Then use its Edit menu to access the Module Manager, which allows you to install & maintain modules, etc. The location of installed modules will depend on your OS. For Windows users, mine are [by default] installed in the folder C:\Users\David\AppData\Roaming\Sword where David is my username in Windows 7. If you wish to obtain the OSIS source text for a module, then you'd need to contact the relevant CrossWire volunteer. Do not rely on the Sword utility called mod2osis, as this has many issues. David Haslam -- View this message in context: http://sword-dev.350566.n4.nabble.com/How-to-log-out-Strongs-modules-for-development-tp3085506p3085641.html Sent from the SWORD Dev mailing list archive at Nabble.com. From refdoc at gmx.net Mon Dec 13 15:06:04 2010 From: refdoc at gmx.net (Peter von Kaehne) Date: Mon, 13 Dec 2010 22:06:04 +0000 Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <1292256809378-3085641.post@n4.nabble.com> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> Message-ID: <4D0698CC.3020509@gmx.net> On 13/12/10 16:13, David Haslam wrote: > If you wish to obtain the OSIS source text for a module, then you'd need to > contact the relevant CrossWire volunteer. The Strong modules are created using TEI not OSIS. I am not sure (though Chris Little will know) if this : http://files.morphgnt.org/strongs-dictionary/ and our source is the same, but I would think nevertheless this is a quality source for TEI encoded Strongs. Another, interesting (though I think, quite sleepy) project is here: http://www.textonline.org/wiki/Textonline.org:Current_events Unfortunate the site appears to be in difficulties. The site uses a variant of SFM to encode which should be easily translatable into TEI on completion. Peter From dhowens at pmbx.net Mon Dec 13 15:25:22 2010 From: dhowens at pmbx.net (Daniel Owens) Date: Mon, 13 Dec 2010 16:25:22 -0600 Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <4D0698CC.3020509@gmx.net> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> <4D0698CC.3020509@gmx.net> Message-ID: <4D069D52.6070201@pmbx.net> On 12/13/2010 04:06 PM, Peter von Kaehne wrote: > On 13/12/10 16:13, David Haslam wrote: > >> If you wish to obtain the OSIS source text for a module, then you'd need to >> contact the relevant CrossWire volunteer. > The Strong modules are created using TEI not OSIS. > > I am not sure (though Chris Little will know) if this : > > http://files.morphgnt.org/strongs-dictionary/ > > and our source is the same, but I would think nevertheless this is a > quality source for TEI encoded Strongs. > > Another, interesting (though I think, quite sleepy) project is here: > > http://www.textonline.org/wiki/Textonline.org:Current_events > > Unfortunate the site appears to be in difficulties. The site uses a > variant of SFM to encode which should be easily translatable into TEI on > completion. > > Peter > Sleepy is a great way to describe our project at textonline.org! I get to it after semesters close (which is right now for us in America), and I need to chase down our provider to fix the site's database! Hopefully when my dissertation is done I will make lots of progress. Currently the effort in regard to Greek is essentially dormant. For Hebrew, I am working on checking the glosses that you, David IB, obtained from the OLB lexicon to make sure they conform to BDB and Strongs, thus moving the source way from the OLB source and toward public domain material. I am using WeSay, a program written by SIL to enable collaboration in developing lexicons. The files are in LIFT XML and housed at LanguageDepot.org. If you or someone you know would like to contribute to the ongoing work, register there and let me know so I can get you (or another) set up to contribute. WeSay uses Mercurial for version control, but all the user does is click Send/Receive button in WeSay. It is really user-friendly once it is set up. Once I get the textonline.org site back up and running I will make sure the instructions there are clear. But for Strongs, another source is at OpenScriptures.org. I think they are working on perfecting a Strong's source in OSIS. Daniel From refdoc at gmx.net Mon Dec 13 15:45:49 2010 From: refdoc at gmx.net (Peter von Kaehne) Date: Mon, 13 Dec 2010 22:45:49 +0000 Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <4D069D52.6070201@pmbx.net> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> <4D0698CC.3020509@gmx.net> <4D069D52.6070201@pmbx.net> Message-ID: <4D06A21D.4000603@gmx.net> On 13/12/10 22:25, Daniel Owens wrote: > > But for Strongs, another source is at OpenScriptures.org. I think they > are working on perfecting a Strong's source in OSIS. TEI And the source of that is Ulrik Petersen's version linked to above Peter From davidtroidl at aol.com Mon Dec 13 16:12:05 2010 From: davidtroidl at aol.com (davidtroidl at aol.com) Date: Mon, 13 Dec 2010 18:12:05 -0500 Subject: [sword-devel] How to log out Strongs modules for development Message-ID: <8CD69324AAB4ADF-1D6C-5AEA@webmail-d005.sysops.aol.com> On 12/13/2010 5:45 PM, Peter von Kaehne wrote: On 13/12/10 22:25, Daniel Owens wrote: But for Strongs, another source is at OpenScriptures.org. I think they are working on perfecting a Strong's source in OSIS. TEI And the source of that is Ulrik Petersen's version linked to above The Greek is Ulrik Petersen's version, has its own embedded DTD, and doesn't look very much like TEI or OSIS. The Hebrew is my best attempt to encode the dictionary in OSIS as it currently stands. Peter _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101213/d5c0eb30/attachment.html> From Technical at Tyndale.cam.ac.uk Tue Dec 14 05:01:36 2010 From: Technical at Tyndale.cam.ac.uk (David Instone-Brewer) Date: Tue, 14 Dec 2010 12:01:36 +0000 Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <4D069D52.6070201@pmbx.net> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> <4D0698CC.3020509@gmx.net> <4D069D52.6070201@pmbx.net> Message-ID: <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> Dear Daniel I was hoping to look at the possibility of adding a "Root" field to the Strongs modules, so that people could do a search for similar words. As a starting point I was going to find a programming way of identifying clusters from Strong's own internal links to similar words, and then look through for obvious errors (that's the tricky bit!). It would be nice to make a distinction between "root" and "lemma", but this would take more sophistication. Initially I just need a copy of the project at present (in XML or similar) to see if the plan is feasible. If I get some sensible results, it looks like the best thing to do is to send them to you for incorporation into the official module. Is that right? BTW the Strongs Greek v.1.4 still lists 5054 (teknwn) as derived from 5098. This should be derived from "5088". This is in error in all online versions of Strongs This error led someone to publish a book last year saying that Jesus was actually the son of a judge, and was a respected member of the establishment, because 5098 is timoria from 5097; vindication, i.e. (by implication) a penalty:--punishment. Its frightening what can happen as a result of bad OCR. David IB At 22:25 13/12/2010, Daniel Owens wrote: >On 12/13/2010 04:06 PM, Peter von Kaehne wrote: >>On 13/12/10 16:13, David Haslam wrote: >> >>>If you wish to obtain the OSIS source text for a module, then you'd need to >>>contact the relevant CrossWire volunteer. >>The Strong modules are created using TEI not OSIS. >> >>I am not sure (though Chris Little will know) if this : >> >>http://files.morphgnt.org/strongs-dictionary/ >> >>and our source is the same, but I would think nevertheless this is a >>quality source for TEI encoded Strongs. >> >>Another, interesting (though I think, quite sleepy) project is here: >> >>http://www.textonline.org/wiki/Textonline.org:Current_events >> >>Unfortunate the site appears to be in difficulties. The site uses a >>variant of SFM to encode which should be easily translatable into TEI on >>completion. >> >>Peter >Sleepy is a great way to describe our project at textonline.org! I >get to it after semesters close (which is right now for us in >America), and I need to chase down our provider to fix the site's >database! Hopefully when my dissertation is done I will make lots of progress. > >Currently the effort in regard to Greek is essentially dormant. For >Hebrew, I am working on checking the glosses that you, David IB, >obtained from the OLB lexicon to make sure they conform to BDB and >Strongs, thus moving the source way from the OLB source and toward >public domain material. I am using WeSay, a program written by SIL >to enable collaboration in developing lexicons. The files are in >LIFT XML and housed at LanguageDepot.org. If you or someone you know >would like to contribute to the ongoing work, register there and let >me know so I can get you (or another) set up to contribute. WeSay >uses Mercurial for version control, but all the user does is click >Send/Receive button in WeSay. It is really user-friendly once it is >set up. Once I get the textonline.org site back up and running I >will make sure the instructions there are clear. > >But for Strongs, another source is at OpenScriptures.org. I think >they are working on perfecting a Strong's source in OSIS. > >Daniel > >_______________________________________________ >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101214/022d519a/attachment.html> From dfhmch at googlemail.com Tue Dec 14 05:19:19 2010 From: dfhmch at googlemail.com (David Haslam) Date: Tue, 14 Dec 2010 04:19:19 -0800 (PST) Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> <4D0698CC.3020509@gmx.net> <4D069D52.6070201@pmbx.net> <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> Message-ID: <1292329159500-3086951.post@n4.nabble.com> David, LOL. OCR at its most humorous. Anderson: Acts 16:37. But Paul said to them: Having publicly scourged us uncondemned, us who are Etonians, they threw us into prison: and do they now put us out secretly? No, verily: but let them come and lead us out. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/How-to-log-out-Strongs-modules-for-development-tp3085506p3086951.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Tue Dec 14 05:21:59 2010 From: dfhmch at googlemail.com (David Haslam) Date: Tue, 14 Dec 2010 04:21:59 -0800 (PST) Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> <4D0698CC.3020509@gmx.net> <4D069D52.6070201@pmbx.net> <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> Message-ID: <1292329319907-3086952.post@n4.nabble.com> David, LOL. OCR at its most humorous.... Anderson: Acts 16:37. But Paul said to them: Having publicly scourged us uncondemned, us who are Etonians, they threw us into prison: and do they now put us out secretly? No, verily: but let them come and lead us out. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/How-to-log-out-Strongs-modules-for-development-tp3085506p3086952.html Sent from the SWORD Dev mailing list archive at Nabble.com. From karl at kleinpaste.org Tue Dec 14 05:23:14 2010 From: karl at kleinpaste.org (Karl Kleinpaste) Date: Tue, 14 Dec 2010 07:23:14 -0500 Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> (David Instone-Brewer's message of "Tue, 14 Dec 2010 12:01:36 +0000") References: <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> Message-ID: <vxk7hfc35n1.fsf@awol.kleinpaste.org> David Instone-Brewer <Technical at Tyndale.cam.ac.uk> writes: > BTW the Strongs Greek v.1.4 still lists 5054 (teknwn) as derived from > 5098. This should be derived from "5088". This is in error in all > online versions of Strongs The point is valid but the bogus xref is in 5043, not (double typo) 5054. From bdrake at crosswire.org Tue Dec 14 05:25:53 2010 From: bdrake at crosswire.org (Barry Drake) Date: Tue, 14 Dec 2010 12:25:53 +0000 Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> <4D0698CC.3020509@gmx.net> <4D069D52.6070201@pmbx.net> <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> Message-ID: <1292329553.2048.5.camel@pcspecialist> On Tue, 2010-12-14 at 12:01 +0000, David Instone-Brewer wrote: > I was hoping to look at the possibility of adding a "Root" field to > the Strongs modules, so that people could do a search for similar > words. > As a starting point I was going to find a programming way of > identifying clusters from Strong's own internal links to similar words This takes me back to a strong (no pun intended) note of caution given by a lecturer at Cambridge. He is a Hebrew expert, and warned us to be VERY cautious with research based on 'roots'. He gave a couple of English examples, and pointed out the words 'ladybird', (Americans more sensibly call it a 'ladybug' which works properly), but 'ladybird' .... ? His other example was 'butterfly'. He assured us that Hebrew has at least as many such anomalies. God bless, Barry Drake -- What do you see when you use your Computer? Same old thing? ...There IS a Better Way! Ubuntu! From DavidTroidl at aol.com Tue Dec 14 06:33:48 2010 From: DavidTroidl at aol.com (David Troidl) Date: Tue, 14 Dec 2010 08:33:48 -0500 Subject: [sword-devel] How to log out Strongs modules for development In-Reply-To: <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> References: <E1PS9ki-0005l7-SD@ppsw-41.csi.cam.ac.uk> <1292256809378-3085641.post@n4.nabble.com> <4D0698CC.3020509@gmx.net> <4D069D52.6070201@pmbx.net> <E1PSTZo-0004D2-WM@ppsw-51.csi.cam.ac.uk> Message-ID: <4D07723C.9020306@aol.com> David, On 12/14/2010 7:01 AM, David Instone-Brewer wrote: > Dear Daniel > > I was hoping to look at the possibility of adding a "Root" field to > the Strongs modules, so that people could do a search for similar words. > As a starting point I was going to find a programming way of > identifying clusters from Strong's own internal links to similar words, > and then look through for obvious errors (that's the tricky bit!). > It would be nice to make a distinction between "root" and "lemma", but > this would take more sophistication. The root field would be a wonderful idea. Darrell Smith and I had done some work on Hebrew roots a while back. He may have more to say on this point. On OpenScriptures, we also have my BDB Outline, which gives a rough approximation of derivation (https://github.com/openscriptures/HebrewLexicon). The project is in a state of flux right now, but the current version is at least consistent. On the Greek side, I have a Greek lexicon, that I use for recording my translation choices. It also contains a derivative field, that may be of use. I could probably extract that, if it would help. Peace, David > > Initially I just need a copy of the project at present (in XML or > similar) to see if the plan is feasible. > If I get some sensible results, it looks like the best thing to do is > to send them to you for incorporation into the official module. > Is that right? > > BTW the Strongs Greek v.1.4 still lists 5054 (teknwn) as derived from > 5098. > This should be derived from "5088". This is in error in all online > versions of Strongs > This error led someone to publish a book last year saying that Jesus > was actually the son of a judge, and was a respected member of the > establishment, because 5098 is /_timoria_/ from 5097; vindication, > i.e. (by implication) a penalty:--punishment. > Its frightening what can happen as a result of bad OCR. > > David IB > > At 22:25 13/12/2010, Daniel Owens wrote: >> On 12/13/2010 04:06 PM, Peter von Kaehne wrote: >>> On 13/12/10 16:13, David Haslam wrote: >>> >>>> If you wish to obtain the OSIS source text for a module, then you'd >>>> need to >>>> contact the relevant CrossWire volunteer. >>> The Strong modules are created using TEI not OSIS. >>> >>> I am not sure (though Chris Little will know) if this : >>> >>> http://files.morphgnt.org/strongs-dictionary/ >>> >>> and our source is the same, but I would think nevertheless this is a >>> quality source for TEI encoded Strongs. >>> >>> Another, interesting (though I think, quite sleepy) project is here: >>> >>> http://www.textonline.org/wiki/Textonline.org:Current_events >>> >>> Unfortunate the site appears to be in difficulties. The site uses a >>> variant of SFM to encode which should be easily translatable into TEI on >>> completion. >>> >>> Peter >> Sleepy is a great way to describe our project at textonline.org! I >> get to it after semesters close (which is right now for us in >> America), and I need to chase down our provider to fix the site's >> database! Hopefully when my dissertation is done I will make lots of >> progress. >> >> Currently the effort in regard to Greek is essentially dormant. For >> Hebrew, I am working on checking the glosses that you, David IB, >> obtained from the OLB lexicon to make sure they conform to BDB and >> Strongs, thus moving the source way from the OLB source and toward >> public domain material. I am using WeSay, a program written by SIL to >> enable collaboration in developing lexicons. The files are in LIFT >> XML and housed at LanguageDepot.org. If you or someone you know would >> like to contribute to the ongoing work, register there and let me >> know so I can get you (or another) set up to contribute. WeSay uses >> Mercurial for version control, but all the user does is click >> Send/Receive button in WeSay. It is really user-friendly once it is >> set up. Once I get the textonline.org site back up and running I will >> make sure the instructions there are clear. >> >> But for Strongs, another source is at OpenScriptures.org. I think >> they are working on perfecting a Strong's source in OSIS. >> >> Daniel >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101214/512faa3f/attachment.html> From teusjannette at gmail.com Tue Dec 14 09:17:19 2010 From: teusjannette at gmail.com (Teus Benschop) Date: Tue, 14 Dec 2010 17:17:19 +0100 Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 Message-ID: <1292343439.25652.16.camel@2530p> Hi, The Dutch Annotations upon the Whole Bible 1657 has been completed as of today. In the previous release about 10 books were missing. Today's release is complete. It is at http://sites.google.com/site/dutchannotations1657/. Released under the GFDL, it is for everybody to use. Teus Benschop From dfhmch at googlemail.com Tue Dec 14 09:47:26 2010 From: dfhmch at googlemail.com (David Haslam) Date: Tue, 14 Dec 2010 08:47:26 -0800 (PST) Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 In-Reply-To: <1292343439.25652.16.camel@2530p> References: <1292343439.25652.16.camel@2530p> Message-ID: <1292345246907-3087492.post@n4.nabble.com> Teus, Being the English translation of The Dutch Annotations upon the Whole Bible 1657. Not everyone reading your message would immediately realize that the text is English rather than Dutch. For further background, see http://en.wikipedia.org/wiki/Theodore_Haak Theodore Haak , who was the translator of the Annotations, which work was ordered by the Synod of Dort 1618. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/The-Dutch-Annotations-upon-the-Whole-Bible-1657-tp3087410p3087492.html Sent from the SWORD Dev mailing list archive at Nabble.com. From bdumont at ameritech.net Tue Dec 14 10:14:38 2010 From: bdumont at ameritech.net (Brian J. Dumont) Date: Tue, 14 Dec 2010 12:14:38 -0500 Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 In-Reply-To: <1292343439.25652.16.camel@2530p> References: <1292343439.25652.16.camel@2530p> Message-ID: <4D07A5FE.6060009@ameritech.net> On 12/14/2010 11:17 AM, Teus Benschop wrote: > Hi, > > The Dutch Annotations upon the Whole Bible 1657 has been completed as of > today. In the previous release about 10 books were missing. Today's > release is complete. It is at > http://sites.google.com/site/dutchannotations1657/. Released under the > GFDL, it is for everybody to use. > > Teus Benschop > Are there plans to convert these to a SWORD module? Thanks, Brian From teusjannette at gmail.com Tue Dec 14 10:37:58 2010 From: teusjannette at gmail.com (Teus Benschop) Date: Tue, 14 Dec 2010 18:37:58 +0100 Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 In-Reply-To: <4D07A5FE.6060009@ameritech.net> References: <1292343439.25652.16.camel@2530p> <4D07A5FE.6060009@ameritech.net> Message-ID: <1292348278.25652.23.camel@2530p> Thanks for clarifying that the language is English rather than Dutch. A SWORD module has been created and is now being uploaded to http://sites.google.com/site/dutchannotations1657/ . But I would prefer an official module, hosted by the SWORD repositories,. Teus From dfhmch at googlemail.com Thu Dec 16 08:03:27 2010 From: dfhmch at googlemail.com (David Haslam) Date: Thu, 16 Dec 2010 07:03:27 -0800 (PST) Subject: [sword-devel] Parsing Devanagari digits in Cross References Message-ID: <1292511807615-3091020.post@n4.nabble.com> One of my contacts mentioned something in an email today. "I used the USFM to OSIS python program from Snowfall with quite a bit of changes to make it work with http://en.wikipedia.org/wiki/Devanagari Devanagari numbers in the crossreference processor. So now I can take both of the Nepali Bibles from USFM to OSIS and then to a Sword module in one step. I wish my additional code was in good enough shape to share but I?m mostly a hacker." I report this just in case the maintainers of usfm2osis.pl might wish to address this and similar situations. btw. Has anyone in CrossWire used the Snowfall Software http://www.virtualstorehouse.org/index.php/scripture-preservation-tool.html Scripture Preservation Tool recently? David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Parsing-Devanagari-digits-in-Cross-References-tp3091020p3091020.html Sent from the SWORD Dev mailing list archive at Nabble.com. From greg.hellings at gmail.com Thu Dec 16 08:07:41 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Thu, 16 Dec 2010 09:07:41 -0600 Subject: [sword-devel] Parsing Devanagari digits in Cross References In-Reply-To: <1292511807615-3091020.post@n4.nabble.com> References: <1292511807615-3091020.post@n4.nabble.com> Message-ID: <AANLkTim7L6_kYy_iHCrjPXXzZrNmvzuJRuHGH9PgF=yR@mail.gmail.com> On Thu, Dec 16, 2010 at 9:03 AM, David Haslam <dfhmch at googlemail.com> wrote: > > One of my contacts mentioned something in an email today. > > "I used the USFM to OSIS python program from Snowfall with quite a bit of > changes to make it work with ?http://en.wikipedia.org/wiki/Devanagari > Devanagari ?numbers in the crossreference processor. > So now I can take both of the Nepali Bibles from USFM to OSIS and then to a > Sword module in one step. > I wish my additional code was in good enough shape to share but I?m mostly a > hacker." > > I report this just in case the maintainers of usfm2osis.pl might wish to > address this and similar situations. Peter created a parallel script called xreffix.pl which sits alongside usfm2osis.pl and is intended to be run on the output of usfm2osis.pl. Using it requires the SWORD Perl bindings be installed and a locale that understands the source language. It should understand anything that SWORD and the locale understand - if that includes Devanagari digits. --Greg From dfhmch at googlemail.com Thu Dec 16 08:09:28 2010 From: dfhmch at googlemail.com (David Haslam) Date: Thu, 16 Dec 2010 07:09:28 -0800 (PST) Subject: [sword-devel] UBS Publishing Assistant Message-ID: <1292512168650-3091035.post@n4.nabble.com> Shared knowledge, FIO. UBS (United Bible Society) has some proprietary software called http://confluence.ubs-icap.org/display/PUBASSIST/Home Publishing Assistant that takes the USFM from Paratext and puts it in a format that interfaces with http://en.wikipedia.org/wiki/Adobe_InDesign InDesign . If they set all the parameters well, then there is only tweeking to make the columns line up nicely etc but, still a lot of work. In the end they get a very nice looking Bible. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/UBS-Publishing-Assistant-tp3091035p3091035.html Sent from the SWORD Dev mailing list archive at Nabble.com. From hunt.robertj at gmail.com Thu Dec 16 13:26:44 2010 From: hunt.robertj at gmail.com (Robert Hunt) Date: Fri, 17 Dec 2010 09:26:44 +1300 Subject: [sword-devel] Parsing Devanagari digits in Cross References In-Reply-To: <1292511807615-3091020.post@n4.nabble.com> References: <1292511807615-3091020.post@n4.nabble.com> Message-ID: <4D0A7604.8050209@gmail.com> I tried running it a few months back, but discovered that the downloadable version (labelled V3.0.9 but SFMToOSIS.py was 2.0.7 inside) had a number of bugs that made it inoperable. I fixed some of the worst ones, and submitted my fixes back to Snowfall but I'm not sure if they updated their downloadable version (in fact I can't even see a file to download on that page now). Robert. On 17/12/10 04:03, David Haslam wrote: > btw. Has anyone in CrossWire used the Snowfall Software > http://www.virtualstorehouse.org/index.php/scripture-preservation-tool.html > Scripture Preservation Tool recently? > > David > > From p1234567891 at gmail.com Fri Dec 17 19:34:30 2010 From: p1234567891 at gmail.com (=)) Date: Sat, 18 Dec 2010 10:34:30 +0800 Subject: [sword-devel] Bug Reports and Suggestions Message-ID: <AANLkTi=ynNDtJjvc98HWd8Mk2c6CC8HSe9-NvRd7J-=L@mail.gmail.com> Hello! I just put up a few bug reports and suggestions onto the Bug Reporter: Malachi chapter 4 is somehow inaccessible in Passage Study, although it is in Parallel Study <http://www.crosswire.org/bugs/browse/SWEB-11> (http://www.crosswire.org/bugs/browse/SWEB-11) Clicking on a word sometimes results in other extra words being highlighted<http://www.crosswire.org/bugs/browse/SWEB-12> (http://www.crosswire.org/bugs/browse/SWEB-12) Can the interface be changed such that navigating the website is handled through absolute links? <http://www.crosswire.org/bugs/browse/SWEB-13> (http://www.crosswire.org/bugs/browse/SWEB-13) Minor typographical error and incorrect text source<http://www.crosswire.org/bugs/browse/MOD-152> (http://www.crosswire.org/bugs/browse/MOD-152) Hope someone can help. =) David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101218/842c25d4/attachment.html> From dfhmch at googlemail.com Sun Dec 19 01:38:15 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sun, 19 Dec 2010 00:38:15 -0800 (PST) Subject: [sword-devel] Localized language names - a suggestion Message-ID: <1292747895278-3094297.post@n4.nabble.com> Referring to http://www.crosswire.org/wiki/DevTools:confFiles the only language related element is lang itself. This means that when a front-end encounters a new module for which it cannot yet provide a look-up for the localized language name, it will show Unknown as the name of the language. That's what Xiphos does, for example. As a fall-back position, might it be sensible to allow the conf file to optionally include the localized language name in addition to the lang element? This would be processed as follows: If the lang identifier can be looked up, use the look-up value. If not, then if the conf file includes the localized language name, use that. Then if not either, fall back to using unknown, as at present. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Localized-language-names-a-suggestion-tp3094297p3094297.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Mon Dec 20 01:53:43 2010 From: dfhmch at googlemail.com (David Haslam) Date: Mon, 20 Dec 2010 00:53:43 -0800 (PST) Subject: [sword-devel] Midverse section titles in USFM Message-ID: <1292835223779-3095211.post@n4.nabble.com> How does usfm2mod.pl handle the occurrence of a section title part way through a verse? Example:\v 16 ??????????? ?????????? ?????????? ??????????. \s ???? ??? ?????? ?????????? ???????. \v 17 ???????? ?????? ??????? ????????? ????? ?????????? ???????????? ????????? ?????????????? ??????????????????: ????????????? The line with no tag is the continuation of verse 16. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Midverse-section-titles-in-USFM-tp3095211p3095211.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Mon Dec 20 06:53:28 2010 From: dfhmch at googlemail.com (David Haslam) Date: Mon, 20 Dec 2010 05:53:28 -0800 (PST) Subject: [sword-devel] Midverse section titles in USFM In-Reply-To: <1292835223779-3095211.post@n4.nabble.com> References: <1292835223779-3095211.post@n4.nabble.com> Message-ID: <1292853208467-3095522.post@n4.nabble.com> Correction to my original message: I meant to type usfm2osis.pl rather than usfm2mod.pl Apologies for any confusion. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Midverse-section-titles-in-USFM-tp3095211p3095522.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Tue Dec 21 05:20:02 2010 From: dfhmch at googlemail.com (David Haslam) Date: Tue, 21 Dec 2010 04:20:02 -0800 (PST) Subject: [sword-devel] Midverse section titles in USFM In-Reply-To: <1292835223779-3095211.post@n4.nabble.com> References: <1292835223779-3095211.post@n4.nabble.com> Message-ID: <1292934002595-3147615.post@n4.nabble.com> One of my contacts has described what usfm2osis.pl does with such an example. He wrote: I slid your text into one of my sfm files for Matthew.<verse eID="Matt.1.15"/> <verse sID="Matt.1.16" osisID="Matt.1.16"/> ??????????? ?????????? ?????????? ??????????. </p> </div> <div type="section"> <title>???? ??? ?????? ?????????? ???????. ???????? ?????? ??????? ????????? ????? ?????????? ???????????? ????????? ?????????????? ??????????????????: ????????????? It looks good to me with the midverse section title but, I?m not sure what osis2mod would do with this. So that's the next question for this thread. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Midverse-section-titles-in-USFM-tp3095211p3147615.html Sent from the SWORD Dev mailing list archive at Nabble.com. From vtamara at servidor.justapaz.org Fri Dec 24 02:48:55 2010 From: vtamara at servidor.justapaz.org (vtamara) Date: Fri, 24 Dec 2010 04:48:55 -0500 Subject: [sword-devel] 10 problems and solutions in KJV Message-ID: <20101224094855.GA17510@servidor.justapaz.org> Good morning in the Lord. I couldn't send this from vtamara at pasosdeJesus.org, however ... 1) In Acts 20:7 it says And upon but it should be And upon Since the conjuction "de" (strong G1161) is AND, and the preposition "en" (strong G1722) can be translated as IN, BY, WITH, ON, etc. Such concordance is also used in BLB: http://www.blueletterbible.org/Bible.cfm?b=Act&c=20&v=7&t=KJV#conc/7 2) In Acts 20:32 there is a final commentary "NOTE! Tags have for some reason, become scrambled" which is correct since it says: And now , brethren , I commend you to God , and to the word of his grace , which is able to build you up , and to give you an inheritance among all them which are sanctified. in fact the tags are scrambled, comparing the greek words and strong numbers with http://www.blueletterbible.org/Bible.cfm?b=Act&c=20&v=32&t=KJV#conc/32 they are practically the same, except: * in BLB there are only 24 words (not 25, KJV would repeat 3956,A-DPM,24 and 3956,A-DPM,25) * BLB says 3569,ADV-C,2 but KJV2003 says 3568,ADV-C,2 The first is TANUN the second is NUN (both are the adverb now). According to http://biblos.com/acts/20.htm --entitled Greek NT: Stephanus Textus Receptus (1550, with accents)-- it should be "TANUN" Then with that reference and my tiny experience in greek: And now, brethren, I commend , you to God, and , to the word of his grace, which is able to build you up, and , to give you an inheritance among all them which are sanctified 3) The beginning of Acts 20:37 says And they all wept sore however according to http://www.blueletterbible.org/Bible.cfm?b=Act&c=20&v=37&t=KJV#conc/37 strong 2805 is the noun 'klauthmos' that can be translated as weeping, lamentation according to Thayer-BLB strong 2425 is the adjective 'hikanos' that can be translated as many enough, sufficient then it would concordate better with 'sore' than with 'they'. strong 1096 is the verb 'ginomai' that means 'become' Then in my humble opinion, a better markup would be: And they all wept sore , 4) Acts 21:4 Says NOTE! Another scrambled verse! it includes: disciples , we tarried there seven days : who said to Paul through the Spirit , that he should not go up to Jerusalem . however strong 3748 (is the relative pronoun hostis that is translated as who) is not marking anything in KJV2003 strong 1223 (is the preposition dia that is translated as trhough) is not markin anything in KJV2003 strong 2419 (is the noun Ierousalem) is not marking anything in KJV2003 The other words are strong 3101 is mathetes that means pupils strong 1961 is the verb epimeno that means to stay i.e we tarried strong 2250 is the noun hemera that menas day strong 847 is the adverb autou that means there strong 2033 is the adjective hepta that menas seven strong 3972 is the noun Paulos strong 3004 is the verb to say strong 3972 is Paulos strong 1123 is dia translated as through strong 4141 is penuma translated as Spirit strong 305 is the verb anabaino translated as that he should ... go up strong 3361 is the negativ me that is translated as no strong 1519 is the preposition eis transalted as to then IMHO it should be: disciples, we tarried there seven days : who said to Paul through the Spirit , that he should not go up to . Jerusalem 5) Acts 21:26 says: an offering should be offered However according to http://www.blueletterbible.org/Bible.cfm?b=Act&c=21&v=26&t=KJV#26 it should be: an offering should be offered 6) Acts 25:5 is marked: and accuse this man However the pronoun 846 (he, him) cannot be translated as 'accuse', neither the verb 2723 (accuse) as 'this', the noun 435 (man) is not used and the pronoun 5129 (to this one) is used as 'man'. IMHO a better concordance (similar to www.blb.org as well as the translations of each strong number given before) is: and accuse this man 7) Acts 27:3 at end is repeating strong 5177: to refresh himself. However in http://www.blueletterbible.org/Bible.cfm?b=Act&c=27&v=3&t=KJV#conc/3 such verb appears only once. 8) Acts 27:8 has 18 words and it doesn't have grammar information for the 10th and 12th word: ... The fair havens However in: http://www.blueletterbible.org/Bible.cfm?b=Act&c=27&v=8&t=KJV#conc/8http://www.blueletterbible.org/Bible.cfm?b=Act&c=27&v=8&t=KJV#conc/8 I see 16 words. As I understand strong 3040 is "havens", strong 2570 is "fair" however since those two words are the name of a bay in Crete (according to http://www.blueletterbible.org/lang/lexicon/lexicon.cfm?Strongs=G2568&t=KJV ) there is also a strong number 2568 for such proper noun "Fair Havens". I don't know if there exists markup for such case. If not, in my humble opinion it would be better to leave only 16 words (instead of 18), renumbering, and changing the note: The fair havens nigh whereunto was the city of Lasea. NOTE! The words : "kalos" and "limen" are also a proper noun with strong number 2568, it is a bay of Crete. 9) Acts 27:18 includes: they lightened the ship; However according to http://www.blueletterbible.org/lang/lexicon/lexicon.cfm?Strongs=G4160&t=KJV the verb 4160 is 'to make' and according to http://www.blueletterbible.org/lang/lexicon/lexicon.cfm?Strongs=G1546&t=KJV the nonun 1546 doesn't mean ship but `the throwing overboard of goods and lading whereby sailors lighten a ship in a storm to keep her from sinking' in my humble opinion it would be better: they lightened the ship 10) Acts 27:37 doesn't have morphology in the word threescore and However in Acts 7:14 we find the same noun with morphology A-NUI, then I would suggest: threescore and -- Dios, gracias por tu amor infinito. http://www.primarilypublicdomain.org/letter/ -- Vladimir T?mara Pati?o. http://vtamara.pasosdeJesus.org/ From dfhmch at googlemail.com Sun Dec 26 09:14:58 2010 From: dfhmch at googlemail.com (David Haslam) Date: Sun, 26 Dec 2010 08:14:58 -0800 (PST) Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 In-Reply-To: <1292348278.25652.23.camel@2530p> References: <1292343439.25652.16.camel@2530p> <4D07A5FE.6060009@ameritech.net> <1292348278.25652.23.camel@2530p> Message-ID: <1293380098461-3164307.post@n4.nabble.com> Teus would like CrossWire to maintain & host this module in one of our repos. Please would someone volunteer. The source text is http://sites.google.com/site/dutchannotations1657/ available as USFM and in OSIS format. Reminder: Although the module is called DutchAnnotations, it is in fact the English translation. David Haslam -- View this message in context: http://sword-dev.350566.n4.nabble.com/The-Dutch-Annotations-upon-the-Whole-Bible-1657-tp3087410p3164307.html Sent from the SWORD Dev mailing list archive at Nabble.com. From jonmmorgan at gmail.com Sun Dec 26 22:22:06 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Mon, 27 Dec 2010 16:22:06 +1100 Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 In-Reply-To: <1292348278.25652.23.camel@2530p> References: <1292343439.25652.16.camel@2530p> <4D07A5FE.6060009@ameritech.net> <1292348278.25652.23.camel@2530p> Message-ID: Hi Teus, After some prompting, I had a look at the SWORD module. A few comments: 1. I was expecting this to be a commentary rather than a Bible (though this might be a gray area, as it seems to have the complete Biblical text with annotations). A similar one is the Geneva Bible Translation Notes, which includes the Biblical text as well as the notes, but is packaged as a commentary. 2. If it were to be a Bible, I would expect the annotations to be hidden away in translation notes. 3. Making the section headings pre-verse headings (e.g. Genesis 1:0) would probably be a good thing, as they really come before the chapter rather than being dropped into verse 1. 4. Having scripture references linked would be good too, though I realise this isn't straightforward as they are just loose in the text. 5. Almost all the verses seem to start with a ".". Is this what is expected? [I do see it in the original text, but that is a display style, with verses shown as "22.". This display style isn't going to carry over nicely when verse numbers are formatted differently, or even not shown at all]. 6. Quite a few letters seem to be doubled in Matthew where they shouldn't be (e.g. thhe, bringgg, anotherr). This seems to be in the USFM source, and seems to apply to John as well, but not to Mark and only occasionally to Luke (I haven't checked any of the others). 7. Spacing around punctuation seems sometimes to be suspect (e.g. in John 11:50, "Christs death ,for thhe reconciliation" rather than "Christ's death, for the reconciliation" - here the spacing around the punctuation differs from the original, but the original does not have an apostrophe: I would still say it would be better with an apostrophe for use now, but it may not be considered accurate to the original text). Not wishing to find fault with what must have been a large job, just to note problems as I see them so it can be improved. Jon On Wed, Dec 15, 2010 at 4:37 AM, Teus Benschop wrote: > Thanks for clarifying that the language is English rather than Dutch. > > A SWORD module has been created and is now being uploaded to > http://sites.google.com/site/dutchannotations1657/ . > > But I would prefer an official module, hosted by the SWORD > repositories,. > > Teus > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfhmch at googlemail.com Mon Dec 27 03:00:10 2010 From: dfhmch at googlemail.com (David Haslam) Date: Mon, 27 Dec 2010 02:00:10 -0800 (PST) Subject: [sword-devel] Ndebele and Shona Bibles online In-Reply-To: <1257243153.2824.12.camel@2530p> References: <1257243153.2824.12.camel@2530p> Message-ID: <1293444010390-3164845.post@n4.nabble.com> The source text for the Ndebele translation has been updated on 2010-12-17. Download from http://sites.google.com/site/bibletranslationdata/ndebele-bible http://sites.google.com/site/bibletranslationdata/ndebele-bible Please would someone volunteer to rebuild the Ndebele SWORD module. I just rebuilt the Ndebele Go Bible apps using the latest USFM files. These can be downloaded from the following shared folder in my box.net account http://www.box.net/shared/ta29dr148f http://www.box.net/shared/ta29dr148f Thank you. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Ndebele-and-Shona-Bibles-online-tp360973p3164845.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Mon Dec 27 03:42:00 2010 From: dfhmch at googlemail.com (David Haslam) Date: Mon, 27 Dec 2010 02:42:00 -0800 (PST) Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 In-Reply-To: References: <1292343439.25652.16.camel@2530p> <4D07A5FE.6060009@ameritech.net> <1292348278.25652.23.camel@2530p> Message-ID: <1293446520671-3164864.post@n4.nabble.com> I just used the GoBibleCreatorUSFMPreprocessor utility on the USFM files. Under "Scan for tags that will not be processed by GBC" (GoBibleCreator), it detected\mte 17 occurrences \imt 1 occurrence \ip 1 occurrenceThese may require attention. The last figure may be incorrect, as 9 books were listed for this tag. Could be a bug in Dirk's code. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/The-Dutch-Annotations-upon-the-Whole-Bible-1657-tp3087410p3164864.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Mon Dec 27 13:44:05 2010 From: dfhmch at googlemail.com (David Haslam) Date: Mon, 27 Dec 2010 12:44:05 -0800 (PST) Subject: [sword-devel] Ndebele and Shona Bibles online In-Reply-To: <1293444010390-3164845.post@n4.nabble.com> References: <1257243153.2824.12.camel@2530p> <1293444010390-3164845.post@n4.nabble.com> Message-ID: <1293482645674-3165443.post@n4.nabble.com> If someone does volunteer, please would they contact me before starting work on the Ndebele module. Some further issues were encountered today, and I'm in email contact with Teus about these. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Ndebele-and-Shona-Bibles-online-tp360973p3165443.html Sent from the SWORD Dev mailing list archive at Nabble.com. From teusjannette at gmail.com Tue Dec 28 04:23:44 2010 From: teusjannette at gmail.com (Teus Benschop) Date: Tue, 28 Dec 2010 12:23:44 +0100 Subject: [sword-devel] The Dutch Annotations upon the Whole Bible 1657 In-Reply-To: References: <1292343439.25652.16.camel@2530p> <4D07A5FE.6060009@ameritech.net> <1292348278.25652.23.camel@2530p> Message-ID: <1293535424.6526.22.camel@2530p> Hi Jonathan, On Mon, 2010-12-27 at 16:22 +1100, Jonathan Morgan wrote: > Hi Teus, > > After some prompting, I had a look at the SWORD module. A few > comments: > 1. I was expecting this to be a commentary rather than a Bible (though > this might be a gray area, as it seems to have the complete Biblical > text with annotations). A similar one is the Geneva Bible Translation > Notes, which includes the Biblical text as well as the notes, but is > packaged as a commentary. Thinking about this, you are correct. It is a commentary, rather than a Bible. The SWORD module was created through Bibledit-Gtk. It only knows about creating SWORD Bibles, not commentaries. If the official module is going to be a Commentary, I'd be happy. > > 2. If it were to be a Bible, I would expect the annotations to be > hidden away in translation notes. Yes, that is what one would expect. Clearly, another sign that this is a commentary. The original book reads like a commentary too, because the notes are scattered throughout the text, not in footnotes. > > 3. Making the section headings pre-verse headings (e.g. Genesis 1:0) > would probably be a good thing, as they really come before the chapter > rather than being dropped into verse 1. Yes, your are right. Bibledit-Gtk does not know about such things, that is why these were put into verse 1. Hope that the official module places the various bits in the correct places. > > 4. Having scripture references linked would be good too, though I > realise this isn't straightforward as they are just loose in the text. Indeed, that would be so helpful. > 5. Almost all the verses seem to start with a ".". Is this what is > expected? [I do see it in the original text, but that is a display > style, with verses shown as "22.". This display style isn't going to > carry over nicely when verse numbers are formatted differently, or > even not shown at all]. The dots came in because the typists put a dot after each verse, like in the original. When converting to USFM, a space got inserted. But really, there is no need for a dot to be there. It might as well go out. > > 6. Quite a few letters seem to be doubled in Matthew where they > shouldn't be (e.g. thhe, bringgg, anotherr). This seems to be in the > USFM source, and seems to apply to John as well, but not to Mark and > only occasionally to Luke (I haven't checked any of the others). There were several typists involved who typed it all. Some were more accurate than the others. This is the reason that there are some spelling mistakes here and there. One laptop had bouncing keys, I remember. This could have been a cause of the doubled letters. Clearly, though the text is good as it is, it can do with some improvements. > > 7. Spacing around punctuation seems sometimes to be suspect (e.g. in > John 11:50, "Christs death ,for thhe reconciliation" rather than > "Christ's death, for the reconciliation" - here the spacing around the > punctuation differs from the original, but the original does not have > an apostrophe: I would still say it would be better with an apostrophe > for use now, but it may not be considered accurate to the original > text). Yes, there are those spelling errors left in the text. As for the apostrophe, yes, I would agree that updating the text would be helpful, so that it follows modern conventions. > > Not wishing to find fault with what must have been a large job, just > to note problems as I see them so it can be improved. Thanks for looking at this. The idea of entering this Commentary into the computer was so that it could be used during our revision of some Bibles in Bantu languages. For that reason I focused on speed of entry, rather than on accuracy. We wanted to have something that would assist us, even if it contained some errors. We have reached our goal: The commentary has been typed, and we can display it in Xiphos or other front-ends, and we can use it during the translation work. I therefore consider this project to have been completed. The text has been released under a free license, not only to allow various packages to display it, but also so that others can pick up the work where we left it. I'd encourage people to clone the text, host it somewhere else as well, improve it, spread it, and so on. If crosswire would like to host it, and make it one of their projects, I'd be glad. Teus From kalemas at mail.ru Tue Dec 28 05:22:52 2010 From: kalemas at mail.ru (Kostya Maslyuk) Date: Tue, 28 Dec 2010 15:22:52 +0300 Subject: [sword-devel] cmake -DSWORD_BINDINGS="" Message-ID: Generating without bindings flatapi.cpp still included. a bug? bindings/sources.cmake:170 SET(sword_base_SOURCES ${sword_base_frontend_SOURCES} ${sword_base_keys_SOURCES} ${sword_base_mgr_SOURCES} ${sword_base_module_SOURCES} ${sword_base_utilfns_SOURCES} ${sword_base_binding_SOURCES} ) From scribe at crosswire.org Tue Dec 28 17:24:50 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Tue, 28 Dec 2010 17:24:50 -0700 Subject: [sword-devel] Remote Repositories Message-ID: <4D1A7FD2.3080105@crosswire.org> I have 2 things I'd like for us to discuss and finalize fairly quickly if that's at all possible ;) 1) As we discussed in the past, I think we all agreed it would be useful to add an official .conf entry for navigating to the purchase URL for a locked module. Currently the user has to scan the About section to find this. If we added: UnlockURL= would it be feasible we could have fairly rapid support for spawning an HTML viewer to this URL from our major frontends? 2) Current Events: I'd like to have a: NEWS.txt or some such file recognized at the root of our remote module repositories which allow publishers to let interested users know what's going on at their institution. I envision a simple memo control showing the contents of this file in our applications' installer view when showing a repository's resources. I can add a method to InstallMgr's InstallSource class: SWBuf getNews(), or something similar. I have ideas about how publishers could support multiple languages: NEWS.txt NEWS.txt.de NEWS.txt.es with proper defaults and such, but does this concept sound like something we'd all be willing to implement, and in what timeframe? Hope everyone has had a very wonderful Christmas filled with family, friends, and love. Troy From jonmmorgan at gmail.com Tue Dec 28 21:57:43 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Wed, 29 Dec 2010 15:57:43 +1100 Subject: [sword-devel] Remote Repositories In-Reply-To: <4D1A7FD2.3080105@crosswire.org> References: <4D1A7FD2.3080105@crosswire.org> Message-ID: Hi Troy, On Wed, Dec 29, 2010 at 11:24 AM, Troy A. Griffitts wrote: > I have 2 things I'd like for us to discuss and finalize fairly quickly > if that's at all possible ;) > > 1) As we discussed in the past, I think we all agreed it would be useful > to add an official .conf entry for navigating to the purchase URL for a > locked module. Currently the user has to scan the About section to find > this. If we added: > > UnlockURL= > > would it be feasible we could have fairly rapid support for spawning an > HTML viewer to this URL from our major frontends? > This makes sense. If it were standardised we might put it in for BPBible 0.5, but I wouldn't guarantee it at this stage. Is this something that could get out of date? A publisher changes their URL schema and suddenly that link no longer works? 2) Current Events: I'd like to have a: > > NEWS.txt > > or some such file recognized at the root of our remote module > repositories which allow publishers to let interested users know what's > going on at their institution. I envision a simple memo control showing > the contents of this file in our applications' installer view when > showing a repository's resources. > > I can add a method to InstallMgr's InstallSource class: SWBuf getNews(), > or something similar. > > > I have ideas about how publishers could support multiple languages: > > NEWS.txt > NEWS.txt.de > NEWS.txt.es > > with proper defaults and such, but does this concept sound like > something we'd all be willing to implement, and in what timeframe? > Several thoughts on this: 1. Is this the most appropriate place to display it? 2. Will it be kept up to date? (I get frustrated by websites, etc. that have news older than a year or two old, and are either no longer doing anything or have given up telling me new things). 3. Is it duplicating information shown elsewhere? Does it mean just another thing for publishers to remember to keep up to date? 4. What degree of formatting will be needed/wanted in this news? I would be inclined to suggest the following instead: 1. Module repositories have some kind of a description or about section. This states the purpose of repository, etc., and is hopefully much less likely to change or be out of date. 2. Module repositories can have a URL to the main site for that module repository. This could be the main page of the publisher or a special page for the SWORD repository or whatever else the publisher chooses. If they want to have news I would probably expect it more to be on a feed on a webpage somewhere than in InstallMgr. This also means those who come across it who are not using SWORD get the same information, and there are no compromises to force-fit the news to what frontends will support. You could support something like this with a fairly standard conf file at the base of the repository. Maybe other fields could be included as well (such as a display name for the repository), but it seems to me a bit arbitrary to have news and nothing else, and I'm not sure that I follow the reasoning. Thoughts? Jon > Hope everyone has had a very wonderful Christmas filled with family, > friends, and love. > > > Troy > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scribe at crosswire.org Tue Dec 28 22:25:00 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Tue, 28 Dec 2010 22:25:00 -0700 Subject: [sword-devel] Remote Repositories In-Reply-To: References: <4D1A7FD2.3080105@crosswire.org> Message-ID: <4D1AC62C.4010802@crosswire.org> Thanks for the input Jonathan, On 12/28/2010 09:57 PM, Jonathan Morgan wrote: > > wrote: > UnlockURL= > This makes sense. If it were standardised we might put it in for > BPBible 0.5, but I wouldn't guarantee it at this stage. Thanks! > Is this something that could get out of date? A publisher changes their > URL schema and suddenly that link no longer works? Well, this will probably be used at install time, so hopefully the user is attempting to remote install the latest version of the module from the publisher's own remote repository which should have an up-to-date URL... but of course, I wouldn't put it past someone to forget to update the entry in the .conf file. > 2) Current Events: I'd like to have a: > > NEWS.txt > Well, a general comment which might have bearing on your thoughts below. This item was spawned by a publisher stating that they would like to "have a chance to interact with" users downloading modules from the publisher's repository. This was my first thought to give them a basic mechanism to do such. I called it "NEWS.txt" incidentally, as my best guess at what they'd like to say when they 'interacted' with users. I could be off on my assumptions, and obviously the repository maintainer could put whatever they wanted in there-- not just news. Maybe, as you say, simply a repository description, or "Visit us at: http://..." or whatever. Formatting is another issue you bring up which, if we decide to do this, we certainly do need to resolve. I'm not inclined to open up the issue of moving .conf entries from basicRTF+ markup right now, so it would probably stay in line with this lame legacy markup for now. Just as a summary to this topic, I understand we probably need to advance to some HTML markup for the .conf About section, but it requires an orchestrated switch, and frankly, I'm ok with having a very limited set of tags (I think we support italic, bold, center, paragraph break, and ) in our About section. It makes it easy for a variety of display methods on a variety of devices. And it really should just simply be an "About". Any more thoughts? Troy > Several thoughts on this: > 1. Is this the most appropriate place to display it? > 2. Will it be kept up to date? (I get frustrated by websites, etc. that > have news older than a year or two old, and are either no longer doing > anything or have given up telling me new things). > 3. Is it duplicating information shown elsewhere? Does it mean just > another thing for publishers to remember to keep up to date? > 4. What degree of formatting will be needed/wanted in this news? > > I would be inclined to suggest the following instead: > 1. Module repositories have some kind of a description or about > section. This states the purpose of repository, etc., and is hopefully > much less likely to change or be out of date. > 2. Module repositories can have a URL to the main site for that module > repository. This could be the main page of the publisher or a special > page for the SWORD repository or whatever else the publisher chooses. > If they want to have news I would probably expect it more to be on a > feed on a webpage somewhere than in InstallMgr. This also means those > who come across it who are not using SWORD get the same information, and > there are no compromises to force-fit the news to what frontends will > support. > > You could support something like this with a fairly standard conf file > at the base of the repository. Maybe other fields could be included as > well (such as a display name for the repository), but it seems to me a > bit arbitrary to have news and nothing else, and I'm not sure that I > follow the reasoning. > > Thoughts? > > Jon > > > Hope everyone has had a very wonderful Christmas filled with family, > friends, and love. > > > Troy > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 From greg.hellings at gmail.com Tue Dec 28 22:31:13 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Tue, 28 Dec 2010 23:31:13 -0600 Subject: [sword-devel] Remote Repositories In-Reply-To: <4D1AC62C.4010802@crosswire.org> References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: Why does the News.txt need to have a format we talk about? There are already perfectly good definitions for news lists and feeds already around. See RSS, Atom and related technologies. --Greg On Dec 28, 2010 11:25 PM, "Troy A. Griffitts" wrote: > Thanks for the input Jonathan, > > On 12/28/2010 09:57 PM, Jonathan Morgan wrote: >> > wrote: >> UnlockURL= > >> This makes sense. If it were standardised we might put it in for >> BPBible 0.5, but I wouldn't guarantee it at this stage. > > Thanks! > >> Is this something that could get out of date? A publisher changes their >> URL schema and suddenly that link no longer works? > > Well, this will probably be used at install time, so hopefully the user > is attempting to remote install the latest version of the module from > the publisher's own remote repository which should have an up-to-date > URL... but of course, I wouldn't put it past someone to forget to update > the entry in the .conf file. > > >> 2) Current Events: I'd like to have a: >> >> NEWS.txt >> > > Well, a general comment which might have bearing on your thoughts below. > This item was spawned by a publisher stating that they would like to > "have a chance to interact with" users downloading modules from the > publisher's repository. > > This was my first thought to give them a basic mechanism to do such. I > called it "NEWS.txt" incidentally, as my best guess at what they'd like > to say when they 'interacted' with users. I could be off on my > assumptions, and obviously the repository maintainer could put whatever > they wanted in there-- not just news. Maybe, as you say, simply a > repository description, or "Visit us at: http://..." or whatever. > > Formatting is another issue you bring up which, if we decide to do this, > we certainly do need to resolve. I'm not inclined to open up the issue > of moving .conf entries from basicRTF+ markup right now, so > it would probably stay in line with this lame legacy markup for now. > Just as a summary to this topic, I understand we probably need to > advance to some HTML markup for the .conf About section, but it requires > an orchestrated switch, and frankly, I'm ok with having a very limited > set of tags (I think we support italic, bold, center, paragraph break, > and ) in our About section. It makes it easy for a variety > of display methods on a variety of devices. And it really should just > simply be an "About". > > Any more thoughts? > > Troy > > > >> Several thoughts on this: >> 1. Is this the most appropriate place to display it? >> 2. Will it be kept up to date? (I get frustrated by websites, etc. that >> have news older than a year or two old, and are either no longer doing >> anything or have given up telling me new things). >> 3. Is it duplicating information shown elsewhere? Does it mean just >> another thing for publishers to remember to keep up to date? >> 4. What degree of formatting will be needed/wanted in this news? >> >> I would be inclined to suggest the following instead: >> 1. Module repositories have some kind of a description or about >> section. This states the purpose of repository, etc., and is hopefully >> much less likely to change or be out of date. >> 2. Module repositories can have a URL to the main site for that module >> repository. This could be the main page of the publisher or a special >> page for the SWORD repository or whatever else the publisher chooses. >> If they want to have news I would probably expect it more to be on a >> feed on a webpage somewhere than in InstallMgr. This also means those >> who come across it who are not using SWORD get the same information, and >> there are no compromises to force-fit the news to what frontends will >> support. >> >> You could support something like this with a fairly standard conf file >> at the base of the repository. Maybe other fields could be included as >> well (such as a display name for the repository), but it seems to me a >> bit arbitrary to have news and nothing else, and I'm not sure that I >> follow the reasoning. >> >> Thoughts? >> >> Jon >> >> >> Hope everyone has had a very wonderful Christmas filled with family, >> friends, and love. >> >> >> Troy >> >> >> _______________________________________________ >> 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 >> >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonmmorgan at gmail.com Tue Dec 28 22:44:33 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Wed, 29 Dec 2010 16:44:33 +1100 Subject: [sword-devel] Remote Repositories In-Reply-To: References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: Greg, On Wed, Dec 29, 2010 at 4:31 PM, Greg Hellings wrote: > Why does the News.txt need to have a format we talk about? There are > already perfectly good definitions for news lists and feeds already around. > See RSS, Atom and related technologies. > Because I'm not convinced that every frontend wants to have to implement parsing and display of RSS, Atom or related technologies. Having one chunk of formatted text to show might not be the best in the world, but at least it's relatively simple to do. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.hellings at gmail.com Tue Dec 28 22:50:49 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Tue, 28 Dec 2010 23:50:49 -0600 Subject: [sword-devel] Remote Repositories In-Reply-To: References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: Troy said he would provide a way to get the access from the engine. RSS is simply XML. Troy has told us the engine has Xml processing power (I don't know how it would handle the use of CDATA sections common in RSS). Every front end I am aware of has access to XML libraries already outside of Sword. --Greg On Dec 28, 2010 11:45 PM, "Jonathan Morgan" wrote: > Greg, > > On Wed, Dec 29, 2010 at 4:31 PM, Greg Hellings wrote: > >> Why does the News.txt need to have a format we talk about? There are >> already perfectly good definitions for news lists and feeds already around. >> See RSS, Atom and related technologies. >> > > Because I'm not convinced that every frontend wants to have to implement > parsing and display of RSS, Atom or related technologies. Having one chunk > of formatted text to show might not be the best in the world, but at least > it's relatively simple to do. > > Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From scribe at crosswire.org Tue Dec 28 23:04:58 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Tue, 28 Dec 2010 23:04:58 -0700 Subject: [sword-devel] Remote Repositories In-Reply-To: References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: <4D1ACF8A.2090700@crosswire.org> Greg, I might not have done a good job explaining the purpose of this field. My intention is to provide the publisher with a way to communicate basic information to users who view their repository from any of our applications. This may be news, it may be a promotion, it may just be a "Thanks for visiting our repository" blurb. Just some way the publisher can communicate information to anyone who might be interested in a publisher's repository. Hope this clears things up. Troy On 12/28/2010 10:50 PM, Greg Hellings wrote: > Troy said he would provide a way to get the access from the engine. > > RSS is simply XML. Troy has told us the engine has Xml processing power > (I don't know how it would handle the use of CDATA sections common in > RSS). Every front end I am aware of has access to XML libraries already > outside of Sword. > > --Greg > > On Dec 28, 2010 11:45 PM, "Jonathan Morgan" > wrote: >> Greg, >> >> On Wed, Dec 29, 2010 at 4:31 PM, Greg Hellings > >wrote: >> >>> Why does the News.txt need to have a format we talk about? There are >>> already perfectly good definitions for news lists and feeds already > around. >>> See RSS, Atom and related technologies. >>> >> >> Because I'm not convinced that every frontend wants to have to implement >> parsing and display of RSS, Atom or related technologies. Having one chunk >> of formatted text to show might not be the best in the world, but at least >> it's relatively simple to do. >> >> Jon > > > > _______________________________________________ > 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 From greg.hellings at gmail.com Tue Dec 28 23:12:04 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 29 Dec 2010 00:12:04 -0600 Subject: [sword-devel] Remote Repositories In-Reply-To: <4D1ACF8A.2090700@crosswire.org> References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> <4D1ACF8A.2090700@crosswire.org> Message-ID: That was clear - and RSS still fits the bill perfectly. A static file with one entry, or a dynamic list 100 entries long, and it cab be left to the app whether to display one entry, up to five, or all of them. The format is already defined, well known, easily processed, easily generated, very versatile and completely fills your need. We are not talking about the need for the engine or app to hold all the extra seen/unseen information and polling that generic RSS readers maintain. Simply parse a well defined format retrieved from the server and display it to the user. --Greg On Dec 29, 2010 12:05 AM, "Troy A. Griffitts" wrote: > Greg, > > I might not have done a good job explaining the purpose of this field. > My intention is to provide the publisher with a way to communicate basic > information to users who view their repository from any of our > applications. This may be news, it may be a promotion, it may just be a > "Thanks for visiting our repository" blurb. Just some way the publisher > can communicate information to anyone who might be interested in a > publisher's repository. > > Hope this clears things up. > > Troy > > > > On 12/28/2010 10:50 PM, Greg Hellings wrote: >> Troy said he would provide a way to get the access from the engine. >> >> RSS is simply XML. Troy has told us the engine has Xml processing power >> (I don't know how it would handle the use of CDATA sections common in >> RSS). Every front end I am aware of has access to XML libraries already >> outside of Sword. >> >> --Greg >> >> On Dec 28, 2010 11:45 PM, "Jonathan Morgan" > > wrote: >>> Greg, >>> >>> On Wed, Dec 29, 2010 at 4:31 PM, Greg Hellings >> >wrote: >>> >>>> Why does the News.txt need to have a format we talk about? There are >>>> already perfectly good definitions for news lists and feeds already >> around. >>>> See RSS, Atom and related technologies. >>>> >>> >>> Because I'm not convinced that every frontend wants to have to implement >>> parsing and display of RSS, Atom or related technologies. Having one chunk >>> of formatted text to show might not be the best in the world, but at least >>> it's relatively simple to do. >>> >>> Jon >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonmmorgan at gmail.com Tue Dec 28 23:17:00 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Wed, 29 Dec 2010 17:17:00 +1100 Subject: [sword-devel] Remote Repositories In-Reply-To: References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: Greg, On Wed, Dec 29, 2010 at 4:50 PM, Greg Hellings wrote: > Troy said he would provide a way to get the access from the engine. > > RSS is simply XML. Troy has told us the engine has Xml processing power (I > don't know how it would handle the use of CDATA sections common in RSS). > Every front end I am aware of has access to XML libraries already outside of > Sword. > My point still stands. A chunk of text to display is simple (the hardest decision is to think where to put it). Pre-formatted text is slightly harder, but still fairly simple. RSS requires some form of processing, and some form of formatting. It also makes it reasonably likely that you will have to consider showing either small quantities of text or large quantities of text, with corresponding UI implications. It all seems a bit of overkill when what the user probably wants is just a description of what the repository is. Jon > --Greg > On Dec 28, 2010 11:45 PM, "Jonathan Morgan" wrote: > > Greg, > > > > On Wed, Dec 29, 2010 at 4:31 PM, Greg Hellings >wrote: > > > >> Why does the News.txt need to have a format we talk about? There are > >> already perfectly good definitions for news lists and feeds already > around. > >> See RSS, Atom and related technologies. > >> > > > > Because I'm not convinced that every frontend wants to have to implement > > parsing and display of RSS, Atom or related technologies. Having one > chunk > > of formatted text to show might not be the best in the world, but at > least > > it's relatively simple to do. > > > > Jon > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.hellings at gmail.com Tue Dec 28 23:52:14 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 29 Dec 2010 00:52:14 -0600 Subject: [sword-devel] Remote Repositories In-Reply-To: References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: According to Troy it could function as a simple hello message, or it could function as a news list. That is why I suggest RSS as fulfilling both needs. If you want to limit it to a single plain blob, by all means, make it just a plaintext, rtf or html file that is staticly fetched and displayed. --Greg On Dec 29, 2010 12:17 AM, "Jonathan Morgan" wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: From scribe at crosswire.org Wed Dec 29 00:22:09 2010 From: scribe at crosswire.org (Troy A. Griffitts) Date: Wed, 29 Dec 2010 00:22:09 -0700 Subject: [sword-devel] Remote Repositories In-Reply-To: References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: <4D1AE1A1.6050104@crosswire.org> Hey Greg, Thanks for the suggestions. If we need to expand the functionality to a full blown news facility, then using RSS sounds like the right technology. Right now, I do think limiting the functionality is important. I need something easy to implement quickly so we can gain widespread adoption in all of our frontend applications. As Jonathan pointed out, the first, hardest part of implementing a simple blurb feature for the publisher is freeing up real estate somewhere for the component. It's really not much thought or effort beyond that. If we get requests from publishers who desire to maintain their own RSS feed within this mechanism, then we can expand the design at that time. Thanks for the input. Troy On 12/28/2010 11:52 PM, Greg Hellings wrote: > According to Troy it could function as a simple hello message, or it > could function as a news list. That is why I suggest RSS as fulfilling > both needs. If you want to limit it to a single plain blob, by all > means, make it just a plaintext, rtf or html file that is staticly > fetched and displayed. > > --Greg > > On Dec 29, 2010 12:17 AM, "Jonathan Morgan" > wrote: > > > > _______________________________________________ > 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 From dfhmch at googlemail.com Wed Dec 29 01:45:25 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 29 Dec 2010 00:45:25 -0800 (PST) Subject: [sword-devel] Remote Repositories In-Reply-To: <4D1AE1A1.6050104@crosswire.org> References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> <4D1AE1A1.6050104@crosswire.org> Message-ID: <1293612325752-3166863.post@n4.nabble.com> Troy, Why do we need a new conf element for news? Surely it would be sufficiently effective to include the URL for an RSS feed within the Description element. This is visible to all front-ends that have a feature to display the module description, whether during or after installation. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Remote-Repositories-tp3166646p3166863.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Wed Dec 29 01:47:59 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 29 Dec 2010 00:47:59 -0800 (PST) Subject: [sword-devel] Localized language names - a suggestion In-Reply-To: <1292747895278-3094297.post@n4.nabble.com> References: <1292747895278-3094297.post@n4.nabble.com> Message-ID: <1293612479904-3166868.post@n4.nabble.com> Troy's thread today about conf elements reminds me that nobody had responded to my earlier post. As this also relates to conf files, I am just issuing this reply as a reminder for you to consider something that may have fallen by the wayside in the run up to Christmas. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Localized-language-names-a-suggestion-tp3094297p3166868.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Wed Dec 29 01:53:46 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 29 Dec 2010 00:53:46 -0800 (PST) Subject: [sword-devel] BibleTech:2011 is in Seattle, March 25/26 In-Reply-To: <1287770829015-3007669.post@n4.nabble.com> References: <1287770829015-3007669.post@n4.nabble.com> Message-ID: <1293612826242-3166870.post@n4.nabble.com> Is anyone from CrossWire attending and/or speaking at http://www.bibletechconference.com/ BibleTech:2011 ? Submissions for titles and abstracts closed November 30, 2010. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/BibleTech-2011-is-in-Seattle-March-25-26-tp3007669p3166870.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Wed Dec 29 02:21:56 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 29 Dec 2010 01:21:56 -0800 (PST) Subject: [sword-devel] ICCM-Europe: Fer 9-12 in the Netherlands Message-ID: <1293614516707-3166883.post@n4.nabble.com> For CrossWire folk based in Europe, who might be interested. The International Conference on Computing & Missions : Europe 2011 will take place (d.v.) February 9 (Wednesday) - February 12 (Saturday), 2011 - De Betteld - The Netherlands http://www.iccm-europe.org/ http://www.iccm-europe.org/ I attended and enjoyed the 2010 conference. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/ICCM-Europe-Fer-9-12-in-the-Netherlands-tp3166883p3166883.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dfhmch at googlemail.com Wed Dec 29 06:52:10 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 29 Dec 2010 05:52:10 -0800 (PST) Subject: [sword-devel] need we bookmarks/history storage standart? In-Reply-To: <1269433106826-1680448.post@n4.nabble.com> References: <20100323122449.30880@gmx.net> <74317659.20100323171848@mail.ru> <1918426719.20100323193330@mail.ru> <4BA7D01B.8090007@cox.net> <49A8417A-D2CE-4EA3-99CB-3CC5B96050E4@mac.com> <4BA9CC1A.3080600@gmx.net> <4BA9D0B1.80401@gmx.net> <1269429742996-1680389.post@n4.nabble.com> <75a952c01003240454m49960b50we4e0135effec19f0@mail.gmail.com> <1269433106826-1680448.post@n4.nabble.com> Message-ID: <1293630730940-3167120.post@n4.nabble.com> Resurrecting an old thread, that seems to have gone a bit stale since March. Have others seen http://readitlaterlist.com/ http://readitlaterlist.com/ David -- View this message in context: http://sword-dev.350566.n4.nabble.com/need-we-bookmarks-history-storage-standart-tp1678793p3167120.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dmsmith at crosswire.org Wed Dec 29 08:39:46 2010 From: dmsmith at crosswire.org (DM Smith) Date: Wed, 29 Dec 2010 10:39:46 -0500 Subject: [sword-devel] Remote Repositories In-Reply-To: <4D1AC62C.4010802@crosswire.org> References: <4D1A7FD2.3080105@crosswire.org> <4D1AC62C.4010802@crosswire.org> Message-ID: <54F26F65-3A33-4FCB-A3C7-8D60F8C3D4AF@crosswire.org> On Dec 29, 2010, at 12:25 AM, Troy A. Griffitts wrote: > I'm ok with having a very limited > set of tags (I think we support italic, bold, center, paragraph break, > and ) in our About section. The "official" statement regarding our conf is: http://crosswire.org/wiki/DevTools:confFiles It is well maintained with the results of discussions here. Only the ShortPromo section allows label The only allowable RTF is: \qc \par \pard \u{num}? It is allowed only in the About section. On another note: * There are confs with bad Version= strings. It is supposed to be a number. It specifically says to not use non--numbers. In Him, DM -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfhmch at googlemail.com Wed Dec 29 09:16:54 2010 From: dfhmch at googlemail.com (David Haslam) Date: Wed, 29 Dec 2010 08:16:54 -0800 (PST) Subject: [sword-devel] ICCM-Europe: Feb 9-12 in the Netherlands In-Reply-To: <1293614516707-3166883.post@n4.nabble.com> References: <1293614516707-3166883.post@n4.nabble.com> Message-ID: <1293639414987-3167310.post@n4.nabble.com> Pasted from an email... "John Edmiston is our keynote speaker this year and the slant of the conference will be on the use of Cyberspace in missions. We are still finalising the workshop program(me) and information will be posted to www.iccm-europe.org as these are put together." David -- View this message in context: http://sword-dev.350566.n4.nabble.com/ICCM-Europe-Fer-9-12-in-the-Netherlands-tp3166883p3167310.html Sent from the SWORD Dev mailing list archive at Nabble.com. From greg.hellings at gmail.com Wed Dec 29 09:37:39 2010 From: greg.hellings at gmail.com (Greg Hellings) Date: Wed, 29 Dec 2010 10:37:39 -0600 Subject: [sword-devel] BibleTech:2011 is in Seattle, March 25/26 In-Reply-To: <1293612826242-3166870.post@n4.nabble.com> References: <1287770829015-3007669.post@n4.nabble.com> <1293612826242-3166870.post@n4.nabble.com> Message-ID: I am contemplating attending. Depends on how life and finances shake out in the next few weeks and months. --Greg On Wed, Dec 29, 2010 at 2:53 AM, David Haslam wrote: > > Is anyone from CrossWire attending and/or speaking at > http://www.bibletechconference.com/ BibleTech:2011 ?? > > Submissions for titles and abstracts closed November 30, 2010. > > David > > > > > -- > View this message in context: http://sword-dev.350566.n4.nabble.com/BibleTech-2011-is-in-Seattle-March-25-26-tp3007669p3166870.html > Sent from the SWORD Dev mailing list archive at Nabble.com. > > _______________________________________________ > 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 > From bdrake at crosswire.org Thu Dec 30 04:54:24 2010 From: bdrake at crosswire.org (Barry Drake) Date: Thu, 30 Dec 2010 11:54:24 +0000 Subject: [sword-devel] Sword Support question ..... Message-ID: <1293710064.3177.7.camel@pcspecialist> Please can someone supply answers. There have been two on the support list in the last couple of days. I'm not cross posting because I got told off about that, but I can't respond as one was on Windows Vista, and the other on Windows 7. Both are from people wanting to make the personal commentary work. I corresponded with one of them to find out what software and what OS he had. Turned out he had an old version of the Sword Project for Windows purchased at great expense from CDEarth. He got the later version from us, but still couldn't work it. As he is on Vista I can't help. Today's question is below: "I do not see any way of adding a personal commentary, I have checked everything that I can think to do, right clicking the commentary, looking in the menus and nothing seems to allow me to add a commentary. I am using: Windows 7, BPBible 0.4.7" Can someone who knows post an FAQ about this please? God bless, Barry. -- What do you see when you use your Computer? Same old thing? ...There IS a Better Way! Ubuntu! From chris at burrell.me.uk Thu Dec 30 05:05:05 2010 From: chris at burrell.me.uk (Chris Burrell) Date: Thu, 30 Dec 2010 12:05:05 +0000 Subject: [sword-devel] Sword Support question ..... In-Reply-To: <1293710064.3177.7.camel@pcspecialist> References: <1293710064.3177.7.camel@pcspecialist> Message-ID: Hi Barry From bogus@does.not.exist.com Tue Dec 14 19:32:00 2010 From: bogus@does.not.exist.com () Date: Wed, 15 Dec 2010 02:32:00 -0000 Subject: No subject Message-ID: personal commentaries and scratch pad functionality is probably planned for 0.5 "s*cratchpad:* I believe that this is planned for 0.5 along with a "personal commentary" thing." So I guess you'll have to wait a wee bit longer before you can get to that functionality. Cheers Chris On 30 December 2010 11:54, Barry Drake wrote: > Please can someone supply answers. There have been two on the support > list in the last couple of days. I'm not cross posting because I got > told off about that, but I can't respond as one was on Windows Vista, > and the other on Windows 7. Both are from people wanting to make the > personal commentary work. I corresponded with one of them to find out > what software and what OS he had. Turned out he had an old version of > the Sword Project for Windows purchased at great expense from CDEarth. > He got the later version from us, but still couldn't work it. As he is > on Vista I can't help. Today's question is below: > "I do not see any way of adding a personal commentary, I have checked > everything that I can think to do, right clicking the commentary, > looking in the menus and nothing seems to allow me to add a commentary. > I am using: Windows 7, BPBible 0.4.7" > > Can someone who knows post an FAQ about this please? > > God bless, Barry. > -- > What do you see when you use your Computer? Same old thing? > ...There IS a Better Way! Ubuntu! > > > _______________________________________________ > 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 > --0016e64caa7e0eda3e04989f7f91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Barry

From a look at the website:=A0http://bpbible.com/node/33, it suggests that pers= onal commentaries and scratch pad functionality is probably planned for 0.5=

"scratc= hpad:=A0I believe that this is planned for 0.5 along with a "pers= onal commentary" thing."

So I guess you'll have to wait a wee bit longer bef= ore you can get to that functionality.

Cheers

Chris

On 30 December 2010 11:54, Barry = Drake <bdrake@= crosswire.org> wrote:

Please can someone supply answers. =A0There= have been two on the support
list in the last couple of days. =A0I'm not cross posting because I got=
told off about that, but I can't respond as one was on Windows Vista, and the other on Windows 7. =A0Both are from people wanting to make the
personal commentary work. =A0I corresponded with one of them to find out what software and what OS he had. =A0Turned out he had an old version of the Sword Project for Windows purchased at great expense from CDEarth.
He got the later version from us, but still couldn't work it. =A0As he = is
on Vista I can't help. =A0Today's question is below:
"I do not see any way of adding a personal commentary, I have checked<= br> everything that I can think to do, right clicking the commentary,
looking in the menus and nothing seems to allow me to add a commentary.
I am using: Windows 7, BPBible 0.4.7"

Can someone who knows post an FAQ about this please?

God bless, =A0 =A0 =A0 =A0 =A0 =A0 =A0Barry.
--
What do you see when you use your Computer? Same old thing?
...There IS a Better Way! =A0Ubuntu!

_______________________________________________
sword-devel mailing list: swor= d-devel at crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

--0016e64caa7e0eda3e04989f7f91-- From jonmmorgan at gmail.com Thu Dec 30 06:41:22 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Fri, 31 Dec 2010 00:41:22 +1100 Subject: [sword-devel] Sword Support question ..... In-Reply-To: References: <1293710064.3177.7.camel@pcspecialist> Message-ID: I have replied to the BPBible question, as I always try to do fairly promptly (even though sword-support is not our primary or recommended support location). As to when we plan to support particular functionality, like all of the projects here BPBible's Roadmap tends to fluctuate based on time available, shifting priorities, etc., etc. Anything said in a forum post 2 years ago would be much more likely to reflect our hopes than any kind of reality, and so is not necessarily to be trusted. In this case I can guarantee you that the functionality will not be in 0.5. It's actually in our current Roadmap as 0.6, but that number is rather arbitrary, and it is very likely to depend on what we decide 0.6 will be and when we decide to do it. Jon On Thu, Dec 30, 2010 at 11:05 PM, Chris Burrell wrote: > Hi Barry > > From a look at the website: http://bpbible.com/node/33, it suggests that > personal commentaries and scratch pad functionality is probably planned for > 0.5 > > "s*cratchpad:* I believe that this is planned for 0.5 along with a > "personal commentary" thing." > > So I guess you'll have to wait a wee bit longer before you can get to that > functionality. > Cheers > Chris > > > On 30 December 2010 11:54, Barry Drake wrote: > >> Please can someone supply answers. There have been two on the support >> list in the last couple of days. I'm not cross posting because I got >> told off about that, but I can't respond as one was on Windows Vista, >> and the other on Windows 7. Both are from people wanting to make the >> personal commentary work. I corresponded with one of them to find out >> what software and what OS he had. Turned out he had an old version of >> the Sword Project for Windows purchased at great expense from CDEarth. >> He got the later version from us, but still couldn't work it. As he is >> on Vista I can't help. Today's question is below: >> "I do not see any way of adding a personal commentary, I have checked >> everything that I can think to do, right clicking the commentary, >> looking in the menus and nothing seems to allow me to add a commentary. >> I am using: Windows 7, BPBible 0.4.7" >> >> Can someone who knows post an FAQ about this please? >> >> God bless, Barry. >> -- >> What do you see when you use your Computer? Same old thing? >> ...There IS a Better Way! Ubuntu! >> >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfhmch at googlemail.com Thu Dec 30 06:54:38 2010 From: dfhmch at googlemail.com (David Haslam) Date: Thu, 30 Dec 2010 05:54:38 -0800 (PST) Subject: [sword-devel] Sword Support question ..... In-Reply-To: <1293710064.3177.7.camel@pcspecialist> References: <1293710064.3177.7.camel@pcspecialist> Message-ID: <1293717278296-3168277.post@n4.nabble.com> The person Barry is trying to help has been ripped off by CDEarth. All CrossWire software is free (in the sense of both "free speech" and "free beer"). Even the CD we can provide on request is only charged for the P&P & the negligible cost of the actual disc. ... CDEarth is a SCAM, as was it's predecessor called ThinkAll. See http://www.veign.com/blog/2007/10/14/cdearth-thinkall-one-big-scam/ Although the CD?s are sent to you free (pay shipping only) your CD?s must be sent back to them within 10 days or your credit card will automatically be charged. Not only that you are signing up for a membership where they automatically send you CD?s and charge your credit card if not returned after a very short evaluation period. ... CD Earth is doing the exact same thing. They are selling software that they say is Free software, as listed in the page title and in the footer under the FreeSoftwareCD.net, and automatically enrolling you in a Software Library Club, as listed in their Terms of Service. The Software Library Club is charging $14.99 per CD that you keep beyond 25 days that will automatically sent to you every month and they will charge for shipping these CDs to you every month. ... David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Sword-Support-question-tp3168189p3168277.html Sent from the SWORD Dev mailing list archive at Nabble.com. From dmsmith at crosswire.org Thu Dec 30 08:47:20 2010 From: dmsmith at crosswire.org (DM Smith) Date: Thu, 30 Dec 2010 10:47:20 -0500 Subject: [sword-devel] Raw Dictionaries being indexed by Google Message-ID: <4D1CA988.9090708@crosswire.org> Just thought this was interesting. I did a Google search and got a hit on our raw dictionaries (site:crosswire.org panther). It turned up: http://www.crosswire.org/sword/download/ftpmirror/pub/sword/raw/modules/lexdict/rawld/glossaries/ereo_en/ereo_en.dat In Him, DM From dfhmch at googlemail.com Thu Dec 30 09:13:22 2010 From: dfhmch at googlemail.com (David Haslam) Date: Thu, 30 Dec 2010 08:13:22 -0800 (PST) Subject: [sword-devel] Raw Dictionaries being indexed by Google In-Reply-To: <4D1CA988.9090708@crosswire.org> References: <4D1CA988.9090708@crosswire.org> Message-ID: <1293725602482-3168454.post@n4.nabble.com> Google will index everything it can, unless you prevent it with a suitable http://en.wikipedia.org/wiki/Robots_exclusion_standard robots.txt file. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Raw-Dictionaries-being-indexed-by-Google-tp3168428p3168454.html Sent from the SWORD Dev mailing list archive at Nabble.com. From jonmmorgan at gmail.com Fri Dec 31 06:24:23 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Sat, 1 Jan 2011 00:24:23 +1100 Subject: [sword-devel] BPBible 0.5 beta 1 released Message-ID: Hi all, BPBible 0.5 beta 1 has been released. As this is the first preview version using the new rendering engine and other major UI changes have been made, we would welcome anyone interested downloading the beta and giving us any feedback. Find out more about it at http://bpbible.com/news/bpbible-0.5-beta1-released. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From DavidTroidl at aol.com Fri Dec 31 07:29:19 2010 From: DavidTroidl at aol.com (David Troidl) Date: Fri, 31 Dec 2010 09:29:19 -0500 Subject: [sword-devel] BPBible 0.5 beta 1 released In-Reply-To: References: Message-ID: <4D1DE8BF.7060906@aol.com> Hi, I did download the beta, and had some feedback. I created an account on the BP Bible site. Do you have a mailing list I could write to? I can't stand forums. Peace, David On 12/31/2010 8:24 AM, Jonathan Morgan wrote: > Hi all, > > BPBible 0.5 beta 1 has been released. As this is the first preview > version using the new rendering engine and other major UI changes have > been made, we would welcome anyone interested downloading the beta and > giving us any feedback. Find out more about it at > http://bpbible.com/news/bpbible-0.5-beta1-released. > > Jon > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhowens at pmbx.net Fri Dec 31 09:13:30 2010 From: dhowens at pmbx.net (Daniel Owens) Date: Fri, 31 Dec 2010 10:13:30 -0600 Subject: [sword-devel] BPBible 0.5 beta 1 released In-Reply-To: References: Message-ID: <4D1E012A.8020404@pmbx.net> This has been worth waiting for. Right to left and continuous scrolling is a huge step forward. I also like the options for displaying Strongs numbers. Well done! Daniel On 12/31/2010 07:24 AM, Jonathan Morgan wrote: > Hi all, > > BPBible 0.5 beta 1 has been released. As this is the first preview > version using the new rendering engine and other major UI changes have > been made, we would welcome anyone interested downloading the beta and > giving us any feedback. Find out more about it at > http://bpbible.com/news/bpbible-0.5-beta1-released. > > Jon > > > _______________________________________________ > 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 From jonmmorgan at gmail.com Fri Dec 31 20:39:07 2010 From: jonmmorgan at gmail.com (Jonathan Morgan) Date: Sat, 1 Jan 2011 14:39:07 +1100 Subject: [sword-devel] BPBible 0.5 beta 1 released In-Reply-To: <4D1DE8BF.7060906@aol.com> References: <4D1DE8BF.7060906@aol.com> Message-ID: Hi David, There are a few other options for giving feedback: 1. You can create issues in our issue tracker ( http://code.google.com/p/bpbible/issues/list). You'll need a Google Account for that. 2. You can subscribe to the BPBible Developers Google Group ( http://groups.google.com/group/bpbible-devel?hl=en) and email there. 3. You can email me directly. Whichever method you choose I will probably be the first point of contact, so it doesn't really matter too much. Jon On Sat, Jan 1, 2011 at 1:29 AM, David Troidl wrote: > Hi, > > I did download the beta, and had some feedback. I created an account on > the BP Bible site. Do you have a mailing list I could write to? I can't > stand forums. > > Peace, > > David > > > On 12/31/2010 8:24 AM, Jonathan Morgan wrote: > > Hi all, > > BPBible 0.5 beta 1 has been released. As this is the first preview version > using the new rendering engine and other major UI changes have been made, we > would welcome anyone interested downloading the beta and giving us any > feedback. Find out more about it at > http://bpbible.com/news/bpbible-0.5-beta1-released. > > Jon > > > _______________________________________________ > sword-devel mailing list: sword-devel at crosswire.orghttp://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: