Information about orca

Information about orca

[Sauro Cesaretti]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

Hello,
I'd like to know if I can use orca in both kde and gnome?
Can i use every kind of software based on x with it?
How can I install that screen reader?
thank in advance for all information.
best regards.
Sauro

[-- Attachment #2: Type: text/html, Size: 838 bytes --]

Re: [Kde-accessibility] Information about orca

[Peter Korn]

Hi Sauro,
> I'd like to know if I can use orca in both kde and gnome?
> Can i use every kind of software based on x with it?
> How can I install that screen reader?
> thank in advance for all information.
Briefly: not quite yet today, no, and see the Orca web site.

Screen readers for graphical UNIX systems like KDE and GNOME work by 
interrogating the applications and user interface elements directly - 
rather than by replacing the video driver or inserting themselves in the 
X protocol and building an Off-Screen Model of the text and semantic 
objects on the screen.  As such, they only work with applications that 
expose their information via standard API calls.  The standard we 
developed as part of the GNOME Accessibility Project is the Assistive 
Technology Service Provider Interface (or AT-SPI).  This is implemented 
by the GNOME desktop, the GTK+ graphics library, the Java/Swing library, 
the UNO library of StarOffice, and the XUL library of Firefox/Mozilla.  
Applications written with these graphical libraries, or which otherwise 
implement AT-SPI (like Adobe Reader 7 for Linux and Solaris), should 
work with Orca.  Orca is still in fairly early development (version 
0.2.4), and works better with some apps and some graphical libraries 
than others.  KDE 4 (and Qt4) plan to support AT-SPI, at which time Orca 
should work with KDE as well.

Information on installing Orca, and on most other things Orca related, 
are on the main Orca website: http://live.gnome.org/Orca  There, in 
addition to general installation instructions, you will find information 
on installing Orca on Fedora Core 5, Ubuntu Dapper Drake, and Sun 
OpenSolaris.

You might also join the Orca mailing list: <orca-list@gnome.org>.  You 
can subscribe via the web interface at: 
http://mail.gnome.org/mailman/listinfo/orca-list


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

Re: [Kde-accessibility] Information about orca

[Hart Larry]

I just looked on your Orca page, but I didn't see a list of synthesizers, 
either hardware or software.  I sure hope it may sound as good as Eliquence or 
support a Dectalk U S B?  Thanks
Hart

Re: [Kde-accessibility] Information about orca

[Peter Korn]

Hi Hart,
> I just looked on your Orca page, but I didn't see a list of synthesizers,
> either hardware or software. I sure hope it may sound as good as 
> Eliquence or
> support a Dectalk U S B? Thanks

It's on the FAQ page, under the question "What voices are available?".  
See:
http://live.gnome.org/Orca/FrequentlyAskedQuestions#head-b8e4ba96980c5d02358f6fc012187a499ba43b08

Orca works with all voices/engines supported by gnome-speech, which 
today includes Festival, FreeTTS, Fonix DECtalk, and IBMTTS (which comes 
from the same source code base as Eloquence, and sounds remarkably 
similar).  I'm not aware of any hardware engines supported by 
gnome-speech directly, but my information may be old...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. This is another great question for the <orca-list@gnome.org> 
mailing list.  I encourage you to take your Orca questions there!

Re: [Kde-accessibility] Information about orca

[Kristoffer Gustafsson]

    Hello!

How is it with via voice in these days?

The liast I heard was about one and a half year ago, when there was a 
discution on how to get via voice to work with newer operating systems than 
redhat 8.
Have anybody gotten this to work, or is there another way to obtain viavoice 
for linux?

/Kristoffer
----- Original Message ----- 
From: "Peter Korn" <Peter.Korn@Sun.COM>
To: "Hart Larry" <chime@hubert-humphrey.com>
Cc: "Linux for blind general discussion" <blinux-list@redhat.com>; 
<kde-accessibility@kde.org>
Sent: Friday, June 02, 2006 12:35 AM
Subject: Re: [Kde-accessibility] Information about orca


> Hi Hart,
>> I just looked on your Orca page, but I didn't see a list of synthesizers,
>> either hardware or software. I sure hope it may sound as good as 
>> Eliquence or
>> support a Dectalk U S B? Thanks
>
> It's on the FAQ page, under the question "What voices are available?". 
> See:
> http://live.gnome.org/Orca/FrequentlyAskedQuestions#head-b8e4ba96980c5d02358f6fc012187a499ba43b08
>
> Orca works with all voices/engines supported by gnome-speech, which today 
> includes Festival, FreeTTS, Fonix DECtalk, and IBMTTS (which comes from 
> the same source code base as Eloquence, and sounds remarkably similar). 
> I'm not aware of any hardware engines supported by gnome-speech directly, 
> but my information may be old...
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> P.S. This is another great question for the <orca-list@gnome.org> mailing 
> list.  I encourage you to take your Orca questions there!
>
> _______________________________________________
> Blinux-list mailing list
> Blinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list 

Re: [Kde-accessibility] Information about orca

[ari]

Sorry for asking this, but why can't, or wouldn't it be better for unix GUI
screenreaders to also use the video intercepter?
Ari

Re: [Kde-accessibility] Information about orca

[Samuel Thibault]

ari, le Sat 03 Jun 2006 08:44:20 +0200, a écrit :
> Sorry for asking this, but why can't, or wouldn't it be better for unix GUI
> screenreaders to also use the video intercepter?

Do you mean, for getting a graphical snapshot of what X displays? You
would then have to use an OCR for getting text...

Samuel

Re: [Kde-accessibility] Information about orca

[Tim Chase]

> Do you mean, for getting a graphical snapshot of what X displays? You
> would then have to use an OCR for getting text...

In theory, it might be possible to create an X server that 
intercepted the calls and made an internal representation of them 
that was more accessible and navigable.  One might start Xorg 
with either the frame-buffer driver ("fbdev"), or even the 
"virtual frame-buffer server" (Xvfb) which doesn't require any 
sort of video card at all.

I don't think anybody has attempted this, but, IMHO, it's the 
best sort of place to build an accessible-GUI solution for 
Linux/BSD, as (much like JAWS) it's an interceptor of all the 
calls for drawing and rendering text on the screen.  It wouldn't 
rely on a particular toolkit (GTK or KDE), but rather would work 
with every X application that used standard text-rendering 
functionality.

Just a few thoughts on the matter...

-tim

Re: [Kde-accessibility] Information about orca

[Samuel Thibault]

Hi,

Tim Chase, le Sat 03 Jun 2006 08:25:37 -0500, a écrit :
> >Do you mean, for getting a graphical snapshot of what X displays? You
> >would then have to use an OCR for getting text...
> 
> In theory, it might be possible to create an X server that 
> intercepted the calls and made an internal representation of them 
> that was more accessible and navigable.

But with your strategy, you need an OCR for getting the text that is
displayed.

> I don't think anybody has attempted this

The ultrasonix project attempted it and was sorta successful because at
that time applications were asking the X server to draw text.  But with
nowaday's applications, applications draw everything themselves thanks
to toolkits like gtk or qt, including text, so ultrasonix can't get much
better information than a graphical snapshot, which is difficult to
interpret.

>, but, IMHO, it's the 
> best sort of place to build an accessible-GUI solution for 
> Linux/BSD, as (much like JAWS) it's an interceptor of all the 
> calls for drawing and rendering text on the screen.

I don't know for sure, but I thought JAWS was using microsoft's MSAA,
which is just what at-spi is.

> It wouldn't rely on a particular toolkit (GTK or KDE), but rather
> would work with every X application that used standard text-rendering
> functionality.

X applications don't use standard text-rendering functionalities
(because these are pretty much outdated).

> Just a few thoughts on the matter...

That made sense some time ago, but unfortunately not any more.

That said, for old applications that would be still in use, it might
still make sense.

Samuel

Re: [Kde-accessibility] Information about orca

[Tim Chase]

>>In theory, it might be possible to create an X server that 
>>intercepted the calls and made an internal representation of them 
>>that was more accessible and navigable.
> 
> But with your strategy, you need an OCR for getting the text that is
> displayed.

Like JAWS (and WindowEyes?), it would be intercepting the calls 
to things like XDrawText where the actual text is being passed in 
to the X server, before it has been rendered to the "screen". 
However, as you pointed out (and I didn't know before you 
mentioned it) UltraSonix's difficulty with applications bypassing 
standard X calls, rendering to an image, and then just having X 
render the image.  It looks like such a solution would need to 
patch not only X, but the Cairo rendering library, as well as the 
GTK and KDE libraries, and possibly other rendering libraries 
(such as xcompmgr, stuff from the Enlightenment window manager, 
and possibly others).

Yuk.

> I don't know for sure, but I thought JAWS was using microsoft's MSAA,
> which is just what at-spi is.

They might be using both.  My understanding (feable as it may be) 
was that they started by intercepting GDI calls with their own 
device-context/display-driver, catching various instructions for 
rendering text to build an internal model of the screen.  After 
MS added their accessibility framework, they may have made use of 
it (in addition, or instead).

Intercepting GUI stuff, unless designed from the ground-up to 
support it and enforce it, is an ugly proposition.  Unless 
developers are forced to use it by way of API requirements, a 
far-too-large percentage of developers will not take 
accessibility into consideration when developing an application.

Thus, we end up with this ugly dichotomy of "accessible 
applications" and "not so accessible applications".  It's also 
one of the beauties of console applications:  because they all 
write to a grid of text cells, everything is exposed as text 
(okay, it takes going out of one's way to attempt to draw images 
on a text-cell console) and that text can be navigated fairly 
easily.  As evidenced by yasr, screader, speakup, emacspeak, etc.

Thanks for the info about toolkits bypassing the X APIs for 
drawing text.  It's only 9:00am and I've already learned my 
something new for the day.  I guess I can go back to bed now. :)

-tim

Re: [Kde-accessibility] Information about orca

[Samuel Thibault]

Tim Chase, le Sat 03 Jun 2006 09:02:46 -0500, a écrit :
> >>In theory, it might be possible to create an X server that 
> >>intercepted the calls and made an internal representation of them 
> >>that was more accessible and navigable.
> >
> >But with your strategy, you need an OCR for getting the text that is
> >displayed.
> 
> Like JAWS (and WindowEyes?), it would be intercepting the calls 
> to things like XDrawText where the actual text is being passed in 
> to the X server

Agreed, that's what Ultrasonix does IIRC, but I do tell you that
applications don't use XDrawText anymore. They draw text themselves
(with the help of freetype & such libraries) and just send the _pixmap_
to the X server.  Don't expect people to ever use XDrawText again.

Samuel