Tech Forum Archive

Open Source Digital Talking Book Player

78 postsstarted by cannona-p40 31,895 viewsoriginal topic

cannona-p40
Member
#1
Hi all.

I have been working at the Church for about three and a half months. During that time, my primary focus has been accessibility; making our sites more accessible, and improving our services to persons with disabilities, especially the print-disabled. One particular technology I have encouraged the Church to adopt is the Digital Accessible Information System, or DAISY for short.

DAISY is an XML based open ANSI approved standard for creating digital talking books. It has gained broad support in the print disabled communities and most agencies that produce books for the Blind have either already switched to the format or are in the process of doing so.

Currently, the Church records the Ensign, New Era, Friend, as well as most of our other major publications for the blind. These recordings are currently being distributed on cassette, but they are recorded at half-speed and we utilize all four tracks of the cassette separatly. This results in being able to fit about 6 hours on a single 90 minute cassette.

The reasons I believe that DAISY would be a good move for the Church are many. First, as mentioned above, it is for all intents and purposes an industry standard. On the other hand, the 4-track format is being supported less and less. Because it is based upon cassettes, and since cassettes are becoming rather scarce in general, the cost of the players and media continues to rise.

Another reason is that the DAISY format is much more flexible than the old 4-track standard. Properly created DAISY books allow the reader to quickly and easily jump from section to section, chapter to chapter, page to page, and even paragraph to paragraph. (As you might imagine, this especially makes a huge difference for the scriptures.) The user can either listen to the book being read by a human reader, or read the text on the screen. The user can add book marks, tell the player to automatically read or skip footnotes, and search for text, among other things. In comparison to cassettes, where the only navigation available was rewind and fast-forward, the increase in functionality is huge. In fact, many books which would not have been practical to produce on cassette, like the Topical Guide or Bible Dictionary, can now be made available Through DAISY

Finally, because the format is open, it doesn't require too much alteration to our existing processes to implement. The audio portion of the book is typically encoded in the MP3 format, which we are already producing for lds.org, and we use XML in our publication process, so the text can be easily incorporated.

So far, I have received an enormous amount of support for this proposal, but we still have a ways to go before we can begin to make a public release. Still, I am very optimistic.

The only area about which I have some concern regards the availability of playback devices. The least expensive hardware player sells for about $200, and a software player can be had for $50. Unfortunately, at this time, no good freeware players exist. However, the news in this regard is not all bad. The National Library Service for the Blind and Physically Handicapped, a division of the Library of Congress, has adopted DAISY, and so all eligible persons in the United States will soon be able to borrow a DAISY player at no cost. Also, because the format is based on mp3 files, the books will be able to be played in a standard MP3 player, although they will lack many advanced features when played in this manner.

However, this is not really a new issue. The 4-track format also requires a special player, and unlike Daisy, there is no less functional alternative. So, I believe that over all, more people will have access to DAISY than had access to the 4-track standard. Still, the accessibility to DAISY could be better, which brings me to my reason for posting.

I am wondering if there is anyone who would be interested in working on an open source DAISY player? I think it would be nice if we could have a solid freeware player to distribute with our DAISY titles. This is how I envision such a player working:

After the application was installed on the users machine, it would check to see if an internet connection was available. If one was, it would display to the user a library of content. This would include all the books, magazines, pamphlets, ETC. that we make available in DAISY. They could pick the titles they were interested in and they would be automagically downloaded, unzipped, and installed in their local library by the program in the background. If they chose a magazine, the
program would give them the choice of downloading just that issue, or subscribing to that publication. If they subscribed, new issues would be automatically downloaded on program startup, or optionally, we could have the program check in the background on system startup.

If the user did not have an internet connection, they could still load books from CD or their local hard drive.

Once the book was downloaded from the internet or otherwise loaded, the user could browse the table of contents, jump from paragraph to paragraph, and everything
else a good Daisy player supports. It would also show the text of the book in sync with the audio. There would be controls for enlarging the text, changing the color and contrast, and anything else that might help a partially sighted user. For the totally blind person with no screenreader, the application
under windows could easily be made self voicing with the Microsoft Speech Engine. It may also be possible to do something similar under the Mac as well.

Other possible features could include:
Ability to slow down or speed up the audio (a commonly requested feature in DAISY players).
Ability to begin listening to books as they are being downloaded.
Support for skippable content
advanced text searching
ETC.

I thought that the best language for this project would probably be Python. Python generally requires less development time than some other languages, it has broad cross-platform support, and although it is an interpreted language, there are ways to create native windows executables that are not too large. Also, I happen to know Python, so that is also a plus. :)

I considered Java, like the Family History Dept. uses for the Family Search Indexing app, but that requires either the user to have the right JRE installed, or that they have an internet connection. Neither is a supposition I feel we can safely make. Java also has a bad record when it comes to playing nice with screen readers, although that can usually be alleviated by some smart programming.

Anyway, those are my thoughts. I'm very much interested in people's feedback on this, and in finding out how many folks would be interested in helping out with development.

Thanks

Aaron Cannon
russellhltn
Community Administrator
#2
Sounds like a great project!

Another thing against Java is that they seem to have frequent security updates and the updates don't remove the old non-secure version.

Would anything special need to be done to support Braille devices?

Going back to what you are envisioning, I'd see it as something that could be "flavored" to go to the initial download. For example, since you would be downloading it from the lds.org site, it would go back to that site to find content on install. But another group could do the same thing to have it go to their site.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
mkmurray
Senior Member
#3
I think this would be a great project to start. It could be hosted on a site like SourceForge, like a few of the other project ideas that have jumped from this site to a real open-source hosting site.

I googled a little about DAISY and found thier official site: http://www.daisy.org/.

Out of curiosity, which standard(s) would you support? the 2005? the 2.02?

http://www.daisy.org/z3986/specifications/default.asp
russellhltn
Community Administrator
#4
2005 is the current standard. The 2.02 is the old one. But would the church need to publish to the old standard to accommodate the most players?

