[sword-devel] Linked in audio files

[Matthew Talbert]

On Wed, Aug 25, 2010 at 8:20 AM, Karl Kleinpaste <karl at kleinpaste.org> wrote:
>
> Chris Little <chrislit at crosswire.org> writes:
> > If you mean to embed the audio in-line, I would recommend using the
> > <figure> element. There's nothing specifically image-oriented about the
> > element, aside from implications made by its name.
>
> Yes, there is: The XXXhtmlhref filters wrap the resulting HTML <img>
> element in <a href="passagestudy.jsp?action=showImage..."> for the sake
> of letting the application kick off a standard external viewer, if it
> knows how to do so.
>
> Sure, we could expect applications to extend the semantic of "showImage"
> to include playing audio files, fine.  Then we are left with how to
> display a clickable element (or some similar mechanism) for the user to
> be made aware that he's got an audio clip he could play, because
> otherwise there's no visible content wrapped by the showImage href.  So
> the application probably has to hack the filter output to spackle in a
> standard miniature image to indicate it, to go along with the intended
> <img> pseudo-picture actually-audio reference, and then understand how
> to distinguish file types being kicked with an image viewer versus being
> kicked with an audio player.
>
> I think this overloads img/figure quite a lot, to no good benefit in the
> long run.  Better would be tags that indicate audio natively, rather
> than to coerce image support, and have the filters do the right thing by
> producing a visible "you can click here to hear audio" marker.
>
> No matter how one looks at it, there is a fair amount of work to be done
> to support such a thing.
>

What would seem better to me is for the importers to add these as an
Entry Attribute. As already used in the engine, entry attributes can
be Footnotes, Headings, or Words, with additional sub-levels of body,
n, osisID, type (and others) for Footnotes. Type can be
crossReference, translation, count. I would suggest a new footnote
type of "audio", and the other attributes be used to store the other
information like the filename, etc. Then the filters would essentially
ignore these footnotes. The frontend would determine if a module
supported audio by a .conf entry, and use the Entry Attributes to
determine which file to play. In Xiphos, I would expect that our
current "Read Aloud" functionality would simply be extended to play
from the audio files if available.

Matthew