On Wed, Aug 25, 2010 at 8:20 AM, Karl Kleinpaste <[email protected]> wrote: > > Chris Little <[email protected]> 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 _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
