dmsmith at crosswire.org
Thu Nov 8 10:36:51 MST 2012
It would be straightforward to model it in JSword after the GBF filter. It'd essentially be the equivalent of the usfm2osis script. That's a work in progress. And since usfm input is not "clean" having it in JSword is dubious at best.
Also I don't see the value for modules unless the SWORD library does as well.
On Nov 8, 2012, at 5:39 AM, Chris Burrell <chris at burrell.me.uk> wrote:
> Thanks for all the info. On the last point, I did mean read directly from USFM. I don't know the format well-enough, but presumably if other software uses it, then maybe we could have a go at displaying the best we can...
> On 8 November 2012 10:17, Peter von Kaehne <refdoc at gmx.net> wrote:
> Hi Chris,
> > Von: Chris Burrell <chris at burrell.me.uk>
> > I've found some instructions on transforming usfm/x to osis on the wiki
> > but
> > was wondering how difficult it would be to automate a lot of it?
> Several of us have been starting to think and experiment with this too.
> Basically it is easy to automate as such. The problem is around cleaning up.
> There is a thread earlier this year where some of this was discussed. The basic plan is to use a git repository and git hooks with scripts attached to that. Some infrastructure is up, but not much else has happened yet.
> > is it such that there is too much manual cleaning up?
> Manual/mechanical cleaning up is a huge need, unfortunately. I have not yet encountered a truly clean USFM text, despite all claims by various USFM experts.
> > also, I was wondering if there's any appetite in developing a driver to
> > read such modules, within sword or jsword...
> You mean to read directly USFM?
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sword-devel