On Tue, Nov 30, 2010 at 9:18 AM, Peter von Kaehne <ref...@gmx.net> wrote: > >> Von: Greg Hellings <greg.helli...@gmail.com> > >> However, a few problems arise. Namely, I have no control over the >> display of the text in my target applications (Xiphos and Bibletime) >> when I use OSIS. You, being in the semantics-please camp, might think >> that's a good thing. You've stymied my attempt, as a content creator, >> to actually accomplish my goal of influencing rendering. But as the >> content creator, I'm not willing to be stymied because the task I was >> given was to make these texts render the same in SWORD as they do in >> the source app. > > Not withstanding my previous comments on this thread being an annually > repetitive occurrence, i do think there is a problem in your reasoning, Greg: > > Once you target a specific frontend you end up in the same scenario as we had > with the South African modules for BibleCs only. or - on a grander scale - as > all those IE6-only sites. >
These modules are for internal use by an organization. In time, some of them might be made available to people outside the org, but for their internal use, they can control which applications people use. Additionally, the proprietary software they use is available on Windows (so BibleCS is a moot point for them) and Macintosh (so MacSword is also immaterial in their view). When the project was started 5 years back, BT and then-Gnomesword were basically the only two options on Linux, so that was the choice. Also, the handheld displays are of no interest to them, neither are the more gimmicky frontends that, for instance, display in a browser or from the command line. Since the project was started, BPBible has also made a showing, and JSword has matured. I would venture to guess that BPBible - using largely the same technologies as Xihpos as for module rendering - would display these modules fine. My guess is that MacSword would as well, since I think it uses the HTMLHREF filter (like Xiphos) and the embedded Safari widget (very similar to BT's QWebKit widget). I know not how BibleDesktop would fare, since I have never used it, but that largely depends on whether it would preserve the content of the style attribute on the ThML raw SWORD entry. So the only frontends left to the ravages of cross-format translation would be BD (ThML -> OSIS -> HTML) and BibleCS (ThML -> RTF). I'm fine with BibleCS not working, and maybe some day I'll give BD a look after these modules work fine in the "target" applications. > I would much rather we produced good modules and filed endless numbers of bug > reports against any application and the library for non-compliance if things > which should work do not work, instead of targetting the oddities and > non-compliant aspects of each application separately. > > And yes, I think XSLT and CSS combination would be the best. I am still > waiting for Troy's actual reasoning rather than his gut reaction to XSLT. He > promised it. I understand not wanting to provide the transformation at the engine level. SWORD would then need to either provide an XSLT implementation (any takers?), select one of the ones available (which all come with lots of baggage - libxml2 is relatively lightweight without too many dependencies, but it does have some; QXml relies on Qt; Gecko would require installation of most of the Mozilla/Firefox libraries, etc) or support many options - which is still more work. While I might opt to have libxml2 support if it were up to me, I can understand not wanting to do so. But the fact is that all of the front-ends I know of, except for BibleCS, already have access to XSLT power in their toolkits. libxml2 is a part of most Gnome stacks, QXml is already available for BibleTime, BPBible has XML processing built-in to Python and possibly through wxWidgets as well, Android apps have access to Java which has extensive XML support, anyone using the Perl bindings has access to a plethora of CPAN modules to handle XML, etc. BibleCS might even have XSLT powers somewhere in Borland's libraries, though I wouldn't know. So all that points to the power which could be had if the library produced valid OSIS documents or even fragments for a requested passage, and then the frontend could select to process through XSLT, DOM, SAX, or anything else they wanted. But that would require someone to step up and fix the *OSIS filters. I have enough work done on fixing mod2osis that it could be generalized into the library to support that use, if this was desired. But I can't justify taking the time (for me it would be months because string manipulation in C is probably my weakest knowledge in programming) away from getting these modules out the door now. After they are done, I intend to go back to that task, but since ThML works grandly for me now, I will just use it. --Greg _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page