Figure Description: RFB's logo is placed below the copyright statement. The figure shows three books with the letters "R", "F", "B" on the spine of the books. A set of headphones surround the set of books.

CONFERENCE DATE: May 12 & 13, 1994 LOCATION: Recording for the Blind, Inc., Princeton, New Jersey USA PROCEEDING DISTRIBUTION DATE: June 1994 POINT OF CONTACT:

PREFACE

We encourage further distribution, in electronic and print form, including braille and large print versions. Permission to do so is hereby given, as long as the proceedings are distributed in their entirety, on a nonprofit basis.

Table of Contents

Part 1. Executive Summary
Part 2. Plenary Session Summary
Part 3. Conference Participant Comments
Part 4. List of Conference Participants- (e-mail addresses included)
Part 5. AsTer List Server on InterNet

Part 1. EXECUTIVE SUMMARY

Dr. Raman developed AsTeR, "Audio System for Technical Readings" for his PhD thesis at Cornell University. AsTeR is a sophisticated computer program which provides access to electronic documents through an "audio formatting language" and a speech synthesizer. AsTeR's advantages are many. By exercising control over pitch, loudness, pauses and other elements of sound, the system can speak the most complex mathematical expressions in a consistent and understandable manner.

The Symposium was underwritten by a grant from the Alfred P. Sloan Foundation.

Development requirements are in the areas of User Interface, Porting, and Data Structures. Recommendations follow.

The User Interface should be consistent across all platforms, and be interactive for read, write and edit. Its control and navigation needs to be simple and easy. Input must be supported from keyboard and alternative adaptive equipment, 6 and 8 dot Braille, for example. All the features found in modern on-line search and retrieval systems -- sophisticated search, navigation, placemark and notetaking capabilities -- should be included.

The output modality of the user interface should include, but not be limited to, the simultaneous use of formatted audio, refreshable Braille, text to speech, non-speech audio, graphics (sound graph), scalable large character display, and hard copy output (Braille and print). This will facilitate communication without regard to disability.

The development of each interface needs to follow a set of guiding principles, such as those developed by Dr. Abraham Nemeth for the Nemeth Braille Code.

Several steps in the development of the user interface include the development of a Braille output module that will interface with the AsTeR front end, and the research of techniques for synchronizing the focus of the currently presented object in various output modalities.

Recommendations about Porting AsTeR include Rensselaer Polytechnic Institute (RPI) setting up an AsTeR server in a remote client server arrangement with an Emacs interface. Porting AsTeR to a more widely available version of Lisp will be worked on, as well as setting up an AsTeR processor at Recording for the Blind to create demonstration audio tapes of selected technical titles. An on-line manual for use and extensions of AsTeR will be written, and it is planned to eventually port AsTeR to the C language, making the system independent of Lisp and Unix.

Data Structures development will include testing SGML input to AsTer. Work with ISO 12083 committees on the semantic additions to the 12083 math fragment, and user defined semantic constructs will be explored. Experiments will be conducted with the 12083 math fragment as an input to AsTeR to determine 12083's strengths and weaknesses.

Guidelines will be written for providing the semantics behind the LaTeX macros.

Structured document files are crucial. Qualification tests will be created to determine the usability of structured document files as provided by publishers and other content-providers. The tests' suitability for use by other organizations will be examined as well.

Publishers and other content-providers need to understand the need for well structured files, and a program of education will be initiated. Some of their documents will be processed and taped AsTeR renderings will be sent to them for review as part of this program.

The group recognized the need to develop, disseminate and maintain a resource list of products, components, and research efforts currently underway, and also to encourage the development of an accessible graphical calculator, to level the playing field for persons with disabilities studying math and science.

At the wrap-up session of the Symposium leaders emerged for each of the working groups. The group went on to identify a number of specific actions for the next six months.

Communication will be facilitated through the InterNet, for people working on specific projects as well as others who want to keep up with developments.

Part 2. Plenary Session Summary

Math & Science Working Symposium
May 12-13, 1994

PORTING
Working Group Leader: Dr. T.V. Raman

Short-term:
1. Rensselaer Polytechnic Institute to set up an AsTeR server for use in a remote client-server arrangement with emacs interface.

2. Oregon State University will begin working on porting ASTER to another version of LISP

Mid-term:
Create an on-line manual for use and extensions of ASTER.

Long-term:
Port to language independent of LISP and UNIX, preferably C or C++ language.

USER INTERFACE
Working Group Leader: Dr. John Gardner

