Hi Mario,
>>>>> "ML" == Mario Lang <[EMAIL PROTECTED]> writes:
ML> Since speechd-el is more or less a direct replacement for
ML> Emacspeak which was called into existance because of frustration
ML> with how certain things work in emacspeak, I kind of doubt he
ML> (milan) is interested in maintaining emacspeak. OTOH, it would
ML> of course be wonderful, since much of the required knowhow to do
ML> the job properly is already there. Milan? <blink> :-)
All our GNU/Linux users happily moved from Emacspeak to speechd-el, so I
have no interest to get involved with Emacspeak anymore.
As for the other issues you presented, I agree accessibility in Debian
and Free Software generally needs much more help. Unfortunately
Brailcom currently lacks resources to invest more than it already does
into this area and my free time is very constrained for RL reasons, I
had to cut off almost all my personal software projects.
My personal interest areas where I might be able to help are:
- Accessible Emacs interfaces. In this area, speechd-el is maintained
and further developed by Brailcom. I personally don't think this is
the best approach to make Emacs accessible, but I think it currently
provides the best value interim solution and is going to play the role
for the several next years. Additionally, it's a good testing
platform for some accessibility concepts. So it's worth to invest
into it.
- Common accessibility infrastructure. Brailcom develops Speech
Dispatcher and we started to cooperate with KDE on extending the
Speech Dispatcher and KTTSD concepts to cover more application areas.
There was also work on a common API to text-to-speech systems, but
it's stalled now since all participants lacked resources to work on it
further. The only other party I could see any care about this project
recently is KDE. Apparently we need some impulse here. A similar
project is the work on audio framework requirements, where Brailcom
cooperates with KDE again and which seems to be promising.
- Free speech synthesizers. I think that free speech synthesizers
provide good basis to serve the accessibility issues in both the areas
of the quality and features today. Namely, Festival provides usable
to very good free English voices. Free voices for other languages
appear -- Brailcom works on Czech (already usable), Klaus Knopper
works on German, I've heard about Italian and Russian, perhaps someone
still works on French. The Epos project has recently released very
good Czech voices under a DFSG compatible (it seems) license.
Festival extensibility and ability to serve various accessibility
related issues is demonstrated by our festival-freebsoft-utils
package.
Work on supporting non-free speech synthesizers (except for the work
on the common TTS API) is IMHO waste of our limited resources which
could be better spent on supporting the relatively wide range of
activities towards free speech synthesis.
- Braille output. Both BrlTTY and libbraille teams make good work here,
the task is to improve their use in applications. Brailcom makes its
contribution by adding BrlTTY support to speechd-el.
- There are other smaller projects we do, e.g. sound-icons.
- Making X applications accessible. I consider that being a very
important issue, IMHO this is the place where accessibility efforts
should be put primarily now. The current state is discouraging from
the point of view of end users, but encouraging from the point of view
of developers. AT-SPI is here and it's supported in GTK and Qt. One
of the problems I can see is the integration of all the tools into a
working system. Looks like something Debian could deal with.
Not all these areas are necessarily related to Debian directly. But
when thinking about Debian accessibility, we should consider the
direction where Free Software accessibility moves generally and where
Debian can help best.
My vote for the very next Debian accessibility project actions would be:
- Providing up-to-date versions of the gnopernicus and brltty packages
in unstable.
- Making the accessibility issues of debian-installer more visible in
this mailing list.
- Making the project goals more visible here as well (e.g. as you did
with your original mail) so that more attraction could be brought to
the pending tasks and the Debian accessibility project generally.
Regards,
Milan Zamazal
--
Why waste keystrokes when you can waste CPU cycles instead?
Karl Fogel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