Another question: what is the standard computer interface for blind users? The reason I ask is I'd assume that most programmers on this project would be sighted will little experience in coding or even using products aimed at the blind. That creates some user interface issues.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
JamesAnderson
Senior Member
#5
This will do alot of good.

One other thing, since the files would be in mp3 format, would one also be able to download them for use on anything that otherwise would play mp3 files? That way even if one was not disabled but wanted the same content, they could grab that off the site and listen to it, just like any other mp3 file now published by the Church and others, albeit without the special/enhanced features that using a DAISY player would bring.
mkmurray
Senior Member
#6
RussellHltn wrote:But would the church need to publish to the old standard to accommodate the most players?
It appears to me that this isn't really a Church project (not yet at least). It is just an open-source project idea proposed by a Church employee at this point.

So I guess the developers on the project can make that decision to support older specifications if they want.
WelchTC
Senior Member
#7
One comment in favor of Java is the platform independence. Building in Python still requires you to call specific platform GUI calls. However, I love the idea. Who wants to participate?

Tom
gkearney-p40
New Member
#8

Daisy

This is Greg Kearney from the Wyoming Medical Center in Casper. I've done a fair amount of work in the area of DAISY production, I have produced versions of the scriptures with navigation to the verse, the Koran and so on. I have developed open source production software for the Apple Macintosh platform see http://w3.wmcnet.org/dtbmaker/

I'm also a member of the DAISY Consortium and a dyslexic user of DAISY.

A good DAISY playback software that is cross platform is a really important item to have. It should be able to play all three of the daisy standards 2.02, 2002 (this is the format being used by the Library of Congress) and 2005. 2.02 has the advantage of being able to be played on every hardware and software player ever made.

As for braille that is a function of either the screen reader or, in the case of the Mac the operating system.

Greg Kearney
gkearney-p40
New Member
#9
RussellHltn wrote:2005 is the current standard. The 2.02 is the old one. But would the church need to publish to the old standard to accommodate the most players?

Another question: what is the standard computer interface for blind users? The reason I ask is I'd assume that most programmers on this project would be sighted will little experience in coding or even using products aimed at the blind. That creates some user interface issues.
There is no such thing as a standard interface fro the blind. In windows there are two major and several minor screen readers which permit the blind to interact with the visual elements on the screen. These are expensive add on programs which often cost more than the computer itself. It is why many software based DAISY playback tools are self voicing.

On Macintosh computer the screen reader is part of the OS and if the program's interface is written in Cocoa. as most modern programs are, it can be accessed by the built in screen reader called VoiceOver.

Linux screen readers are still in the development stage but Ubuntu has ORCA which seems to work with most applications.
gkearney-p40
New Member
#10
JamesAnderson wrote:This will do alot of good.

One other thing, since the files would be in mp3 format, would one also be able to download them for use on anything that otherwise would play mp3 files? That way even if one was not disabled but wanted the same content, they could grab that off the site and listen to it, just like any other mp3 file now published by the Church and others, albeit without the special/enhanced features that using a DAISY player would bring.
Yes provided care is taken to keep the audio file on the same file level as the DAISY files and that the filenames are keep in playable order so that the book is played back in the right order. My production software always keeps the audio in the correct playable order and so the books can be played in standard MP3 players. I also have tools that convert DAISY to iPod audio book format.
gkearney-p40
New Member
#11
tomw wrote:One comment in favor of Java is the platform independence. Building in Python still requires you to call specific platform GUI calls. However, I love the idea. Who wants to participate?

Tom
An issue with Java is ensuring that the GUI can be accessed by all the various screen readers used by the blind and disabled. Take it from someone who has tried to interact with some of the Church's Java software with the Mac screen reader not all is well and programmers seldom give thought to how people who can not see the screen will use their software. Take, as an example, this reply to my concern about visual only input on new.familysearch.org:

Dear Greg,
Thank you for your concern. You are correct. Those that have vision problems will have to have the assistance of a sighted person to sign up. If the patron is unable get assistance from anyone, they are welcome to call support and we will work with them to help them sign in.

Sincerely,
FamilySearch Support
MEM
<CaseID:458576>

gkearney@gmail.com 8/25/2007 4:55:42 PM >>>
Subject: Picture text and the blind

Given that the sign in requires a membership number and date is the
picture text really needed? What are the chances that an automated
script could guess both?

Such pictures make it impossible for the blind to sign up without
sighted help.

Greg Kearney
Casper, Wyoming


----------------------
<CaseID:458576>
----------------------


So even though there is no good reason to even have the check, no automated system would ever be able to guess both a file number and a date correctly, the answer was basically tough, go get sighted help.

Greg
cannona-p40
Member
#12
RussellHltn wrote: Would anything special need to be done to support Braille devices?

Daisy supports synchronizing Braille with the text and audio, though no players support this, that I know of. However, if we are designing the player, then there's no reason why such functionality couldn't be added.

The only problem I see is that Braille is only produced for a few of our publications. But, if there were enough demand...
RussellHltn wrote: Going back to what you are envisioning, I'd see it as something that could be "flavored" to go to the initial download. For example, since you would be downloading it from the lds.org site, it would go back to that site to find content on install. But another group could do the same thing to have it go to their site.

This is also something that I've thought about. Of course, if enough organizations began offering feeds of their DAISY content, then it might also make sense to give the user the ability to add additional locations to their library.
mkmurray wrote: Out of curiosity, which standard(s) would you support? the 2005? the 2.02?

Currently, we are creating books in the 2002 format. The format changed significantly from version 2.02 to 2002, but the differences between 2002 and 2005 are not that great. The 2005 format just added some specialized features that we probably won't need.
Still, I would eventually like to have it support all formats, but Daisy 2002 would be a good start.