1. User interface should be consistent across all platforms. The control and navigation of the user interface should be simple and easy.

1.1 The development of the user interface should follow a set of guiding principles, such as those developed by Dr. Abraham Nemeth for the Nemeth Braille Code.

1.2 User interface should include a complete suite of features that are found in modern on-line search and retrieval systems, including sophisticated search, navigation, placemark and notetaking capabilities.

2. Output modality should include but not be limited to formatted audio, text to speech, non speech audio, graphics (sound graph), scalable large character display, hard copy output (Braille and print), and refreshable Braille. This should remain open and extensible for further modalities.

3. Interface should facilitate communication between people without regard to disability, for example enabling simultaneous use by a student and a teacher.

4. Interface should be interactive (read, write and edit). Input should be supported from keyboard, and alternative adaptive equipment, e.g., 6 and 8 dot Braille input, etc. These input devices should also be usable for navigation.

5. Undertake the development of a Braille output module that will interact with the ASTER front end.

6. Research the techniques for synchronizing the focus of the currently presented object in various output modalities.

DATA STRUCTURE
Working Group Leader: Dr. Art Ogawa

1. Write guidelines for providing the semantics behind the LaTeX macros.

2. To determine its strengths/weaknesses, experiment with the ISO 12083 math fragment as an input to ASTER.

3. Educate publishers and other content-providers about the need for well-structured files.

3.1 Process documents and send taped ASTER renderings to the provider for review.

4. Create a qualification test to determine usability of structured document files.

4.1 Determine the test's suitability for use by other organizations.

5. Work with ISO 12083 committees on the semantic additions to 12083 and user defined semantic constructs. We need to participate in those extensions.

GENERAL RECOMMENDATIONS
1. Develop, disseminate and maintain a resource list of products, components and research efforts currently underway.

2. Encourage the development of an accessible graphical calculator.

Part 3. Conference Participant Comments

The report of the plenary session was sent out to conference participants. Each person was given an opportunity to comment on the results. The recommendations are listed and their comments follow their name.

Summary

Comments:

George Kerscher
Feedback from the conference participants indicated they were very pleased with the results. The open flexible format was conducive to a working meeting. Most people felt that another two-day conference should be held in the Spring of 1995.

The next conference should again be a working meeting to extend and advance the work laid out here. It was recognized that the conference should be primarily a working meeting, but that there are many advantages in having interested parties join the conference.

Dr. Helmut Jurgensen
AsTeR is a highly significant step towards the translation of text marked-up for typesetting into a different medium. In its present form, it is a proof-of-principle system the potential, usability, and limitations of which are unclear. Making AsTeR available via the Internet will serve as a very useful field test regarding user acceptance and at the same time point to required changes and standards.

Specifically, as far as its capability of dealing with TeX and LaTeX is concerned, AsTeR leaves the onus of dealing with TeX's mechanism for macro definitions to the user (a choice we rejected in the context of TeX-to-Braille translation already several years ago; details available from H. Jurgensen) and, moreover, assumes a standard semantics for existing macros. To me this seems to be only acceptable as a short-term solution (ad hoc macro definitions in documents are not an exotic exception, but very common); on the long run, a more in-depth approach will be needed; this could require changes to existing mark-up systems and the respective software, but might be easier and cheaper to implement than enforcing standards based on the capabilities of the present version of AsTeR.

A detailed document would be required specifying AsTeR's capabilities and, more importantly, limitations regarding LaTeX and plain TeX. Dr. Raman's thesis is not detailed enough in this respect. This document would have to examine typical and complicated cases of macro definitions, their purposes, and to which extent AsTeR can be made to handle these properly or where additional differentiating mechanisms in TeX would be required to aid AsTeR and possibly other rendering systems.

In porting AsTeR, findings from these investigations should be taken into account. Just porting the present system without a careful evaluation of its features and its goals may lead to the undesirable creation of a de facto standard far short of what could be achieved.

From a more long-term perspective, a precise statement would need to be worked out specifying which information should be explicitly available in a document for such a document to be rendered automatically for the blind, the deaf-blind, etc. This problem should be seen in the general context of current multi- media and multi-purpose information processing research and technology development.

PORTING
Working Group Leader: Dr. T.V. Raman

Short-term:
1. Rensselaer Polytechnic Institute to set up an AsTeR server for use in a remote client-server arrangement with emacs interface.

COMMENTS:

Dr. T.V. Raman

