Re: [sword-devel] Linked in audio files
On 8/24/2010 2:10 PM, Karl Kleinpaste wrote: Matthew Talbertransom1...@gmail.com writes: I thought of that. But images have a separate tag (figure, I think) OSISfigure, ThMLimg. 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. a generica does not exist, does it? Only in ThML, I'm pretty sure. It's easy enough to check: http://www.crosswire.org/osis/schemas/osisCore.2.1.1.xsd.html OSIS does have a, with more or less standard semantics. (It supports the href attribute, but not name). But I'd recommend using a only if you want to link to an external page/object (e.g. you want to force front ends to launch an external player). I think front ends ought to have the flexibility to play audio in-line, such as by rendering the OSIS figure as HTML5 audio. I think the standard way of implementing audio Bibles is to chop the text into chapter-sized chunks/files and have verses indicate indexes into the chapter files. So if verse 10 is 15 seconds into the chapter audio, playing verse 10 will start at +15 seconds and continue to the end of the chapter. I'm not saying that couldn't be improved on, just that that's what I've seen done. --Chris ___ 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
Re: [sword-devel] Linked in audio files
Von: Chris Little chris...@crosswire.org OSIS does have a, with more or less standard semantics. (It supports the href attribute, but not name). But I'd recommend using a only if you want to link to an external page/object (e.g. you want to force front ends to launch an external player). I think front ends ought to have the flexibility to play audio in-line, such as by rendering the OSIS figure as HTML5 audio. I think the standard way of implementing audio Bibles is to chop the text into chapter-sized chunks/files and have verses indicate indexes into the chapter files. So if verse 10 is 15 seconds into the chapter audio, playing verse 10 will start at +15 seconds and continue to the end of the chapter. I'm not saying that couldn't be improved on, just that that's what I've seen done. Thanks, this is very helpful Chris. I guess figure it is then. I guess this will run past the filters too, so frontends can use it or ignore it as they wish. re offsetting - is there any real concern that any modern implementation of a media player can not deal with offset? How would we code the offset? re format - I do see the concerns re patents etc, but does this really affect anyone who distributes e.g. mp3 files? I would think the problem is not with files but with players. And as we would use only build-in players (either via rendering engine or external) it is also of no real concern to us either, is it? Mind you, as a non-American I find the matter more quaint then concerning as these things (software patents) do not apply here really. So, anyway, I would suggest that we allow - just as with images - a variety of file types and just hope for (gradual) expansion of any deficient media players (here mp3, ogg and aac) - and steer confused souls towards ogg. . I would guess as long as people are sensible we will not have to deal with really strange codecs anyway. People like those lot who insist on producing RTF marked up modules will not listen anyway - even if we tell them that we do not support x,y or z. But it works on frontend ! Peter -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ 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
Re: [sword-devel] Linked in audio files
So, anyway, I would suggest that we allow - just as with images - a variety of file types and just hope for (gradual) expansion of any deficient media players (here mp3, ogg and aac) - and steer confused souls towards ogg. I ask that we don't favour (or even use) ogg vorbis (FYI, ogg is a container format, vorbis is the audio format codec). I'm going to completely ignore any arguments that could be made for or against the idea that it is patent free or infringes on patents, and I'll instead look to the fact that Apple and others have decided that it's iffy and not worth the risk hence there is no native built-in decoder available in iOS (iPhone/iPad/iPod touch) for it. Hence, for it to work nicely in PocketSword without me having to include my own sound decoder, I'd prefer mp3 or aac. Thanks, ybic nic... :) Nic Carter PocketSword Developer - an iPhone Bible Study app www: http://crosswire.org/pocketsword iTunes: http://itunes.apple.com/app/Pocketsword/id341046078 Twitter: http://twitter.com/pocketsword ___ 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
Re: [sword-devel] Android SWORD
Hi Ken, You can find and-bible source and builds here: http://code.google.com/p/and-bible/ Take a look and then contact me again later if you want or you could develop Bishop if you prefer. Best regards Martin On 25 August 2010 00:01, Kenneth Arnold kenneth.arn...@gmail.com wrote: I just got an Android phone, and after seeing the state of Bible software currently available, I'm excited about helping develop a good SWORD-powered Bible reader for it. I installed Troy's bishop2.apk and tried to download a module... fail (logcat at end of message). So I went looking for the code to see if I could track down the problem... but I haven't found any source code anywhere. Is that intentional, or am I missing something? As a user (previously of Laridian on WinMo), I've made this list of requirements for a Bible reader: - local storage - fast navigation UI (Laridian had specialized T9 for book names. You could get most anywhere in the Bible in about 6 keypresses.) - continuous scrolling (across chapter divisions) - cross references and footnotes - word/phrase search (perhaps fuzzy?) optional features: - scripture memory helper (I have a lot of concrete ideas here) - finding related resources (e.g., sermons) from selected resources - daily reading (or at least what's next after things I've read recently?) - screen orientation lock - song lyrics - history tracking (what passages did I look up while studying yesterday?), perhaps communally (what books have my friends been reading?) Any other interest in helping out? How can we organize a team? Martin, if you're still listening, I'd love to check out your code too. -Ken PS - here's the `adb logcat` from a failed module download. Turns out it succeeds if you create a 'modules' directory inside /sdcard/sword :) -- but then there are plenty of other issues. 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: sourceName: CrossWire 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: modName: ESV 08-24 23:19:46.443 2002 2021 D libsword.so: * InstallMgr::installModule 08-24 23:19:46.443 2002 2021 D libsword.so: * modName: ESV 08-24 23:19:47.286 2002 2021 D libsword.so: * mgr.prefixPath: /sdcard/sword/InstallMgr/20081216195754/ 08-24 23:19:47.286 2002 2021 D libsword.so: * destMgr-prefixPath: /sdcard/sword/ 08-24 23:19:47.286 2002 2021 D libsword.so: * absolutePath: /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: * relativePath: modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: netCopy: ftp.crosswire.org, modules/texts/ztext/esv/, /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/, t, 08-24 23:19:47.341 2002 2021 W System.err: Problem installing: -1 08-24 23:19:47.396 2002 2002 D libsword.so: getModInfoList returning 0 length array On Sun, Jun 13, 2010 at 4:30 AM, Martin Denham mjden...@gmail.com wrote: Hi Troy, Apologies, I was a bit confused regarding the different projects. The above was my first post to *Sword forums. I incorrectly thought that JSword, Sword and other Crosswire forums would be worked on by the same people. I have now joined the JSword-dev list which I had not spotted before. Whether the back end is built based on Sword or JSword it might be worthwhile combining with the Java Jsword guys for the front end which I think has to be in Java. I may download your apk and try it out. I can put my code/build somewhere if you want but it's still in a state of great flux. Kind regards Martin On 13 June 2010 04:54, Troy A. Griffitts scr...@crosswire.org wrote: Martin, Great news on your success of getting JSword to build on Android. I'm sure the JSword mailing list would be interested to hear about your success! I'm not sure about the speed. I will add a primitive search box to my test app and let you know how long a complete search of the KJV (a heavily marked up Bible) takes on my G1. Troy. On 06/09/2010 05:28 AM, mjdenham wrote: Hi Troy, I just thought I would mention that I have also been playing around with Android. I have spent the last few weeks creating a prototype bible viewer application for Android, but I just noticed Troy's messages in this forum. I took a slightly different technical approach to you and I don't know which is better and I also came at this project with the aim of creating a mobile bible viewer I could tweak and improve rather than specifically to write an Android front end for Sword. By way of information I thought I would outline my approach and what led me to start. I have used Pocket e-Sword for many years but development has now ceased on Pocket e-Sword and it is already looking a bit old, as is WinMob that it runs on, so I started thinking what to use in the future. Although I loved
Re: [sword-devel] Linked in audio files
Chris Little chris...@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. ___ 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
Re: [sword-devel] Linked in audio files
On Wed, Aug 25, 2010 at 8:20 AM, Karl Kleinpaste k...@kleinpaste.org wrote: Chris Little chris...@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 ___ 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
Re: [sword-devel] Linked in audio files
Karl Kleinpaste k...@kleinpaste.org writes: 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 It occurs to me as well that simply adding a standard there's audio here image file to spackle _alongside_ the existing tag... a href=showImageimg file=audio-is-here.pngimg file=foo.mp3/a ...will have bad visual side effects because any HTML renderer will still try to interpret foo.mp3 badly, resulting in a typical a broken picture was here display in the output. This means that the filter-supplied img reference must be removed entirely to prevent this bad visual. So the further hackery done to this content would have to replace entirely the filter-supplied img, instead spackling in a total replacement reference, which (just thinking of possibilities off the top of my head) would probably be of the form... img file=audio-is-here.png audio=foo.mp3 start=... stop=... ...which again means that [a] the application must post-hack the filter output severely, [b] we are overloading img in ways we should not, [c] we are extending the qualifiers on img, and [d] neither the filters nor any apps are anywhere near being able to handle any of this because there is no way at this time to carry the audio=... qualifier into the showImage by which the app actually interprets the need for display. This is wrong. Creating a new audio tag (or something similar) that gets wrapped in something like a href=passagestudy.jsp?action=playAudio... would let this happen in much more consistent, standard, and reliable ways. ___ 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
Re: [sword-devel] Linked in audio files
Am 25.08.10 13:41, schrieb Karl Kleinpaste: Karl Kleinpaste k...@kleinpaste.org writes: 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 It occurs to me as well that simply adding a standard there's audio here image file to spackle _alongside_ the existing tag... a href=showImageimg file=audio-is-here.pngimg file=foo.mp3/a ...will have bad visual side effects because any HTML renderer will still try to interpret foo.mp3 badly, resulting in a typical a broken picture was here display in the output. This means that the filter-supplied img reference must be removed entirely to prevent this bad visual. So the further hackery done to this content would have to replace entirely the filter-supplied img, instead spackling in a total replacement reference, which (just thinking of possibilities off the top of my head) would probably be of the form... img file=audio-is-here.png audio=foo.mp3 start=... stop=... ...which again means that [a] the application must post-hack the filter output severely, [b] we are overloading img in ways we should not, [c] we are extending the qualifiers on img, and [d] neither the filters nor any apps are anywhere near being able to handle any of this because there is no way at this time to carry the audio=... qualifier into the showImage by which the app actually interprets the need for display. This is wrong. Creating a new audio tag (or something similar) that gets wrapped in something like a href=passagestudy.jsp?action=playAudio... would let this happen in much more consistent, standard, and reliable ways. I don't have the full overview of what the filters do or render exactly but I generally agree here. Using the img tag for audio content would just be a bad hack. This audio stuff I believe has the potential to get quite popular. It would be worth creating a proper specification for this kind of content. Manfred ___ 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
[sword-devel] Launchpad: libsword - sword
FYI Launchpad.net project name for sword has been changed from libsword to sword. Libsword has been kept as an alias. From now on you can use: https://launchpad.net/sword - to access project pages $ bzr branch lp:sword - to get bzr branch of the svn trunk import NB NB sword does not use launchpad for upstream development NB It is used primarly for debian/ubuntu packaging of sword, and to provide automatic bzr mirror of the svn code repository. Anyone can branch and publish their personal branches of sword on launchpad. Similar abuse of launchpad is done by xiphos, bibletime bibledit. For more information about launchpad and ways it can be used for sword related development, you can contact pkg-crosswire-devel debian packaging team. ___ 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
Re: [sword-devel] Linked in audio files
On 26/08/10 01:00, Manfred Bergmann wrote: Creating a newaudio tag (or something similar) that gets wrapped in something likea href=passagestudy.jsp?action=playAudio... would let this happen in much more consistent, standard, and reliable ways. I don't have the full overview of what the filters do or render exactly but I generally agree here. Using theimg tag for audio content would just be a bad hack. This audio stuff I believe has the potential to get quite popular. It would be worth creating a proper specification for this kind of content. And don't forget, next year everyone will be clamouring after video as well. Might as well think the issue through properly now. Robert. ___ 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
Re: [sword-devel] Linked in audio files
Indeed, for example, Bible translations done for deaf people in sign language are done in video as the primary medium. On Wed, Aug 25, 2010 at 1:02 PM, Robert Hunt hunt.robe...@gmail.com wrote: On 26/08/10 01:00, Manfred Bergmann wrote: Creating a newaudio tag (or something similar) that gets wrapped in something likea href=passagestudy.jsp?action=playAudio... would let this happen in much more consistent, standard, and reliable ways. I don't have the full overview of what the filters do or render exactly but I generally agree here. Using theimg tag for audio content would just be a bad hack. This audio stuff I believe has the potential to get quite popular. It would be worth creating a proper specification for this kind of content. And don't forget, next year everyone will be clamouring after video as well. Might as well think the issue through properly now. Robert. ___ 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 -- Weston Ruter http://weston.ruter.net/ @westonruter http://twitter.com/westonruter - Google Profilehttp://www.google.com/profiles/WestonRuter#about ___ 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
Re: [sword-devel] Linked in audio files
On 8/25/2010 5:20 AM, Karl Kleinpaste wrote: Chris Littlechris...@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 HTMLimg element ina 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. No, there is nothing specifically image-oriented about the figure element. That Sword filters always interpret it as an image is irrelevant to my point. Moving forward, we can mandate that (for Sword) non-image data embedded with figure be tagged with an attribute (e.g. type=x-audio) or we can add the tag ourselves in the importer by reading filename extensions. Then the OSISHTMLHREF filter can watch for type=x-audio and generate audio or whatever (depending on whether we're targeting HTML5 or something else). --Chris ___ 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
Re: [sword-devel] Android SWORD
Dear Ken, Thank you for the debug. I also have had trouble with the installer and haven't had time to look into it. The history is that I build Bishop as a sort of proof of concept for the java-jni bindings for Android. I mostly work in the engine code. The jni binding code I kept in SWORD SVN and the Bishop code I just backed up occasionally to our server. Last year my drive crashed and I lost some work but might have pieced it all back together. Here is an email I sent to Gary with links to all my stuff. __ After last year when I started the work I had a harddrive die on my laptop. I had been backing up the work regularly, but lost about 2 weeks of work in the crash. I used a recovery tool to salvage many of the files from the bishop project and think I may have close to what is in the apk. Here are my resources if you want to try to piece things together: Lastest binary when I stopped, dated 11-18-2009: http://crosswire.org/~scribe/bishop.apk Latest backup of source, dated 10-31-2009: http://crosswire.org/~scribe/bishop-20091031.tar.gz Latest binary after reconstructing source and I think some small new work (I think this is built with debug symbols in the native library so it's a little bigger): http://crosswire.org/~scribe/bishop2.apk Current backup of source which built the above: http://crosswire.org/~scribe/bishop-20100804.tar.gz Please excuse my ignorance of Android programming. I am fumbling through it all. I remember having trouble with the InstallMgr. It sometimes connects and downloads and other times it does not. I thought it might be the limited memory on my G1 or some trouble with the timing of the FTP code in the native library. I've found serious bugs in Android's system calls, (e.g. memccpy) and reported it to them, but they still haven't fixed it. I use my own version in the ftp lib to avoid the bug. That is where I stopped-- thinking I needed to debug this ftp intermittent issue. I didn't compare how well the older .apk works versus the newer .apk. Maybe the older version worked better? Or maybe a newer version of Android or new phone works better? Let me know what you find. Troy On 08/24/2010 09:01 PM, Kenneth Arnold wrote: I just got an Android phone, and after seeing the state of Bible software currently available, I'm excited about helping develop a good SWORD-powered Bible reader for it. I installed Troy's bishop2.apk and tried to download a module... fail (logcat at end of message). So I went looking for the code to see if I could track down the problem... but I haven't found any source code anywhere. Is that intentional, or am I missing something? As a user (previously of Laridian on WinMo), I've made this list of requirements for a Bible reader: - local storage - fast navigation UI (Laridian had specialized T9 for book names. You could get most anywhere in the Bible in about 6 keypresses.) - continuous scrolling (across chapter divisions) - cross references and footnotes - word/phrase search (perhaps fuzzy?) optional features: - scripture memory helper (I have a lot of concrete ideas here) - finding related resources (e.g., sermons) from selected resources - daily reading (or at least what's next after things I've read recently?) - screen orientation lock - song lyrics - history tracking (what passages did I look up while studying yesterday?), perhaps communally (what books have my friends been reading?) Any other interest in helping out? How can we organize a team? Martin, if you're still listening, I'd love to check out your code too. -Ken PS - here's the `adb logcat` from a failed module download. Turns out it succeeds if you create a 'modules' directory inside /sdcard/sword :) -- but then there are plenty of other issues. 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: sourceName: CrossWire 08-24 23:19:46.443 2002 2021 D libsword.so: remoteInstallModule: modName: ESV 08-24 23:19:46.443 2002 2021 D libsword.so: * InstallMgr::installModule 08-24 23:19:46.443 2002 2021 D libsword.so: * modName: ESV 08-24 23:19:47.286 2002 2021 D libsword.so: * mgr.prefixPath: /sdcard/sword/InstallMgr/20081216195754/ 08-24 23:19:47.286 2002 2021 D libsword.so: * destMgr-prefixPath: /sdcard/sword/ 08-24 23:19:47.286 2002 2021 D libsword.so: * absolutePath: /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: * relativePath: modules/texts/ztext/esv/ 08-24 23:19:47.286 2002 2021 D libsword.so: netCopy: ftp.crosswire.org, modules/texts/ztext/esv/, /sdcard/sword/InstallMgr/20081216195754/modules/texts/ztext/esv/, t, 08-24 23:19:47.341 2002 2021 W System.err: Problem installing: -1 08-24 23:19:47.396 2002 2002 D libsword.so: getModInfoList returning 0 length array On Sun, Jun 13, 2010 at 4:30 AM, Martin Denham mjden...@gmail.com wrote: Hi Troy, Apologies, I