Nearly all of the hardware players can support the 2002 standard, although some of the older models may need to have their firmware updated.
RussellHltn wrote: Another question: what is the standard computer interface for blind users? The reason I ask is I'd assume that most programmers on this project would be sighted will little experience in coding or even using products aimed at the blind. That creates some user interface issues.

Most blind computer users (though not all) are using Windows with a screen reader. Some also have Braille displays. Other than that, our computers are generally no different.
Creating interfaces for the blind or folks with low vision should not be too much different than creating one for a sighted user. If one is careful to use standard windows controls (as aposed to nonstandard controls that are used by some cross platform gui kits), and if the developer makes sure that all controls have text associated with them and are accessible via the keyboard, then there really shouldn't be any problem.

Under Python, the best answer I have found is the WxPython toolkit. This is cross platform, but it also utilizes the standard windows GUI controls.

I plan on being as involved as possible with the development of the interface, to make sure that this doesn't become an issue. Even though I would like us to make the interface self-voicing, I would also like to make it work well with screen readers, because most screenreader users would rather use their screenreader to get access to the screen. (Sorry for the tongue twister.)
JamesAnderson wrote: One other thing, since the files would be in mp3 format, would one also be able to download them for use on anything that otherwise would play mp3 files? That way even if one was not disabled but wanted the same content, they could grab that off the site and listen to it, just like any other mp3 file now published by the Church and others, albeit without the special/enhanced features that using a DAISY player would bring.

Yes. I have been quite careful when creating our DAISY books to name the files in such a way that they should play in order on any device that sorts its playlist by file name.

The only difference between a bunch of MP3s and a DAISY book is that a DAISY book has three or four extra XML files in the directory. I assume that most players worth anything should just ignore any file they don't recognize.
tomw wrote:One comment in favor of Java is the platform independence. Building in Python still requires you to call specific platform GUI calls. However, I love the idea. Who wants to participate?

Tom

I believe that the WXPython package mentioned above takes care of this. You use the WXPython interface, and it figures out which API to interact with based on the OS. I believe in Geek Speak this would be refered to as an abstraction layer.

Finally, I have been working on a class that will parse the XML data into a nice data structure. Up until this morning, it was all pseudo-code, but it seems to be coming together nicely. It's not much, but it's a start.

Aaron
kalebpederson
New Member
#13
cannona wrote:
...snip...

Under Python, the best answer I have found is the WxPython toolkit. This is cross platform, but it also utilizes the standard windows GUI controls.

...snip...

I plan on being as involved as possible with the development of the interface, to make sure that this doesn't become an issue. Even though I would like us to make the interface self-voicing, I would also like to make it work well with screen readers, because most screenreader users would rather use their screenreader to get access to the screen. (Sorry for the tongue twister.)

... snip ...

I believe that the WXPython package mentioned above takes care of this. You use the WXPython interface, and it figures out which API to interact with based on the OS. I believe in Geek Speak this would be refered to as an abstraction layer.

Finally, I have been working on a class that will parse the XML data into a nice data structure. Up until this morning, it was all pseudo-code, but it seems to be coming together nicely. It's not much, but it's a start.

Aaron

Hey Aaron (et all),