this is probably the most exciting proposal that emerged over the two-day symposium. It is concrete and therefore implementable. It can show results in the short-term, but also has considerable potential in evolving into a client-server talking library system over the long-term. I see the following challenges: + Design and implement the server: Will require some work to build a server front-end that can interface with AsTeR --- this should be easy. The server should eventually be able to serve documents as well as format a document supplied by a client. This means that server will eventually end up looking like a library front-end. This could be a challenging research problem.
+ Client side: The easiest thing to get off the ground is a client that assumes the user has a dedicated Dectalk-like device for speaking the audio-formatted text, i.e., if the user also wishes to use a screen-reading program, such a screen-reader will speak through a separate synthesizer. This constraint will make the design of the initial set of clients feasible in the short-term, and allow us to demonstrate proof of concept.

Dr. Helmut Jurgensen
User comments on AsTeR and the interface should be solicited. Control information about the type of TeX and LaTeX documents used should be collected.

2. Oregon State University will begin working on porting ASTER to another version of LISP

COMMENTS:

Gary Day
I believe that this should read: Oregon State University will begin working on porting ASTER to a nonproprietary (public domain) version of LISP.

Dr. Helmut Jurgensen
The version of LISP should be running on many platforms and should be cheap (what about Portable Standard Lisp (Utah)?).

Dr. T.V. Raman
AsTeR is currently implemented in Lucid Common-Lisp and CLOS. Porting to other lisps, especially a public-domain lisp will allow AsTeR to be ported to multiple platforms, including PC's. We envision AsTeR running on a PC running a version of UNIX, e.g. LINUX, along with a version of lisp-clos. Other options include:

+ Schemetoc: Will require porting AsTeR to Scheme. This would require considerable effort, but the result would be equivalent to having ported AsTeR to C, something which would have required far more effort.
+ CLICC: Common Lisp to CC. This is a public-domain lisp- clos to C convertor. It's available on the Internet, and according to the documentation is capable of translating lisp-clos programs to C. The resulting C code can be compiled on any machine.

Mid-term:
Create an on-line manual for use and extensions of ASTER.

COMMENTS:

Dr. T.V. RAMAN
I think this needs to go in with the short-term goal. At present the only documents describing AsTeR are my thesis (which is comprehensive) and my conference publications. A user-manual should be derivable from the thesis which is itself written in LaTeX.

Long-term:
Port to language independent of LISP and UNIX, preferably C or C++ language.

COMMENTS:

Gary Day
Currently, the EMACS editor is an essential tool for using AsTeR. I think that this requirement can be relaxed to permit the use of other editors. With regard to converting to C or C++, I wonder if GNU LISP is itself portable to other operating systems, thus obviating the need to convert AsTeR. We didn't really discuss this in our group.

Dr. T. V. Raman
Yes, a long-term goal. Unfortunately, it could take a long time.

Dr. Helmut Jurgensen I suggest to wait with this until more experience with the present system has been gathered.

USER INTERFACE
Working Group Leader: Dr. John Gardner

1. User interface should be consistent across all platforms. The control and navigation of the user interface should be simple and easy.

COMMENTS:

Dr. T.V. Raman
I have one global comment for this entire section, which also expresses my most serious concern. Both at the symposium, and now as I read the executive summary, it was/is unclear as to what the interface we were designing would interface to. Is it AsTeR as it stands? Is it something that will follow AsTeR? Is it something radically different, and if so, who is going to build this radically different beast whose interface we are designing?

I agree fully with everything that has been set forth as desirable in this section. However, very little has been said on how these goals will be achieved. What we have defined below is the holy-grail of user-interfaces, something that every computer company would love to have, but does not know how to build.

Gary Day
It is easy to state that, the interface should be simple and easy to use, but given that mathematical typography is in and of itself a complex procedure, what is meant by "easy"? I think that we should start by clearly stating the objective.Do we want a tool for doing mathematical transcription, or do we want a tool for doing mathematical analysis? stated another way, is the objective, to allow users to peruse mathematical documents that have been professionally typeset with TeX and LaTeX or other typographic systems, or is the purpose to provide the user with a tool for preparing his own mathematical analysis? Observe that a mathematical typographer tends to use special typographic mechanisms (such as bold face symbols) but a mathematician working out a math problem by hand doesn't usually bother with such formalities.I think that we want an interface that will allow us to do both things, but how a simple interface can be created when one doesn't even exist for people with out disabilities is a challenge indeed.

1.1 The development of the user interface should follow a set of guiding principles, such as those developed by Dr. Abraham Nemeth for the Nemeth Braille Code.

