From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (qmail 9106 invoked by uid 0); 8 Oct 1996 00:21:23 -0000 MBOX-Line: From zocki@goldfish.cube.net Tue Oct 8 01:56:46 1996 Received: (qmail 8875 invoked by uid 504); 7 Oct 1996 23:53:23 -0000 Date: 7 Oct 1996 23:53:23 -0000 X-From_: root@goldfish.cube.net Tue Oct 8 01:53:22 1996 Received: (qmail 8778 invoked by uid 0); 7 Oct 1996 23:53:15 -0000 Old-Date: 7 Oct 1996 23:53:15 -0000 Message-ID: <19961007235315.8777.qmail@goldfish.cube.net> From: zocki@goldfish.cube.net To: blinux-list@goldfish.cube.net Subject: UltraSonix-FAQ List-Id: Dear blinux subscriber, there is a new port of the UltraSonix screen reader for the X Window System to Linux (see message in blinux-list from 25.09.96). To give you some first impressions about UltraSonix, here comes the UltraSonix FAQ which is part of the UltraSonix package. The UltraSonix package (2.4 MB) is ready for download by FTP at: multimedia.cc.gatech.edu/pub/UltraSonix.source-7.0.tar.Z and at the blinux ftp server (uploading this minute :) leb.net/incoming/blinux/UltraSonix.source-7.0.tar.Z will go later to: leb.net/pub/blinux/UltraSonix.source-7.0.tar.Z Enjoy! Hans ----------------------------------------------------------- U L T R A S O N I X F R E Q U E N T L Y A S K E D Q U E S T I O N S FAQ Version 1.0, last updated September 3, 1996 Maintainer: Keith Edwards Xerox PARC kedwards@parc.xerox.com 1.0 INTRODUCTION 1.1 What is UltraSonix? 1.2 Why do I sometimes see the software called Mercator or Sonic X? 1.3 Licensing 1.4 Porting 2.0 PROJECT HISTORY 2.1 Early Days 2.2 Heading Towards RAP 2.3 The Current Architecture 2.4 Current Status 3.0 REQUIREMENTS 3.1 Development Requirements 3.2 Runtime Requirements 3.3 Hardware Requirements 4.0 USAGE 5.0 PUBLICATIONS AND RESOURCES 5.1 What documentation is available? 5.2 Is there a Web page on UltraSonix? 5.3 What papers have been published on the system? =========================================================================== 1.0 Introduction 1.1 What is UltraSonix? UltraSonix is a prototype screenreader for the X Window System and UNIX. It provides speech and non-speech auditory representations of the applications on a user's X desktop, and can also generate Braille output of text areas. It can synthesize the input that applications "expect" (mouse clicks and key presses) from alternative input sources. The software works best with X11R6.1 applications built using the Xt toolkit and Motif. The software was developed at Georgia Tech over a period of several years. Since then, the original developers have moved on to other projects. This release of the system is free for non-commercial use. See 1.3, Licensing, and 1.4, Porting, for more information. The work at Georgia Tech is no longer on-going, and the developers unfortunately have very limited resources for supporting the software. The current version of the software is known to work only on Sun SPARCstations running Solaris 2.5 and the Common Desktop Environment (CDE). 1.2 Why do I sometimes see the software called Mercator or Sonic X? The original project at Georgia Tech was called Mercator, after Gerhardus Mercator, a 16th century cartographer who devised a projection of the Earth's surface in which lattitude and longtitude projections are parallel, easing navigation. It turned out that the name Mercator was trademarked, so we went with Sonic X as a potential new name. That name (or one close to it) was also taken, so we finally wound up with UltraSonix. The current distribution still has a number of references to Mercator and Sonic X in it. 1.3 Licensing The UltraSonix software has a registered copyright on it by the Georgia Tech Research Corporation. The use of the program is restricted to educational and non-commercial use only. Any inquiries regarding licensing should be directed to: Georgia Tech Research Corporation Technology Licensing Centennial Research Building - Rm. 275 400 Tenth Street, N.W. Atlanta, Georgia 30332-0415 1.4 Porting An effort is underway by a number of people to port the software to the Linux operating system on Intel hardware. Mark Novak of the Trace Center in Wisconsin is coordinating this effort. Mark can be contacted at menovak@facstaff.wisc.edu. =========================================================================== 2.0 Project History 2.1 Early Days The Mercator project was started at Georgia Tech in 1991, and was initially a collaboration between the Tech Center for Rehabilitation Technology and the Multimedia Computing Group. The CRT had expertise in access software and a need for providing some form of access to X, and the MCG had a lot of experience hacking the internals of the X Window System. At this time, the project was funded by the NASA Marshall Space Flight Center and an interdisciplinary research grant from Georgia Tech. When we started, we wanted to take a pragmatic approach toward engineering so that we could produce something that someone might actually be able to use, but also keep a reseach-oriented focus and try to gain some new insight into novel interaction techniques for auditory environments. One result of the research focus that fell by the wayside was an investigation of techniques for synthetically spatializing audio to produce "3D sound" from a digital source. While not incorporated into Mercator, our group did produce some rather nifty 3D sound software. David Burgess (now at Interval Research Corporation) was chiefly responsible for this work. http://www.cc.gatech.edu/gvu/multimedia/spatsound/spatsound.html has more details if you're interested. Version 1.0 of the software was completed in 1992. Version 1.0 was architecturally very different than UltraSonix today because it started from a presumption that turned out to be not true: that we would not be able to alter the basic design of the X Window System to support screenreaders. Version 1.0 used an "external" approach to providing access. This means that it required no modifications of any kind to applications, toolkits, or window servers to operate. The system basically situated itself between the X server and client applications. To applications, Mercator appeared to be a generic X server, and to the "real" server Mercator appeared to be a client application. A big problem with this approach is that the X protocol provides very low-level information only. So the creation of an on-screen button would result in an sequence of X protocol traffic specifying lines to be drawn at absolute pixel coordinates. To work around the low-level nature of the protocol traffic, version 1.0 of the system augmented the information derived from the protocol traffic with Xt-specific information available via the higher-level Editres protocol. Editres was originally designed as a tool for interactive customization, however, and it became clear that it wasn't suitable for our needs. Mercator 1.0 is described in Technical Report GIT-GVU-92-05, available from Georgia Tech or from the Mercator web site. Despite the architectural differences between 1.0 and later versions, the hierarchical navigation scheme and auditory icons used by 1.0 have pretty much carried through to the latest version. 2.2 Heading towards RAP. After version 1.0, we backed away from our requirement that we not modify X, and started to look at what minimal set of changes could be made to support screenreaders and similar applications. This resulted in an Editres-like protocol designed to gather information at the level of Xt widgets: buttons, scrollbars, and the like. This protocol was called (creatively enough), XtProto, and served as a testbed for us to see what types of services we could provide to screenreaders if we could communicate information about widget state. The work on XtProto resulted in Mercator version 2.0. This work and XtProto itself were described at the X Technical Conference. Version 2.0 worked well enough that we believed it was the way to go for future screenreader work under X. We also had a set of modifications to the Xt and Xlib libraries that could be used to provide information about GUI state to screenreader programs. This version also had the added side-effect that it let us show a proof-of-concept to folks at the X Consortium, and get the ball rolling on incorporating functionality like XtProto into future versions of X. Versions 3.0 and 4.0 refined the internals of the system and cleaned up the protocol to the point that we felt comfortable with its stability and utility. Both of these versions added user interface functionality, but were based on a protocol derived from the XtProto used back in version 2.0. These later versions were supported by the NASA Marshall Space Flight Center, Sun Microsystems, and the National Security Agency. 2.3 The current architecture At about this time, we took over the task of proposing a protocol and set of Xt and Xlib extensions for screenreaders to the X Consortium. Broadly, these modifications fall into a number of categories: - Changes to Xlib. We needed a way to get low-level protocol information from Xlib reliably; our old pseudo-server approach introduced too many race conditions to work well, so X11R6 shipped with a new client-side Xlib extension, called XESetBeforeFlush that can catch this protocol information before it goes out over the wire. - Changes to Xt. We needed to hook into Xt to trap information about widget state changes. Kaleb Keithley implemented a set of hooks in the R6 libXt that provides can capture widget state information. A number of people on the x-agent mailing list also contributed to this design. - A rendezvous protocol. Will Walker at Digital Equipment Corporation proposed a protocol for initially connecting screenreaders (called "external agents") to running applications. This protocol shipped in X11R6.1, and is called the ICE X Rendezvous Mechanism. Look for a description of it in the Interclient Communication Conventions Manual (ICCCM). A number of other people also had input into the design of this protocol. - A remote access protocol. Will Walker came up with the nifty acronym RAP, for Remote Access Protocol. RAP is basically a descendent of XtProto, cleaned up to use the hooks into Xlib and Xt, and Will's rendezvous mechanisms. Unfortunately, RAP has not yet been adopted by the Consortium as a standard. Version 5.0 of the system was a complete overhaul, incorporating RAP and a number of other changes including the ability to dynamically load new I/O modules without recompiling. This version is described in the ACM Symposium on User Interface Software and Techology, (see Publications, below). Version 6.0 added much better text-handling ability, lots of bug fixes, and support for the Common Desktop Environment (CDE). At this time, our main sponsors were Sun Microsystems and the National Security Agency. We shipped code to them in December of 1995, and the project officially ended at that time. None of the core people from the project are at Georgia Tech any longer. Version 7.0 is the "external" release. It is exactly the same as the version 6.0 code we shipped to the NSA, but includes some legal disclaimers that the Georgia Tech Office of Techology Licensing wanted. A few people have version 6.0 source code that they got by signing individual-use licenses before version 7.0 hit the streets. We should probably rename version 7.0 to 1.0 or something, since noone will ever use any earlier versions anyway. Past project members include: Elizabeth Mynatt Keith Edwards Tom Rodriguez Ian Smith Kathryn Stockton Sue Liebeskind Will Luo Stacy Ann Johnson Kevin Chen John Selbie David Burgess Phillip Seaver Thanks to others who have played a great role in getting this software off the ground: John Goldthwaite Will Walker Gerry Higgins Craig Moore Gary Day Earl Johnson Sue Hartman Mayer Max Sheila Stanley Jim Hoover 2.4 Current Status The current external release of the software is version 7.0. Work is ongoing under the auspices of the Trace Center to port UltraSonix to Linux (see 1.4, Porting, above). =========================================================================== 3.0 REQUIREMENTS 3.1 Development Requirements The project at Georgia Tech was only concerned with bringing the system up on Sun hardware running Solaris. The system as released from Georgia Tech is known to run on Sun SPARCstations running Solaris 2.5 and the Common Desktop Environment (CDE). The requirements below reflect this platform; ports to other platforms may have other requirements. To build UltraSonix, you will need the following: - An ANSI-compliant C compiler (we used Sun SPARCcompilers C 3.0.1). - A reasonably-good C++ compiler, with support for templates and exception handling (we used Sun SPARCcompilers C++ 3.0.1). - Fairly POSIX-standard include files. - The Rogue Wave Tools.h++ class libraries, version 7.0 or later. - The Tcl scripting language. - X11R6 or later. See the Design Guide for more information. 3.2 Runtime Requirements UltraSonix requires a reasonably quick machine to run well. We developed on SPARCstation 10-class hardware, but ran on everything down to a SPARCstation 2 with 32MB RAM. To run the system, you will need - Hardware supported by the system (see 3.3, Hardware Requirements, below). - The Sun audio device (/dev/audio). - Either modified X11R5 or X11R6 for client applications. - Client dynamically linked against X11R5 or X11R6. 3.3 Hardware Requirements The following hardware is currently supported: - Dectalk DTC01 speech synthesizer - Dectalk Express speech synthesizer - Entropic TruTalk software-only speech synthesizer - Alva 3/20 Braille terminal - Alva 3/80 Braille terminal - Genovations keypad =========================================================================== 4.0 USAGE ... I'll be adding stuff here as the questions come in. :-) =========================================================================== 5.0 PUBLICATIONS AND RESOURCES 5.1 What documentation is available? A Users Guide and Design Document are included in the source distribution. 5.2 Is there a web page on UltraSonix? The original project web page is at: http://www.cc.gatech.edu/gvu/multimedia/mercator/mercator.html Be forwarned that it is significantly out-of-date. A page on the RAP and ICE Rendezvous efforts is at: http://www.x.org/x-agent/ 5.3 What papers have been published on the system? A subset of the papers are on the web page. These include: Technical Report GIT-GVU-92-05: Mynatt, E. D., and Edwards, W. K. "The Mercator Environment: A Nonvisual Interface to the X Window System," February, 1992. Technical Report GIT-GVU-92-28: Mynatt, E. D., and Edwards, W. K. "New Metaphors for Nonvisual Interfaces," 1992. Mynatt, E.D. and Weber, G., "Nonvisual Presentation of Graphical User Interfaces: Contrasting Two Approaches," in the Proceedings of the 1994 ACM Conference on Human Factors in Computing Systems (CHI'94), Boston, MA, April 24-28, 1994. Mynatt, E.D. "Auditory Presentation of Graphical User Interfaces, " in Kramer, G. (ed) Auditory Display: Sonification, Audification and Auditory Interfaces, Santa Fe. Addison-Wesley: Reading MA., 1994. Mynatt, E and Edwards, W. K., "Mapping GUIs to Auditory Interfaces," in the Proceedings of ACM Symposium on User Interface Software and Technology (UIST), 1992. Edwards, W. K. and Rodriguez, T., Runtime Translation of X Interfaces to Support Visually- Impaired Users," in the Proceedings of the 7th Annual X Technical Conference, Boston, MA, January 8-20, 1993. Click HERE for ASCII version. Edwards, W. K. Mynatt E., and Rodriguez, T., "The Mercator Project: A Nonvisual Interface to the X Window System," in The X Resource, Seastopol, CA. Issue #7, 1993. Mynatt, E. and Edwards, W. K., "New Metaphors for Nonvisual Interfaces," book chapter to appear in Extraordinary Human-Computer Interaction, Edwards, A. (ed.), Addison Wesley, due 1994. Edwards, W. K., Mynatt, E. D., and Stockton, K. "Providing Access to Graphical User Interfaces--Not Graphical Screens," in Proceedings of ACM Conference on Assistive and Enabling Technologies (ASSETS), Marina Del Rey, CA, November, 1994. Edwards, W. K., Mynatt, E. D. "An Architecture for Transforming Graphical Interfaces," in Proceedings of ACM Conference on User Interface Software and Technology (UIST), Marina Del Rey, CA, November, 1994.