[sword-devel] Xiphos Personal Commentary into PocketSword

[Jonathan Morgan]

On Tue, May 4, 2010 at 10:02 PM, Karl Kleinpaste <karl at kleinpaste.org>wrote:

> Yup, you're right.  I didn't even notice (didn't recall, haven't thought
> about in eons) that the link encoding uses a Xiphos-internal reference.
>
> And we fill it with HTML because that's the nature of the editor that
> Xiphos uses (gtkhtml3), so getRawEntry() is what we find useful.
>
> I don't have any immediate ideas for how to address transportability of
> this sort of thing, although it occurs to me that what comes out of the
> engine for internal links is, in general, content of just that form but
> using "passagestudy.jsp", as seen in...
>
> $ grep -l passagestudy src/*/*/*
> src/modules/filters/gbfhtmlhref.cpp
> src/modules/filters/gbfwebif.cpp
> src/modules/filters/osishtmlhref.cpp
> src/modules/filters/osiswebif.cpp
> src/modules/filters/teihtmlhref.cpp
> src/modules/filters/thmlhtmlhref.cpp
> src/modules/filters/thmlwebif.cpp
>
> This is to say, the parameter use is actually internally consistent.
>

Yes, I know BPBible parses all of those URLs, and I noticed the structure
was similar, though I hadn't compared them.  Any programs not using the
HTMLHREF filters are less likely to support them (BibleTime, BibleCS,
others?).  I suppose to my mind the difference is that those are just the *
output* of the filters, not the input, and to use the module I have to
"know" that I have to read it as raw HTML (though it might almost get
through the ThML filters unscathed - I haven't tried it).  This is fine if
all applications do this, but the minute one of them decides to have a
personal commentary type module using proper OSIS or ThML we're stuck (or
will be eventually).  And once another application tries to edit it rather
than just reading it the chance that both HTML editors will support the same
subset of HTML in the same way is probably fairly low, unfortuantely.  [This
is of course sent with the caveat that I'm really not sure what percentage
of users want this kind of program interoperability.]

As for why we use "xiphos.url" internally...  I suspect that's lost to
> the mists of time, unless Terry can recall.  I can change this in a
> straightforward fashion, but it has a backward-compatibility issue for
> existing user-edited content for use in other applications.


Yes.

On Tue, May 4, 2010 at 10:11 PM, Karl Kleinpaste <karl at kleinpaste.org>
 wrote:

> A late thought...
>
> Considering that there are no HTML-to-AnythingElse filters, it would
> appear that this sort of locally-edited content is inherently
> application-specific.  What does BibleCS generate?  Raw RTF?  Same
> problem, going the other way.  Yes, there does exist
> src/modules/filters/rtfhtml.cpp, but all it handles is par, pard, and
> qc, not remotely sufficient for the generality of other display drivers.
>

IIRC, most newer frontends use some brand of HTML.  Similarly, (unless
you're on Windows using the standard RichEdit RTF type control) the chance
of your rich text editor being an HTML editor is fairly good.

I'm pretty certain I remember bug reports against BibleTime in the past that
established BibleCS was using RTF.  It was definitely something that wasn't
readily interoperable.

 As said, the application can fill a user-edited segment with anything at
> all -- plain text, HTML, or LaTeX.  I don't think anyone is sufficiently
> insane as to actually implement a LaTeX editor, but this is a source of
> trouble that will not be easily resolved.
>

Perhaps at a minimum we need new module types or additional conf file
information to say exactly what format the module is in.  Whether
applications choose to support that format is another matter, but knowing it
would IMHO be a good thing.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20100504/d2265267/attachment.html>