[sword-devel] Sword enhancement proposal [was: HTML filter cross references link]

Greg Hellings greg.hellings at gmail.com
Mon Jul 28 23:54:51 MST 2008


Manfred,

On Tue, Jul 29, 2008 at 1:45 AM, Manfred Bergmann <bergmannmd at web.de> wrote:
> Troy.
> I installed GnomeSword and checked how they do with cross-references.
> Actually it is quite similar to how BibleCS deals with it.
> The main problem I have with this is that as far as I understood without
> Sword producing the markup output there is no full access to all the meta
> data because on the other hand you are saying that we should not use the raw
> access which I can understand because using raw access means one has to deal
> with different types of raw sources.
> This in my opinion ties the hands of the frontend-developer in that Sword
> interferes too much into the display of the data or differently spoken does
> not give the flexibility and data access without having Sword produce data
> meant for display.
> HTML is my eyes is a markup meant for display.
> Although I don't understand right now how the Sword module data is stored,
> my proposal here is that Sword should have a simple intermediate XML format
> that can be used by API users to have full access to the module data.

My understanding is that JSword operates similar to this.  It produces
intermediate XML (OSIS) from the module information and applies an
XSLT to transform the data.  In that case, why the modules themselves
could not be in an OSIS format escapes me -- still keeping the index
files for fast access and so on.  OK, so yeah, it would horridly break
backwards compatibility with the modules.  With the current updates to
the keying structure for Bibles, maybe re-releasing all of the modules
should also be a major priority... work similar to what was put into
the KJV module.  Put them all into OSIS formats, manually make
corrections as necessary, and update the modules.  It would definitely
take a lot of person-months of labor, though.

> Simple HTML/RTF can still be produced from this intermediate format by
> Sword. But HTML should not be used to give access to the module data while
> at the same time raw data access should not be used.
> Having XSDs would make is easy for API-users to use XML->Object binding (I
> only know JAXB in Java but this might be available to most languages as it
> is used in protocols like SOAP).
> Also XSLT stylesheets can be used to produce HTML or whatever output.
> Frontends could choose to use the HTML rendered output or choose totally
> different approaches by using the data of the intermediate XML.
> Let me know what you think.

It seems to me that this is one of the better ideas.  After all, the
library should supply display-agnostic data to the front end, which
then renders it into a display format, rather than presenting it with
a list of a few preselected display formats which are supported at the
engine level.

--Greg

>
> Regards,
> Manfred
>
>
> Am 28.07.2008 um 12:35 schrieb Troy A. Griffitts:
>
> Manfred,
>
> In addition to what Ben wrote, GnomeSword uses the stock HTMLHREF
> filters and doesn't add their own.  These filters are usually updated by
> me or someone on their team.  It might be good to pop in to
> irc.freenode.net #sword and ask charcoal about how they do certain
> things with these filters.
>
> -Troy.
>
>
>
> Manfred Bergmann wrote:
>
> Hi Ben.
>
> Ok, one can get the cross-references by getting the entry attributes.
>
> But if the body is not passed in again to the filter you can't figure
>
> anymore to which word the cross-reference is related to by just
>
> parsing the attributes.
>
> The only chance to get the relationship is to show the information in
>
> the tooltip or while clicking on the cross-ref link.
>
> Please correct me if I'm wrong.
>
> If this is correct I have to say that this is quite unflexible.
>
> If someone chooses to not render anything related to cross-references
>
> but still wants to have the data (to show it somewhere else) there is
>
> no way to get the word -> cross-ref relationship.
>
>
>
> Regards,
>
> Manfred
>
>
> Am 28.07.2008 um 01:35 schrieb Ben Morgan:
>
> Yes, there was a change.
>
> I had to change BPBible as well :)
>
> From r2157:
>
> Modified: trunk/src/modules/filters/
>
> osisfootnotes.cpp
>
> ===================================================================
>
> --- trunk/src/modules/filters/osisfootnotes.cpp 2008-05-13 02:58:16
>
> UTC (rev 2156)
>
> +++ trunk/src/modules/filters/osisfootnotes.cpp 2008-05-13 23:37:56
>
> UTC (rev 2157)
>
> @@ -108,7 +108,7 @@
>
>                                       hide = false;
>
>                                       if (option ||
>
> (startTag.getAttribute("type") && !
>
> strcmp(startTag.getAttribute("type"), "crossReference"))) {    // we
>
> want the tag in the text; crossReferences are handled by another
>
> filter
>
>                                               text.append(startTag);
>
> -                                               text.append(tagText);
>
> +//
>
> text.append(tagText);   // we don't put the body back in because it
>
> is retrievable from EntryAttributes["Footnotes"][]["body"].
>
>                                       }
>
>                                       else    continue;
>
>                               }
>
> As it says, you can just get the text using getEntryAttributes at
>
> the end of the note.
>
> The way BPBible installs custom filters is by subclassing the
>
> MarkupFilterMgr's AddRenderFilters, rather than the SWMgr's
>
> It would be nice if you could pass the filters you wanted used in,
>
> though. This would be a pretty common use case...
>
> God Bless,
>
> Ben
>
> -------------------------------------------------------------------------------------------
>
> The Lord is not slow to fulfill his promise as some count slowness,
>
> but is patient toward you, not wishing that any should perish,
>
> but that all should reach repentance.
>
> 2 Peter 3:9 (ESV)
>
>
> On Sun, Jul 27, 2008 at 9:09 PM, Manfred Bergmann
>
> <bergmannmd at web.de> wrote:
>
> Hi Troy.
>
>
> Am 26.07.2008 um 18:44 schrieb Troy A. Griffitts:
>
>      Do you have:
>
>     swordManager.setGlobalOption("Cross-references", "On");
>
> anywhere in your code?
>
> Yes.
>
> I just tested a version of MacSword with Sword library 1.5.10 where
>
> the cross ref list (<reference> elements) are placed inside the note
>
> element and are passed to the HTML filter.
>
> Has there been a change for this from 1.5.10 to 1.5.11?
>
> Yes.  You should never have to call AddRenderFilter to a module,
>
> though
>
> we do allow you to add your own special filters by overriding the
>
> virtual SWMgr::AddRenderFilters() method if one of the default SWORD
>
> filter sets does not work for you.  Not sure how MacSword does it
>
> now.
>
> Hmm, we are doing exactly that ATM.
>
> We didn't override AddRenderFilters() in SWMgr but set Filter subclass
>
> instances for every module in a loop via Module::AddRenderFilter().
>
> So the prefered way is to do this via SWMgr::AddRenderFilters().
>
> The MarkupFilterMgr is the mechanism to ask SWORD to give you a
>
> specific
>
> output markup from RenderText().  This code figures out which filter
>
> set
>
> to apply to each module depending on the module SourceType (OSIS,
>
> GBF,
>
> ThML, etc...) and will apply the correct filters to meet your
>
> requested
>
> output type.  But if you can't use any of the default filter sets,
>
> then
>
> you'll have to override SWMgr::AddRenderFilters() and apply your
>
> custom
>
> filters.
>
> We did that and used RenderFilters from BibleTime project from 2001.
>
> But I adapted some changes of the current Sword render filters so the
>
> new attributes are checked for additionally to the depricated ones.
>
>
>
> Regards,
>
> Manfred
>
>
> _______________________________________________
>
> 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
>
>
> _______________________________________________
> 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
>



More information about the sword-devel mailing list