I would strongly recommend that you go with PyQt (http://www.riverbankcomputing.co.uk/pyqt/index.php). eg. The Python bindings to Qt. Qt (http://trolltech.com/products/qt) is a great toolkit that uses native widgets on almost every imaginable platform. Linux, Solaris, Windows, Mac, etc. They have an open source version that doesn't cost anything and a free IDE is provided as a part of the Windows Download (and you can get the packages separately for Linux/Macintosh if you want).

If you didn't want to use Python, you could use the native C++ interface, or you could use QtJambi, the Open Source Java bindings for the language.

To give you an idea of the quality of apps that are developed with it, both Google Earth and Adobe Photoshop Elements are written with Qt, as is KDE and many Linux/Unix based applications.

Qt is well designed (see http://doc.trolltech.com/4.3/index.html), well supported, and open source... you couldn't ask for much more than that. Given the commercial nature of it, it also has many accessiblity features that would be important given the target audience.

Sorry if I sound a bit like a salesman -- I develop commercial applications with it ... and still love it. I would gladly help out if it were to be written with Qt (no learning curve sure helps :)), and could mock up interfaces really quickly with a good set of specs.

--kpederson
gkearney-p40
New Member
#14
kpederson wrote:Hey Aaron (et all),

I would strongly recommend that you go with PyQt (http://www.riverbankcomputing.co.uk/pyqt/index.php). eg. The Python bindings to Qt. Qt (http://trolltech.com/products/qt) is a great toolkit that uses native widgets on almost every imaginable platform. Linux, Solaris, Windows, Mac, etc. They have an open source version that doesn't cost anything and a free IDE is provided as a part of the Windows Download (and you can get the packages separately for Linux/Macintosh if you want).

If you didn't want to use Python, you could use the native C++ interface, or you could use QtJambi, the Open Source Java bindings for the language.

To give you an idea of the quality of apps that are developed with it, both Google Earth and Adobe Photoshop Elements are written with Qt, as is KDE and many Linux/Unix based applications.

Qt is well designed (see http://doc.trolltech.com/4.3/index.html), well supported, and open source... you couldn't ask for much more than that. Given the commercial nature of it, it also has many accessiblity features that would be important given the target audience.

Sorry if I sound a bit like a salesman -- I develop commercial applications with it ... and still love it. I would gladly help out if it were to be written with Qt (no learning curve sure helps :)), and could mock up interfaces really quickly with a good set of specs.

--kpederson
I would urge a very complete testing of any such toolkit to insure that it is compatible with the various screen readers on the various platforms. My experience with Jave shows that this is a very serious problem.

Greg
WelchTC
Senior Member
#15
I'm very familiar with QT as well. I was not aware that they have an open source version for Windows. However if they do, I would second a vote for QT and/or PyQT. While at Linspire, we developed two major apps using Python and PyQT.

Tom
The_Earl
Member
#16

QT Testing

gkearney wrote:I would urge a very complete testing of any such toolkit to insure that it is compatible with the various screen readers on the various platforms. My experience with Jave shows that this is a very serious problem.

Greg
I will add my voice in support of QT. We use it in our commercial apps as well.

I would think that QT would have good support for accessability. Many commercial apps require this.

As long as you don't stray outside the common UI widgets, I would think that most languages would work with a screen reader. It gets more complicated when programmers try to be 'clever'.

The Earl
cannona-p40
Member
#17
tomw wrote:I'm very familiar with QT as well. I was not aware that they have an open source version for Windows. However if they do, I would second a vote for QT and/or PyQT. While at Linspire, we developed two major apps using Python and PyQT.

Tom

I'm certainly not married to the idea of using WXPython, and if PyQT will work, then lets use it. I will do some testing today to make sure it will work with screenreaders, and I'll get back to you all. However, if it uses the native windows widgets, then there should be no problem.

Thanks!

Aaron
gkearney-p40
New Member
#18
cannona wrote:I'm certainly not married to the idea of using WXPython, and if PyQT will work, then lets use it. I will do some testing today to make sure it will work with screenreaders, and I'll get back to you all. However, if it uses the native windows widgets, then there should be no problem.

Thanks!

Aaron
Aaron I would be happy to test the Mac VocieOver compatibility of anything.

Greg
kalebpederson
New Member
#19

Qt, PyQt and QtJambi open sourced

tomw wrote:I'm very familiar with QT as well. I was not aware that they have an open source version for Windows. However if they do, I would second a vote for QT and/or PyQT. While at Linspire, we developed two major apps using Python and PyQT.

Tom
As of Qt-4.0, Qt was Open Sourced for Windows. When QtJambi, the Java bindings were released a while ago, they also released it under the same licensing.

By what I have heard, the next version of Qt, 4.4.X will add a lot more multimedia (audio/video) support, so that might even include all the support needed for the audio part of the project as well. Right now the audio support is quite limited.

--kpederson
cannona-p40
Member
#20
Well, I did some checking and it appears as though QT does not use native widgets. It only emulates them. I also downloaded and tried a couple QT apps just in case, and they were not accessible.

Aaron
WelchTC
Senior Member
#21
cannona wrote:Well, I did some checking and it appears as though QT does not use native widgets. It only emulates them. I also downloaded and tried a couple QT apps just in case, and they were not accessible.

Aaron
Aaron,

You said that java was a doable but could be problematic. Java does not use the windows widget set either. What makes Java work when QT does not work? Also, what will some of the new technologies coming from Microsoft such as silverlight do for screen readers?

Tom
thedqs
Community Moderators
#22
tomw wrote:One comment in favor of Java is the platform independence. Building in Python still requires you to call specific platform GUI calls. However, I love the idea. Who wants to participate?

Tom

One possibility is C# or another .NET language to keep the platform independence (through mono for Linux and Mac) and I believe it works with QT as well.
- David
cannona-p40
Member
#23
tomw wrote:Aaron,

You said that java was a doable but could be problematic. Java does not use the windows widget set either. What makes Java work when QT does not work? Also, what will some of the new technologies coming from Microsoft such as silverlight do for screen readers?

Tom

Hi Tom.

Java has something known as the Java Access Bridge that allows the screenreader to access the on screen information, but it is something that has to be enabled by the developer of the aplet, so you can imagine how often this gets done. I can't give much more details than that, as I've never learned Java.

I did some research on Silverlight and there isn't much word on its accessibility, though apparently some of the developers are at least giving it some thought. I suppose we'll see.

Aaron
kalebpederson
New Member
#24

Qt accessibility support

cannona wrote:Well, I did some checking and it appears as though QT does not use native widgets. It only emulates them. I also downloaded and tried a couple QT apps just in case, and they were not accessible.
Aaron
Qt does use native widgets and does support accessibility. Per the documentation, it provides "support for assistive tools such as screen readers and braille displays." It just doesn't come automatically, as it doesn't come automatically in all native windows apps either (AFAIK). Here is some documentation on how it's used:

http://doc.trolltech.com/4.3/accessible.html

And specifically:

http://doc.trolltech.com/4.3/accessible ... essibility

I've never tried it before, but it does sound like support is implemented for most built in widgets, but because it's a plugin based system, typically, it probably has to be compiled in. I'll take a look and see what I can find, but feel free to investigate more in the mean time. I would guess that we wouldn't need to do too much as you can often use custom widgets that are composed of builtin widgets, rather than implementing something from scratch... although both would work.

--kpederson
gkearney-p40
New Member
#25
kpederson wrote:Qt does use native widgets and does support accessibility. Per the documentation, it provides "support for assistive tools such as screen readers and braille displays." It just doesn't come automatically, as it doesn't come automatically in all native windows apps either (AFAIK). Here is some documentation on how it's used:

http://doc.trolltech.com/4.3/accessible.html

And specifically:

http://doc.trolltech.com/4.3/accessible ... essibility

I've never tried it before, but it does sound like support is implemented for most built in widgets, but because it's a plugin based system, typically, it probably has to be compiled in. I'll take a look and see what I can find, but feel free to investigate more in the mean time. I would guess that we wouldn't need to do too much as you can often use custom widgets that are composed of builtin widgets, rather than implementing something from scratch... although both would work.

--kpederson

I'm sorry to report that QT does not support VoiceOVer accessibility in the Macintosh platform. None of the controls are reachable items report as "unkonwn" window navigation does not work.

Greg
cannona-p40
Member
#26
kpederson wrote:Qt does use native widgets and does support accessibility. Per the documentation, it provides "support for assistive tools such as screen readers and braille displays." It just doesn't come automatically, as it doesn't come automatically in all native windows apps either (AFAIK). Here is some documentation on how it's used:

http://doc.trolltech.com/4.3/accessible.html

And specifically:

http://doc.trolltech.com/4.3/accessible ... essibility

I've never tried it before, but it does sound like support is implemented for most built in widgets, but because it's a plugin based system, typically, it probably has to be compiled in. I'll take a look and see what I can find, but feel free to investigate more in the mean time. I would guess that we wouldn't need to do too much as you can often use custom widgets that are composed of builtin widgets, rather than implementing something from scratch... although both would work.

--kpederson

Wow. I feel dumb. I never thought about just doing a search on accessibility and qt 4. Looks like you are right. This is very good news. It also looks like it supports accessibility on the mac as well.

Aaron
cannona-p40
Member
#27
gkearney wrote:I'm sorry to report that QT does not support VoiceOVer accessibility in the Macintosh platform. None of the controls are reachable items report as "unkonwn" window navigation does not work.

Greg

Hi Greg. Were you using an application with accessibility hooks? Based on the web page posted above, as well as a few others, QT claims to support accessibility on the Mac.
gkearney-p40
New Member
#28
I have no idea I just downloaded the open source QT and tired the samples, none worked. In the Cocoa environment things are accessible out of the box but there are thing u can do to improve the usage.
kalebpederson
New Member
#29

How to configure Qt to support accessibility

gkearney wrote:I have no idea I just downloaded the open source QT and tired the samples, none worked. In the Cocoa environment things are accessible out of the box but there are thing u can do to improve the usage.
I don't know exactly how it works, but the documentation indicates that it's purposefully a plugin system so that there is no performance penalty for standard users. I know that Qt does use Cocoa on Mac, I've just never had to go the accessibility route.

OK, I just figured it out. Try the following, assuming you're on Linux or Mac:

The accessibility plugin should be in:

$INSTALLDIR/plugins/accessible/libqtaccessiblewidgets.so

But, you also have to configure the examples to use the plugin, so go to the .pro file for the example that you want to try and add the following line near the top:

Code: 

QTPLUGIN      += qtaccessiblewidgets
Then re-run qmake and make. That will link the accessibility library in.

As long as the plugin is in your library path, it should work. Just to be sure:

Code: 

$ export LD_LIBRARY_PATH=$INSTALLDIR/plugins/accessible/libqtaccessiblewidgets.so
$ ldd ./yourExample | grep accessible
        libqtaccessiblewidgets.so => /usr/lib/qt4/plugins/accessible/libqtaccessiblewidgets.so (0xb7ec9000)
I also verified that the shared library was opened when running the example:

Code: 

# lsof | grep <pidOfMyProg> | grep accessible
mdi       19173   kibab  mem       REG        3,6    205524   12001561 /usr/lib/qt4/plugins/accessible/libqtaccessiblewidgets.so
I think this implies that any truly custom widgets (eg. any widget not composed of native widgets) would have to be written in C++, even if we were to use PyQt, but the above shared library works with all the builtin widgets, and the number of truly custom widgets is usually minimal (at least for the programs I have done).

Let me know how it goes.

--kpederson
cannona-p40
Member
#30
Well, I suppose it is safe to assume then that QT is the best option. I will continue to work on the classes to parse the XML. I'll also draw up an outline of the structure of the application and post that here.


Thanks.

Aaron
WelchTC
Senior Member
#31
This is very exciting! Should we host the project here on the LDS Tech web site or somewhere else like Source Forge? If we do it here, individuals would need to sign the Individual Contributors License Agreement before contributing in order to protect themselves and the Church. This agreement basically states that you as a contributor can hold the copyright to your code but that the Church receives a license to that contribution. This is the same agreement all members who want to help on any project sponsored or hosted by the Church would have to sign.

Tom
cannona-p40
Member
#32
tomw wrote:This is very exciting! Should we host the project here on the LDS Tech web site or somewhere else like Source Forge? If we do it here, individuals would need to sign the Individual Contributors License Agreement before contributing in order to protect themselves and the Church. This agreement basically states that you as a contributor can hold the copyright to your code but that the Church receives a license to that contribution. This is the same agreement all members who want to help on any project sponsored or hosted by the Church would have to sign.

Tom
Are there any other pros/cons to having the Church sponsor it Vs. just doing it on SF or another similar platform? If there is no compelling reason to have the Church sponsor it, I would say that SF would probably be the best option, as this project will be useful to many other groups and organizations besides the Church.

Aaron
thedqs
Community Moderators
#33
You can choose though since this is not church-specific I think that SourceForge would be the better option.
- David
mkmurray
Senior Member
#34
thedqs wrote:You can choose though since this is not church-specific I think that SourceForge would be the better option.
I agree for the most part. But we're also looking for people to have a reason to come to this site and participate. But that would be the only real argument for Chuch-hosted...
WelchTC
Senior Member
#35
cannona wrote:Are there any other pros/cons to having the Church sponsor it Vs. just doing it on SF or another similar platform? If there is no compelling reason to have the Church sponsor it, I would say that SF would probably be the best option, as this project will be useful to many other groups and organizations besides the Church.

Aaron
There are no REAL compelling reasons other than some visibility.

Tom
kalebpederson
New Member
#36

Qt XML classes

cannona wrote:Well, I suppose it is safe to assume then that QT is the best option. I will continue to work on the classes to parse the XML. I'll also draw up an outline of the structure of the application and post that here.
Sounds good. BTW, Qt does a have a set of simple XML classes. Basically readers, writers, SAX Parsers, and a couple of DOM based classes. They have great docs.

Let me know once the project is setup on SF or wherever else it's hosted. I'll gladly help with the initial project hierarchy, best practices, or in whatever other way I can.

--kpederson
gkearney-p40
New Member
#37
I vote to have it stay here. The good will that such a project could generate for the Church will be lost if it just goes over to SourceForge or some similar site.

Greg
thedqs
Community Moderators
#38
What is the "good" that would be lost if it goes over to SourceForge? Are you saying that people from the chruch will not use it? I doubt that since the church would just have to link to it. Is it for popularity of the tech site? Well that can be resolved just by putting a link back to this tech site from the sourceforge page that we are given. Would it be a loss in potential people coming to lds.org? I don't see how but I guess would could just recommend people to come to LDS.org from the sourceforge site. Maybe you have identified a part that I haven't taken in account and that would be great to know about.
- David
gkearney-p40
New Member
#39
First off having a reader will benefit the church as it converts from tape to DAISY format for it's material. I could picture distributing the reader with the books on CD for example. Like PAF it would help the church to have it's name attached to the only cross platform DAISY playback solution.
thedqs
Community Moderators
#40
Well I don't see how having a project on SourceForge prevents distribution of the sooftware by the church. Especially if the project has the correct licensing. And since it would be nice to get the greater open source community helping with the project I still see SourceFOrge as a better option then hosting it at LDS Tech.
- David
WelchTC
Senior Member
#41
Having the project hosted here would bring more attention to the Church's contribution to the project. Each time someone has to type in "tech.lds.org" they are reminded who is hosting the site. However others may be confused why a "church" is hosting this project. I was on the fence before but I'm starting to lean towards SourceForge. Regardless, we need more of a specification before we can begin.

Tom
cannona-p40
Member
#42
tomw wrote:Having the project hosted here would bring more attention to the Church's contribution to the project. Each time someone has to type in "tech.lds.org" they are reminded who is hosting the site. However others may be confused why a "church" is hosting this project. I was on the fence before but I'm starting to lean towards SourceForge. Regardless, we need more of a specification before we can begin.

Tom
Hi all.

Just a quick update. I haven't been able to work on this for the last couple of weeks due to some organizational decisions needing to be made concerning exactly who will be taking this project going forward.

I'll post more when I know more.

Thanks all for your interest and offers of help.

Sincerely
Aaron
thedqs
Community Moderators
#43
Thanks for allowing us to contribute ideas to the project.
- David
gkearney-p40
New Member
#44
Here are some goals which I think we should have for this project:

1. Core is cross platform that is Windows, Macintosh, Linux. I'm not particular to any language but I might suggest Perl. i'm not a big fan of Java. Seems to make a great deal of claims it never delivers on. Accessibility is hard to implement in it too. That said the Java app that the church did for census entry works well with Mac VoiceOver.

2. It should support Daisy 2.02 DIASY/INSO 2002 and DAISY/NISO 2005

3. Should support both text only, via TTS and text/audio books.

4. Should support RFB&D Audio+ format DAISY books

5. Should be able to access books stored on Web servers.

6. Should support display of and syncing to text/image when offered by the book by using system HTML/XML rendering.

7. Support for bookmarking, page number navigation and retaining a place in a book from one session to another.

That's all I can think of at the moment.
thedqs
Community Moderators
#45
Here is another thing, though I don't know how well it would work:
8. Should support annotations or highlighting.

The "highlighting" is just a annotation saying that this was highlighted and this is where the highlighting stops.
- David
cannona-p40
Member
#46
Here are my responses to the proposed functionality.

1. I believe the consensis is that it will be written in Python, which is cross platform.

2. Daisy 2002 will be supported for sure because that's what we will be releasing. The other standards would be nice, but probably shouldn't be an immediate priority.

3. I agree. It is possible that we may at some point release a book that is audio or text only, and the player should support either.

4. Nice, but not a priority. Also, I don't think they would appreciate having source code distributed which allows one to crack their DRM. :)

5. This is probably not a top priority, but I do agree that it is important. I think it is something that should be implemented shortly after we get the basic player built.

6. For sure. The more work we can pass off to the OS, the better.

7. See 5.

8. See 5.


On the other hand, this is open source, so ultimately what gets implemented will be up to the contributors.

I have been given the go-ahead to continue work on this project, so I will be posting more shortly.

Thanks!

Aaron
WelchTC
Senior Member
#47
cannona wrote:Here are my responses to the proposed functionality.

1. I believe the consensis is that it will be written in Python, which is cross platform.
Are you saying Python with the QT GUI or would this be a console based application?

Tom
cannona-p40
Member
#48
tomw wrote:Are you saying Python with the QT GUI or would this be a console based application?

Tom
With the QT GUI.
cannona-p40
Member
#49
What follows is a start at putting down some formal guidelines for the application. Input is of course welcome.


The following guidelines are just that, guidelines. They should not be considered unchangeable or complete. They are simply meant to get everyone on the same page, and jumpstart the discussion and coding.

Objective:

The overall goal of this project is to produce a cross platform open source application capable of playing the Daisy/Niso 2002 Digital Talking Books produced by the Church of Jesus Christ of Latter-Day Saints.

Specific goals:

The application should be accessible to users of screen reader or screen magnification software. It should also have the simplest and most intuitive interface possible while not sacrificing important functionality. The source code should be well documented and be written in such a way as to make the addition of functionality as simple as possible. The application should be self-voicing so that it may be used by individuals without screen readers. It should automate the locating and downloading of content as much as possible. Finally, the interface should be written in such a way as to support translation.

Sample application walk-through:

The typical user would either download this application from the Church's web site or receive it bundled on a CD with a Daisy book purchased from the Church Distribution Center. It would be packaged as a single executable for Windows, and in whatever format is the most intuitive for the other operating systems. The installation would be as brief and as painless as possible.

Once the application was opened, it would attempt to detect an internet connection. If one was available, it would automatically connect to the Church's server and download an XML file. This XML file would contain a list of all Daisy publications currently available. This list would be used to populate the library view.

The library view would contain at least two lists. The first would be a list of all the books currently on the users hard drive. (All books would be stored in a particular folder, with a subfolder for each book.) The other list would contain books that were available for download, and/or if a Daisy CD was inserted, from that CD. From the local list, the user would be able to select books to open or delete. From the external list, the user could select books to download. All downloads would take place in the background, but the user could view their status from the download status view.

The subscription view would show a list (also populated from the XML downloaded) of Magazines, general conference, First Presidency Messages, ETC. that the user could subscribe to. Each time the application started, it would check to see if the users subscriptions had been updated with new content. If they had been, it would add those items to the download queue.
(It might make more sense to combine the subscription and library views, as they are related.)

The player view would have standard controls such as play, pause, stop, skip back, skip forward, next section, previous section, next paragraph, previous paragraph, next sentence, previous sentence, next page, previous page, ETC. It would have a frame that would display the text and images from the book, assuming that the book included those. Finally, the frame would have the ability to scroll.

The contents view would show the table of contents of the book as a tree-view. The user could click on an entry to jump directly to that part of the book.

Naturally, all buttons, views, and features would be available from either the mouse or the keyboard, so that a person who is strictly limited to one or the other could still use the program.

Font color, style, and size, as well as background color would be fully customizable.

Finally, the application should optionally support the following features:

Playback of OGG, SPEEX, and any other audio format which is open and might be used in an audio book.

The ability to retrieve content feeds from other sources in addition to the Church.

A commandline interface.

Support for other Daisy standards, specifically Daisy 2.02 and Daisy/NISO 2005.

Ability to begin listening to books before they have completely downloaded.

Place restoration, bookmarking, annotation, ETC. (By place restoration, I mean that the player would remember where you left off reading, even if you haven't read that book for several weeks.)

Ability to speed up and slow down audio without changing the pitch.

Ability to skip certain types of content, such as footnotes and the like.

Ability to copy portions of text to the clipboard.


Brief explanation of Daisy:

A Daisy book consists of at least three XML files and 1 or more audio or image files. The .OPF file (an XML file) contains the metadata of the book and a manifest of all of the files that make up the book. The .NCX file contains the table of contents data stored as XML. Each element in the contents is linked to a specific part of the SMIL file. The .SMIL file (another XML based file) is really what ties it all together. It contains links to sections of mp3 files, portions of the text, and images. It tells the player in what order to play each and which items get played together. The .XML file contains the text of the book. This file is optional. It is referenced by the SMIL file.

The daisy standard supports synchronizing text down to the word level, but we will likely only be producing markup down to the paragraph level. It also supports skippable content. This allows users to optionally skip things they may not wish to hear, such as footnotes.
thedqs
Community Moderators
#50
Interesting, but just how are we going to be able to speed up or down without changing pitch. Or was that meaning to add/remove more space in silent regions?
- David
rmrichesjr
Community Moderators
#51
thedqs wrote:Interesting, but just how are we going to be able to speed up or down without changing pitch. Or was that meaning to add/remove more space in silent regions?
There are signal processing methods for shrinking or expanding speech independent of pitch changes. At least when I studied signal processing, speech was generally handled by chopping the time-domain stream up into slices of (IIRC) about 50ms in duration. Each slice can be converted to the frequency domain and/or processed in other ways. One fairly simple way to shrink or stretch time would be to convert each slice to the frequency domain, rescale the spectrum by interpolation/decimation, then convert back to the time domain. A really simple way to stretch time by 2X would be to play each slice twice. The spectrum and pitch would be unchanged, but the rate of time passage would be changed.
cannona-p40
Member
#52
I'm about ready to create a project on SF, but before I do so, does anyone have any good ideas for a name? The only completely unimaginative idea I was able to come up with is OpenDaisy.

Aaron
rmrichesjr
Community Moderators
#53
cannona wrote:I'm about ready to create a project on SF, but before I do so, does anyone have any good ideas for a name? The only completely unimaginative idea I was able to come up with is OpenDaisy.

Aaron
Is there a possibility that name might run into trademark-based legal problems?

(I'm not a lawyer, and I don't play one on TV.)
russellhltn
Community Administrator
#54
rmrichesjr wrote:Is there a possibility that name might run into trademark-based legal problems?

Valid point. I think it's quite possible that the DAISY Consortium who controls the Daisy specs or even Outerthought who makes the Daisy open-source content management system could complain.

Anyone know anyone who can look at the issues and tell us if we're close to having a problem? Otherwise, the best I can think of is some play on flowers. OpenPedels? Sunflower? A little move exotic, OpenOrchid? Or perhaps "open" as in opening the world of books? OpenReader?
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
mkmurray
Senior Member
#55
RussellHltn wrote:Valid point. I think it's quite possible that the DAISY Consortium who controls the Daisy specs or even Outerthought who makes the Daisy open-source content management system could complain.

Anyone know anyone who can look at the issues and tell us if we're close to having a problem? Otherwise, the best I can think of is some play on flowers. OpenPedels? Sunflower? A little move exotic, OpenOrchid? Or perhaps "open" as in opening the world of books? OpenReader?
We could somehow do something with Helen Keller. Maybe just call it Helen, or Keller. OpenKeller? OpenHelen? Or what about Anne Sullivan, her tutor? OSK (OpenSullivanKeller)?

LOL, I don't know...
russellhltn
Community Administrator
#56
mkmurray wrote:We could somehow do something with Helen Keller.
The blind leading the blind? :rolleyes: I don't know as her tutor was that well known. I don't know as I'd want to head down the blind ally, road. While the blind would get the most use out of it, I'd think it would also be good for those who have time to listen, but not time to read - such as when driving.

Hmmmm BookWorm Reader?

Or something emphasizing the audio - Talking BookWorm? SpeakReader? AudioReader?

Poking around the Latin dictionary, I found something I really like: Littera. (a letter, a written sign or mark signifying a sound) Unfortunately littera.com and littera.org are already taken, so it would have to be something like litterareader if it was to get it's own website.

The reason I like the name is it's simple and elegant. I don't see any reason the reader has to be limited to English, so something that has a little more "universal" name would be nice. Officially it would probably be known as Littera Reader, but Littera for short.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
mkmurray
Senior Member
#57
RussellHltn wrote:The blind leading the blind? :rolleyes: I don't know as her tutor was that well known. I don't know as I'd want to head down the blind ally, road. While the blind would get the most use out of it, I'd think it would also be good for those who have time to listen, but not time to read - such as when driving.

Hmmmm BookWorm Reader?

Or something emphasizing the audio - Talking BookWorm? SpeakReader? AudioReader?

Poking around the Latin dictionary, I found something I really like: Littera. (a letter, a written sign or mark signifying a sound) Unfortunately littera.com and littera.org are already taken, so it would have to be something like litterareader if it was to get it's own website.

The reason I like the name is it's simple and elegant. I don't see any reason the reader has to be limited to English, so something that has a little more "universal" name would be nice. Officially it would probably be known as Littera Reader, but Littera for short.
LOL, Babelfish says that daisy in Spanish is margarita.
mkmurray
Senior Member
#58
Read (verb) in Latin is lego, and read aloud is recito.

Speaker in Latin is orator. What if we called it Dorator (where the D stands for DAISY)? I kind of like that...
mkmurray
Senior Member
#59
Lector is Latin for reader.

What about DAR (DAISY Audio Reader)?
rmrichesjr
Community Moderators
#60
mkmurray wrote:Lector is Latin for reader.

What about DAR (DAISY Audio Reader)?
Already taken: "Disk ARchive" at http://dar.linux.free.fr/
russellhltn
Community Administrator
#61
mkmurray wrote:What if we called it Dorator (where the D stands for DAISY)? I kind of like that...
Visually it looks too much like "doctor" to me. Also who knows if it will stick with just DAISY long-term?

One of the reasons I like Littera is it suggests "literature", something a little more artistic or uplifting then just "talk".

But keep the ideas coming.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
cannona-p40
Member
#62
I like Littera and lector. OpenKeller gave me a good laugh, and Margarita would be interesting, though I don't think it would go over to well, especially if it was distributed on the Church's site. I also agree that keeping away from the Hellen Keller thing would be a good idea. Many blind persons sort of distance them selves from her; not because of her, but because of all of the wildly inaccurate movies and stories which have been produced about her.

Aaron
russellhltn
Community Administrator
#63
cannona wrote:I like Littera and lector.
Lector isn't bad, but one of the first things that come to mind is Hannibal Lecter. :o
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
mkmurray
Senior Member
#64
How about LPS (Litterae pro sulum, meaning Literature for everyone)?

There's also Libri pro sulum (books for everyone)...

Either one, we could call LiPS. That's appropriate since it's a book reader! :D
cannona-p40
Member
#65
I went ahead and completed the form at SF to create the project under the Littera name. That name was already taken, but it was a project that looked like it had had no work ever done on it, and it has been inactive for more than a year, so I made a request to take over the name. Unless the original admins complain, there should be no problem.

I'll let everyone know when I hear back from them.

Thanks.

Aaron
mkmurray
Senior Member
#66
Darn, I really liked LiPS...
russellhltn
Community Administrator
#67
mkmurray wrote:Darn, I really liked LiPS...
Could have used the lips from the Rocky Horror Picture show as the graphic. :D
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
cannona-p40
Member
#68
mkmurray wrote:Darn, I really liked LiPS...
Well, the request could always be rejected. LiPS is already taken as well, but I'll try for that one next, as it also has no releases yet.

Aaron
cannona-p40
Member
#69
The owner of Littera didn't want to give up his name. So, I am trying for LiPS.

We will see.

Also, as an update, I have nearly finished the class to parse the .SMIL file. Next I will work on the .NCX and .OPF parser, and finally, a class which will bring them all together. This last will be what the user interface communicates with to find out what text to display, what audio to play, what the elements of the table of contents are, ETC.

Aaron
russellhltn
Community Administrator
#70
cannona wrote:The owner of Littera didn't want to give up his name.
Well drat. Anyone think of an alternate spelling? Litteri? Litteree? Litta? Litteara?
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
thedqs
Community Moderators
#71
Leitura maybe?
- David
cannona-p40
Member
#72
This project is now available on Source Forge. I invite all interested persons to join the mailing lists and request developer access.

As this is my first bit of Python for public consumption, I'm very interested in any suggestions anyone might have on style, or anything else.

The Source Forge project is at https://sourceforge.net/projects/lips

Aaron
bhofmann
Member
#73
RussellHltn wrote:Well drat. Anyone think of an alternate spelling? Litteri? Litteree? Litta? Litteara?
What about literati?

Definition:
persons of scholarly or literary attainments; intellectuals
russellhltn
Community Administrator
#74
bhofmann wrote:What about literati?
Hmmmm. Not bad. Can't quite put my finger on it. Perhaps because it sounds like Glitterati?
Dang. Now my sweet tooth is acting up.

But it seems like Lips has been chosen.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
cannona-p40
Member
#75
cannona wrote:As this is my first bit of Python for public consumption, I'm very interested in any suggestions anyone might have on style, or anything else.

The Source Forge project is at https://sourceforge.net/projects/lips
If anyone wants to see some actual code, you can get it via SVN at https://lips.svn.sourceforge.net/svnroot/lips
or browse it online at http://lips.svn.sourceforge.net/viewvc/lips/

And again, critiques/offers to help are definitly welcome. Of course, if there is anything I can do to make contributing easier for you, please don't hesitate to ask.
danpass
Senior Member
#76

Microsoft Word files to speak to the blind

I thought this might be of interest...[INDENT]Microsoft Word files to speak to the blind

DAISY Consortium newsletter article on same topic
[/INDENT]
thedqs
Community Moderators
#77
Nice catch. Looks like we'll be able to do a lot of conversions very quickly from other sources too.
- David
anespa
New Member
#78
Dear Friends ,
I am Anes, from an NGO community for blinds. We developed a Python app for ubuntu platform daisy book reader. Currently it work only for Daisy 2.02 books. In future
we plan to develop it for Daisy 3.0 and epub formats with cross-platform (including windows etc..). As a developer I am interested to seek the support of same community people in development purpose... I am waiting for your reply... Feel free to contact me any time :anes.pa@gmail.com

Thanks
Anes