Re: Announcing the OpenTTS project, a fork of speech-dispatcher
William Hubbs napsal(a): There has, in my personal opinion, been very poor collaberation between the accessibility community and Brailcom. We announced that we are not currently able to put a reasonable amount of work into it, but that we welcome anyone willing to help. We avoided any unfair promises, but offered collaboration. Please, read the answer to the Open letter by Mr. Buchal carefully. We didn't receive any concrete offer for such collaboration. So it can be also said that there has been a poor collaboration between the community and Brailcom. I don't think it's fair either way. One example, in my opinion, of poor collaberation has been Brailcom's extremely minimal involvement in the development process. A development repository was opened by Luke so that some of us would be able to get changes into speech-dispatcher. Many patches were sent to this list, for a long time, but there has been extremely minimal participation from Brailcom, so the official repository was never updated and Brailcom hasn't been responding to our patches. We have put a huge amount of resources and our own personal effort into the Speech Dispatcher project within the nearly 10 years of its development. And among other reasons also due to a minimal feedback from the community, we started to put more of it into other our projects in the last two or three years. As we have responsibility for these other projects, we can not switch our long term plans from day to day just because the community decides they now need us. Thus we avoided making any promises that we are not able to guarantee. That's all. We repeatedly asked Brailcom for direction on this list and were told that they couldn't commit any resources to speech-dispatcher at this time. So, speech-dispatcher was becoming a more important project to the accessibility community, but the maintainers were not working on it, and they had no idea when they would be able to work on it again. Not being able to promise is not the same as not having an idea. Another concern I personally have is Brailcom's speechd-up project being deprecated as well as their comments on their speechd-up project page about speakup itself being replaced by other technologies. On the contrary, speakup has a very active user base and shows no signs of being replaced. We only announced that we are not going to continue speechd-up development. We will be glad if someone else will take the project and go on. That's the difference compared to Speech Dispatcher. In my opinion, the fork happened because of poor collaberation and slow responsiveness from the maintainers. I understand that what Brailcom spends their time on is controled by funding, but they made no effort or very minimal effort to work with the community. As well as the community made a little effort to help us. No one asked, hey, I would like to see a new release because I feel the feature XY deserves it. What can I do to help that happen? We were only asked to act or make public promises. Yes, we could continue doing unofficial releases and waiting for them to do official releases when they get funding, etc, but the problem there is that if we add functionality in the community releases, there is no guarantee that that functionality would be accepted by Brailcom in their official releases. I wouldn't see anything wrong about having unofficial patches in Speech Dispatcher packages. That's the packager's responsibility. Of course, it is more convenient when the patches get included upstream, but let's not exaggerate the situation. We said we are going to include them and we were working on it as the time permitted us. We announced the existence of these unofficial versions in the meantime. I personally would be open to working on speech dispatcher, but there would need to be a big change in the way Brailcom collaberates with the community for me to be comfortable with that. If you really mean it, if you are able to accept the increased overhead of collaboration which is compensated by avoiding duplication and confusion, let's stop fruitless discussions. I understand your reasons and if you try to understand ours pragmatically, there is still a chance for more collaboration. I am stopping any arguments on this topic right now because it is really wasting time. Please, consider our limited possibilities and try to suggest a model that would suit you. Best regards, Tomas Cerha Brailcom, o.p.s. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Announcing the OpenTTS project, a fork of speech-dispatcher
Hello, just my few personal thoughts... While I respect anyone's freedom to take on the work that we started and continue in a direction he believes is the best, I am not quite convinced that making a fork is necessary and helpful. The announcement started by a question Why Fork Speech Dispatcher and Related Projects?, but I can't find anything that would answer the question for me even if I pretty much agree with all what was written below. It is true, that GPL grants the freedom to do it, that the importance of Speech Dispatcher grew over the time and that the non-profit organization Brailcom didn't find resources to finance the development in the last two years. But I fail to find a convincing reason in these facts. Brailcom has always officially supported the work done by Luke Yelavich and others. We linked Luke's git from the official Speech Dispatcher web page and we were trying to promote this work where possible. We also put at least some minimal effort into reviewing how the development continues and plan to make an official release (yes, without being able to promise the exact date) and we constantly put significant effort in attempts to find resources for continuation of the work and we believe we will succeed (though, as we announced, we can not promise anything, as it does not depend on our decision). I am just afraid, that having two projects with two names and different directions will not be really practical. What particularly is the key problem in the current model where the actual development takes place in Luke's git repo? I don't say it is ideal, but maybe there is less to do to make it better, then making a fork and renaming... Best regards, Tomas Cerha ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Run Vibuntu on USB with persistant storage!
Stephen Shaw wrote: I'm glad you are excited about this, but not sure that turning all of these lists into the vibuntu mailing list is appropriate. Yes, I wish Anthony a good luck with Vibuntu, but reading about it in three different mailing lists is definitely annoying. Best regards, Tomas ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Thoughts on speech
Willie Walker wrote: * While it may not be the pristine perfect solution, Speech Dispatcher seems to fit nicely into the overall requirements we need as a larger community. Hello, I am not saying SD is pristine perfect, but are there any concrete indications for saying it is NOT? o Is the configuration simple enough and/or can it be made simpler? The main point is that (unlike Gnome Speech) it IS configurable and it makes a number different usage scenarios possible. I don't think, however, that its configuration is something to be done by end users unless they want to experiment. Speech Dispatcher should be configured by the package maintainer for the os/distribution. All the settings which are interesting for a typical end user, such as voice, rate etc., are controlled through Orca so the user doesn't deal with Speech Dispatcher configuration directly. o What additional work needs to be done to integrate it more tightly with Orca? There are ways to look at this problem: 1) What needs to be done in Speech Dispatcher and its Orca backend to support all the functionality needed in the current Orca design 2) What changes in Orca design can be done to make use of the capabilities offered by Speech Dispatcher For 1), there are two concrete things to do: a) Solve the verbalization issuses described at http://bugzilla.gnome.org/show_bug.cgi?id=440114 b) Solve word boundary callbacks (see below). For 2) I won't go into much detail now, but the advantages would most often be in cleaner code than in end user visible features. That's simply because of the fact, that SD API uses a higher level of abstraction than Gnome Speech. There is a well defined system of interaction between different kinds of messages and SD automatically makes sure that certain messages don't get interrupted by others etc. Orca currently relies just on SPEAK and STOP and handles all the interaction itself (for example by storing the last time key echo was performed in a global variable and testing this variable on places, where keyboard echo interruption is not desirable). Other advantage is that there is no need for ANY driver specific code. The interface is completely transparent from this point of view and all driver specific code is located in SD output modules. Ok, I promised to tell more about the callbacks. SD currently does not support automatic callbacks on word boundary, because it supports callbacks through index marks in SSML. So the text would need to be marked in Orca (in its SD backend) by inserting index marks at word boundaries. When I was implementing this in Orca backend, I discovered, that Orca currently doesn't handle these callbacks, so I left this functionality out. If Orca decides to use these word boundary callbacks, this will need to be added to the SD backend. I have, however, one concern about that -- the correct detection of word boundaries is a language dependent operation and thus the only correct place where it should really be done is the speech synthesizer because only the synthesizer knows the lexical structure of the text. On the other hand, if the intended use is only for positioning the cursor, it might be a reasonable simplification to only guess the boundaries using a regular expression, without the intention to be absolutely lexically correct. This needs some more consideration and Will's feedback. Adding automatic word boundary callbacks to Speech Dispatcher (without the need for SSML and index marks) is also a viable option. I believe it is also important to consider other possible advantages of using SSML within Orca. This may have a major impact on the future of Orca speech capabilities and the API. Best regards, Tomas ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Multilingual synthesis
Peter Parente wrote: Right. The problem is, not a single free engine covers the different languages I need. So I have to change voice and driver (festival and espeak from speech-dispatcher). And don't you get sound device blocking problems? Understood. We don't support switching of the driver and voice yet automatically, but it's not inconceivable. Speech Dispatcher solves this completely. You can set prefered drivers for each language and any conflicts are solved by Speech Dispatcher's queuing and priority mechanism. Since Speech Dispatcher also handles speech output, no problems with the output device arise. Best regards, Tomas ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca and minimalist X environments (was Re: accessible routers)
Kenny Hitt napsal(a): The problem with this is you loose the ability to cut and paste data from all the running apps on the system. The command `xclip' allows you to operate X selection from the command-line. In Debian, it comes in the package of the same name. Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Emulating a hardware synth
Samuel Thibault wrote: Maybe speech dispatcher has a way to do this. No, it doesn't. It's a nice idea, however. Anyone interested doing it? Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Is Debian appropriate for accessibility?
Lorenzo Taylor wrote: The source package however installs fine with the current Debian packages with the exception of python-pyorbit, which seems to be out of date. The package python-pyorbit is available from Debian experimental. Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: eSpeak support in Orca -- what is the best way?
Henrik Nilsen Omma wrote: * Speech Dispacher support for Orca -- I know there have been issues raised about this before. Some missing features are mentioned here: http://live.gnome.org/Orca/SpeechDispatcher Hello, the major issue now is the missing callback support. This results in missing cursor/speech synchronization. As far as I know, the end user will notice that in OpenOffice when reading the whole document -- when he interrupts the speech, the cursor will not be positioned to the place where the speech was interrupted. Maybe there are some other situation, may someone comment on that? Adding this support into the Speech Dispatcher Orca backend should not be technically difficult (my rough estimation is 40 manhours, being tempted to say much less). Well, once we get the functionality to the Orca backend, we will also need to support it in the Speech-Dispatcher eSpeak driver. The author of eSpeak added an API for that recently. Maybe Hynek or Jonathan will tell us more about the progress here. I do wonder how the user community would react to a sudden switch of default synth though. Thoughts? Please also note, that Dpeech Dispatcher allows you to switch synthesizers automatically based on the current language, so you should be able to use e.g. Festival for English and eSpeak for other languages. This, however, must be supported by the client (i.e. Orca) by providing relevant language information. Hope this information helps. Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca on laptops.
Bill Haneman: I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. Hello, I'm using CapsLock as another Ctrl key. It is configurable through Gnome keyboard properties dialog (before it was there I used a modified xkb layout to achieve that). Without any deeper knowledge, I'd assume that this is not a hardware feature, when one is able to remap the key easily. Just a hint... Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Using espeak
Willie Walker wrote: 3) I've been holding off rolling the direct speech-dispatcher support into Orca because of the lack of callbacks. The main reason we want callbacks today is to be able to position the caret when a say all operation completes or is interrupted. In the future, we could use them to move the magnifier region of interest and also to highlight the current text being spoken as it is spoken. We've been talking with the speech-dispatcher folks regarding getting callbacks. The ball is in their court right now, and I'm waiting for a response from them. Hello Will, Nolan and all, I'm still hoping to get back to Speech Dispatcher Orca backend soon, but as you may have also realized, the reality is not always in agreement with our wishes... Today, we talked with Hynek Hanke about it and we agreed to cooperate on that. None of us can afford devoting too much time to it, but we will try to find the most efficient solution and add callback support to the Orca/SD backend. Still can't promise any dates, since this is done in our spare time, which practically doesn't exist... Will, what is the current status of Orca speech API. Did you do the changes you planned in summer? Or do you plan some changes in near future? Anyway, Nolan, if you prefer to make espeak working without caret positioning, the current Orca/SD backend might be still useful for you and should be more responsive than the Orca/gnome-speech/speech-dispatcher solution (which doesn't support callbacks aswell). See http://www.freebsoft.org/~cerha/orca/speech-dispatcher-backend.html Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Linux desktop accessibility demo - which programs should I install
Bill Haneman napsal(a): The SpeechDispatcher API has some limitations which make the user experience with orca a little less nice - as I understand it, SpeechDispatcher doesn't support completion/progress tags within an utterance, it can only tell you when an entire utterance is complete. Not really. This limitation only applies to the current Orca backend for Speech Dispatcher. Speech Dispatcher itself supports index marks which are exactly for this purpose. Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: lsr-0.3.0 and speech-dispatcher
Peter Parente napsal(a): Hi Tomas, I apologize for the offense caused by the poor grammar and vagueness of my message. Hi Pete, No offense taken. As I wrote I didn't believe it was intentional, so I am happy to hear that it was even a mistake. Have a nice day, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: lsr-0.3.0 and speech-dispatcher
Peter Parente napsal(a): Thanks for trying speech dispatcher with LSR. The module is pretty rough around the edges since Speech Dispatcher is still under heavy development. You've likely encountered a bug. Hello Peter, I have to object strongly. I don't think it was your intention, but please consider, that you may hurt other project by such a proclamation. Speech Dispatcher is not under heavy development for quite some time now. What was under development lately is just the Python interface library, but even there we were keeping the backwards compatibility very strictly. We're definitely open to discuss any (even potential) problems in our software and we never pretended it is perfect, but I think one should be very carefull when making judgments about other peoples work in public. I'm sorry I had to say that. Anyway, I wish you a good luck with the LSR project. To me it seems technologically very promising. Best regards, Tomas. ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Fixing gnome-speech
Luke Yelavich wrote: Mind I ask when this is likely to be completed? If you would like testers, I would be happy to put my hand up and try. Hi Luke, I hope to be able to make something available this week, but can't promise, since I'm at Guadec and it might be hard to find some spare time. If not, then I'll be back at work by the middle of July. I will definitely announce it as soon as there is something. Best regards, Tomas. -- Brailcom, o.p.s. http://www.brailcom.org Free(b)soft project http://www.freebsoft.org Eurochance project http://eurochance.brailcom.org ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Fixing gnome-speech
Enrico Zini wrote: Hello, In the meantime, however, before I hurt my brain too much with this, what's the overall situation? Is it worth the effort of fixing gnome-speech, or is the effort better spend on making something else work? Hi Enrico, I'm currently working on Speech Dispatcher backend for Orca. This bypasses the Gnome Speech layer completely. Since Speech Dispatcher offers several speech synthesizers not supported by Gnome Speech, this may be essential for some people and the Orca - Gnome Speech - Speech Dispatcher - synthesizer aproach has inherent problems. This might solve your problem too. Please, see also the common TTS API draft at http://www.freebsoft.org/tts-api. This is a common effort of Free Desktop and FSG. Best regards, Tomas -- Brailcom, o.p.s. http://www.brailcom.org Free(b)soft project http://www.freebsoft.org Eurochance project http://eurochance.brailcom.org ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Off-topic announcement: Free On-line Courses of English and German language for blind people
Hello, I am sorry for an off-topic announcement, but I believe this might be an interesting information for many participants of this list. Brailcom is pleased to announce, that our project of free, Internet based language courses for blind people was finished and the results are available on-line to anyone interested. The courses are designed to allow self-studying and are accessible using free software tools. English and German language courses are available in two levels: Intermediate and Advanced. Find more at http://eurochance.brailcom.org. Any feedback is welcome. Best regards Tomas Cerha -- Brailcom, o.p.s. http://www.brailcom.org Free(b)soft project http://www.freebsoft.org Eurochance project http://eurochance.brailcom.org ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Common AT config panel
Hynek Hanke wrote: I'd like to propose to move this thread to [EMAIL PROTECTED] so that it is not spread across several mailing list, people know where to post replies and we have an archive. The mailing list at Freedesktop currently has subscribes from a wide range of accessibility projects both from graphical desktops and from the console and is a place where also other similar points of cooperation are being discussed. I also invite everyone who is interested to join if he didn't do that already. It is a low-traffic list. More information is on http://lists.freedesktop.org/mailman/listinfo/accessibility I just want to inform those, who are not yet subscribed to the accessibility mailing list at Freedesktop.org, that I started a new thread Common Configuration Framework which is closely related to the topic of this thread. See http://lists.freedesktop.org/archives/accessibility/2006-May/98.html for more information. Best regards, Tomas Cerha -- Brailcom, o.p.s. http://www.brailcom.org Free(b)soft project http://www.freebsoft.org Eurochance project http://eurochance.brailcom.org ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Re: Orca 0.2.3
Janina Sajka wrote: PS: This is also an opportunity for our f/oss environment to provide greater accessibility than people have come to expect on platforms like Windows and Macintosh. I believe those two environments rely on gui configuration tools, so I am not surprised people would talk about wanting gui configuration tools. But, it's the wrong approach. That's a good point. When a user says: I want THIS, the greatest problem sometimes is to realize what THIS actually is... Best regards Tomas -- Brailcom, o.p.s. http://www.brailcom.org Free(b)soft project http://www.freebsoft.org Eurochance project http://eurochance.brailcom.org ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