COMMENTS:

Dr. Helmut Jurgensen Clearly, using general guiding principles is a must. Specifically, we found that the Nemeth code itself --- when used in the context of automatic translation (for which it was not designed) --- causes some severe problems; as far as mathematics Braille is concerned, a careful revision of this code would be required. Moreover, there are other codes for mathematics and science. In order not to exclude these, an intermediate interface layer has to be provided.

1.2 User interface should include a complete suite of features that are found in modern on-line search and retrieval systems, including sophisticated search, navigation, placemark and notetaking capabilities.

2. Output modality should include but not be limited to formatted audio, text to speech, non speech audio, graphics (sound graph), scalable large character display, hard copy output (Braille and print), and refreshable Braille. This should remain open and extensible for further modalities.

3. Interface should facilitate communication between people without regard to disability, for example enabling simultaneous use by a student and a teacher.

COMMENTS:

Gary Day
This alludes to the possibility of generating an interactive previewer as part of AsTeR. A question that I have is: is it necessary for the video output rendered by such a previewer need to be a faithful representation of the corresponding printed output generated by Plain TeX or LaTeX, and if so, do the data structures of AsTeR currently retain sufficient metric information to do this?

4. Interface should be interactive (read, write and edit). Input should be supported from keyboard, and alternative adaptive equipment, e.g., 6 and 8 dot Braille input, etc. These input devices should also be usable for navigation.

5. Undertake the development of a Braille output module that will interact with the ASTER front end.

6. Research the techniques for synchronizing the focus of the currently presented object in various output modalities.

DATA STRUCTURE
Working Group Leader: Dr. Art Ogawa

1. Write guidelines for providing the semantics behind the LaTeX macros.

COMMENTS:

Dr. T.V. Raman
A good reference is the final section of the chapter on recognizing document structure in my thesis.

Dr. Helmut Jurgensen
I am afraid this is not going to be enough when it comes to complicated macros; hence my request for a document specifying the limitations of AsTeR with respect to TeX and LaTeX precisely. Moreover, LaTeX in its present form is by no means acceptable as a yardstick. Both plain TeX and the forthcoming (radically different) version of LaTeX should be considered.

2. To determine its strengths/weaknesses, experiment with the ISO 12083 math fragment as an input to ASTER.

COMMENTS:

Dr. T.V. Raman
As soon as I get a sample, either a latex document generated directly from a document encoded using ISO 12083, or something equivalent, I can run AsTeR on it.

3. Educate publishers and other content-providers about the need for well-structured files.

3.1 Process documents and send taped ASTER renderings to the provider for review.

COMMENTS:

Dr. Helmut Jurgensen
At present, I think this should serve a dual purpose: alert authors and publishers to the needs of the disabled; but also alert those working on the redesign of AsTeR and on similar systems to the realities and complexities of document processing and publishing. The AsTeR system in its present form is not ready to serve as a quasi-standard.

4. Create a qualification test to determine usability of structured document files.

4.1 Determine the test's suitability for use by other organizations.

COMMENTS:

Dr. T.V. Raman
I'm unclear as to what this means.

George Kerscher
In some states computer files are required to be delivered by publishers. Currently there is no way to test the quality of the files being delivered.

5. Work with ISO 12083 committees on the semantic additions to 12083 and user defined semantic constructs. We need to participate in those extensions.

COMMENTS:

Dr. T. V. Raman
Do this within the framework of ICADD and HTML+.

Dr. Helmut Jurgensen In general, input from the handicapped into the design and standardization process of information processing tools should come much earlier than it used to. This should go beyond the ISO committees mentioned.

GENERAL RECOMMENDATIONS

1. Develop, disseminate and maintain a resource list of products, components and research efforts currently underway.

2. Encourage the development of an accessible graphical calculator.

Part 4. List of Conference Participants

Part 5. AsTer List Server on InterNet

A list server on InterNet is set up to facilitate communication about developments of AsTer. For people working on specific projects, a separate working group list has been set up.

To subscribe to the general interest mail list, send mail to:

listproc@u.washington.edu

In the body of the message, enter the command:

subscribe aster-l Firstname Lastname

and send the message. Make sure that any .signature files or any other text is removed from the body of the message, as the list processor will attempt to run these lines as list processor commands. You should receive a response to your subscription request that will indicate your list password.

For more information on this list server, send mail to

listproc@u.washington.edu

In the body of the message, send the command

help

for more information on the listproc server.

Working group members will be provided information about the working group list server.

Return to SEM Page

Home