On Wed, 17 Mar 1999, Jason White wrote: > In answer to Brian's question, the issue arose in the context of a > discussion concerning the general utility of a conventional "screen > reader" approach, in which the braille/auditory interface is derived from > monitoring the visual u i, by contrast with the benefits to be gained from > enhancing the underlying software environment such that non-visual > interfaces can take advantage of the semantic and structural distinctions > reflected in the internal data representations maintained by applications. > Emacspeak exemplifies, very successfully, the latter strategy. While this was well thought out and clearly stated you are leaving out the fact that while emacspeak does work well for the software written spicificly for emacs it doesn't do well at all with aplications written for real world Shell users. Add to that fact that some Unix administrators don't even install Emacs do to its size this limits blind users greatly. In fact the University I am currently attending refuses to put the Emacs program on for me because their hardware is limited. I have to use my own system and hook in through the network. I argued > that priority should be given to influencing the development of > open-source software environments to facilitate a separation of > application functionality from visual presentation in ways that permit > braille and auditory interfaces to gain access, via generic means wherever > possible, to the semantic content required to ensure a high quality of > interaction. In reply, it was urged that good results could be achieved by > traditional "screen reading" methods and the writing of scripts that would > monitor the visual interface and react in specified ways to predefined > patterns in the visual presentation. It became clear in the course of this > discussion that some of the participants considered that importance should > be attached to the development of a text-based screen reader for the Linux > console which would employ scripts and macros in the manner suggested. By > way of rejoinder, I reiterated my reservations concerning the limits of > the "screen reader" concept and argued that, in any case, given that the X > Window System supports both text-based and graphical applications, and > recognising that UltraSonix employs essentially the design described > above, consisting, as it does, in core screen reader functions with the > details of the interface being controlled by scripts, there was no need > for a separate screen reader to be developed. Rather, efforts along > traditional screen reader lines should be concentrated on UltraSonix, This is the point where my blood realy boils. I have used Msdos programs for 8 years with these traditional screen readers and my screen reader employees AI to do a lot of what everyone is raving about EMacspeak. I read colums in a word processor fine no matter their size width or content. I can read what the colum header is or what is in the colum with a push of the button I can see the date I am in the in a calender and I am not talking about the number 1 I am talking entire date. Things that Emacspeak can do fine yes but so can these older screen readers. What is the difference? The difference is in order to learn Emacspeak you have to be willing to learn emacs. You shouldn't have to learn emacs to be able to use every aplication on the system nor should you have to install Xwindows to use a shell prompt. Again your suggestion of jumping on the Ultra sonics band wagon locks us into you either use Emacs or you use Xwindows. I use the shell currently with Asap and have been for 4 1/2 years. my pine doesn't talk to much my clients for my job work fine something that doesn't happen in Emacspeak.. I don't have to use Xwin and this is all done with one of those waisted speech programs you are jumping so badly. I would like to know what screen reader you used in the MsDos environment that ticked you off so badly I would bet it would be Jaws or Vocal-eyes judging by your comments because nothing you ahve said here fits my screen reader. I want to add that the screen reader that I have been using takes a total of 54k in memory if it was coded in 'c' it would probably take around 200k in memory and be able to handle every normal shell program perfectly. Including making sure pine don't talk to mucha nd the ability to read colums correctly. I think Speak-up and even SvlPro and a new commercial one I just heard of in the news groups which will be coming out soon are headed in the right direction. While Emacspeak will for sure be around for a long long time and may in the future benifit itself in having other screen readers around it is not and should not be the method everyone follows. That goes the same for an Xwin solution god knows I don't want to use Xwin anymore than I have to. Ken /whistler