From cbfb_gwk@selway.umt.edu Thu Jun 30 15:36:24 1994
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
[nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil])
Delivery-Date: Thu, 30 Jun 94 15:36:27 -0400
Return-Path: cbfb_gwk@selway.umt.edu
Received: by quabbin.crl.dec.com; id AA00964; Thu, 30 Jun 1994 15:36:24 -0400
Received: by crl.dec.com; id AA21488; Thu, 30 Jun 94 15:31:28 -0400
Received: by selway.umt.edu (5.65/DEC-Ultrix/4.3)id AA04518; Thu, 30 Jun 1994 13:25:49 -0600
Message-Id: <Pine.3.89.9406301342.A4437-0100000@selway.umt.edu>
Mime-Version: 1.0
From: "George W. Kerscher" <cbfb_gwk@selway.umt.edu>
To: distribution:;@crl.dec.com; (see end of body)
Subject: Math & Science Working Symposium Proceedings
Date: Thu, 30 Jun 1994 13:25:49 -0600 (MDT)
Content-Type: TEXT/PLAIN; charset=US-ASCII
PROCEEDINGS
from:
Math & Science Working Symposium
Copyright 1994 by Recording For the Blind, Inc
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:
George Kerscher
Mail: P. O. Box 7068
127 N. Higgins Avenue
Suite 202
Missoula, MT 59802
InterNet: cbfb_gwk@selway.umt.edu
Phone: 406/728-7201
FAX: 406/728-6331
PREFACE
These conference proceedings are being distributed via email, with
a follow up postal mailing. Postal mail includes the cassette tape
recordings of Dr. T.V. Raman's thesis (where requested), an MS-DOS
formatted disk with the file of the proceedings, and a hard copy of
the proceedings. The computer file of the proceedings will be
posted electronically through various sources.
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
Recording for the Blind hosted a Math & Science Working Symposium
on May 12-13, 1994 in Princeton, New Jersey. A distinguished group
of international scientists -- researchers and developers in the
fields of mathematics, computer science and adaptive technology --
met to learn about, and continue development of, the work of Dr.
T.V. Raman.
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
Dr. T.V. Raman, DEC Research Analyst
raman@crl.dec.com
Mr. David Holladay and Dr. Caryn Navy, Raised Dot Computing
dnavy@well.sf.ca.us
Mr. Joseph Sullivan, Duxbury Systems, Inc.
duxbury@world.std.com
Dr. Norberto Salinas, University of Kansas
norberto@kuhub.cc.ukans.edu
Prof. John Gardner, Oregon State University
gardner@physics.orst.edu
Dr. Abraham Nemeth, Professor Emeritus, University of Detroit
anemeth@ece.eng.wayne.edu
Dr. James Thatcher, IBM Research
thatch@watson.ibm.com
Dr. Albert Blank, The College of Staten Island
U15430@f.nersc.gov
Dr. Karen Luxton Gourgey, Center for the Visually Impaired,
Baruch College, City University of New York
klgbb@cunyvm.cuny.edu
Ms. Barbara N. Beeton, American Mathematical Society
bnb@math.ams.org
Ms. Barbara Freeze, Canadian National Institute for the Blind
lib-execdir@immedia.ca
Mr. Paul Clarke, Canadian National Institute for the Blind
lib-execdir@immedia.ca
Mr. John Cookson, National Library Service for the Blind and
Physically Handicapped, Library of Congress
jcoo@seq1.loc.gov
Dr. William Barry, Oregon State University
wab1@physics.orst.edu
Dr. Gerhard Weber, University of Stuttgart
weber@informatik.uni-stuttgart.dbp.de
Mr. Lar Kaufman, Polymedia Services
lark@world.std.com
Ms. Lynne M. Schmelz, Harvard University
lynne@harvarda.harvard.edu
Dr. Charles Halperin-Hamu, InfoDesign Corporation
charlie@idc.com
Dir.ir. J. J. Engelen, Katholieke Universiteit Leuven
engelen@cc1.kuleuven.ac.be
Mr. Richard Jones, Arizona State University
icrrj@asuvm.inre.asu.edu
Mr. John (Jay) Modi, College of William & Mary
NONE
Dr. Helmut Jurgensen, The University of Western Ontario
helmut@uwo.ca
Mr. Dan Comden, University of Washington
danc@cac.washington.edu
Dr. Chris A. Rowley, Open University
c.a.rowley@open.ac.uk
Mr. Gary R. Day, National Security Agency (NSA)
grday@afterlife.ncsc.mil
Mr. Daryl Diller, National Security Agency (NSA)
ddiller@afterlife.ncsc.mil
Dr. Mukkai Krishnamoorthy, Rensselaer Polytechnic Institute
moorthy@cs.rpi.edu
Dr. David Gries
gries@cs.cornell.edu
Mr. Douglas Forer, Educational Testing Service
dforer@rosedale.org
Dr. Arthur Ogawa, TeX Consultants
ogawa@mail.teleport.com
Mr. Chris Gray, IBM
cgray@vnet.ibm.com
Dr. David Lunney, East Carolina University
chlunney@ecuvm.cis.ecu.edu
Dr. Richard V. Cox, AT&T Bell Laboratories
rvc@research.att.com
Christopher W. Brooks, Recording for the Blind, Inc.
cwbrooks@bass.rfb.org
George Kerscher, Recording for the Blind, Inc.
cbfb_gwk@selway.umt.edu
Steve Edwards, Recording for the Blind, Inc.
sje@selway.umt.edu
Bill Robinson, Recording for the Blind, Inc
robinson@bass.rfb.org
Linden Clarke, Recording for the Blind, Inc.
lclarke@rfb.org
Sarah Johns, Recording for the Blind, Inc
sjohns@rfb.org
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.
%%% overflow headers %%%
To: Sloan Conference Participants <anemeth@ece.eng.wayne.edu>,
bnb@math.ams.org, c.a.rowley@open.ac.uk, cgray@vnet.ibm.com,
charlie@idc.com, chlunney@ecuvm.cis.ecu.edu, danc@cac.washington.edu,
David Holladay <dnavy@well.sf.ca.us>, ddiller@afterlife.ncsc.mil,
dforer@rosedale.org, duxbury@world.std.com, engelen@cc1.kuleuven.ac.be,
grday@afterlife.ncsc.mil, gries@cs.cornell.edu, helmut@csd.uwo.ca,
jcoo@seq1.loc.gov, jimagid@aol.com, klgbb@cunyvm.cuny.edu,
Lar Kaufman <lark@ora.com>, lib-execdir@immedia.ca,
lynne@harvarda.harvard.edu, moorthy@cs.rpi.edu,
norberto@kuhub.cc.ukans.edu, nrcgsh@ritvax.isc.rit.edu,
Arthur Ogawa <ogawa@mail.teleport.com>,
Richard Jones <icrrj@asuvm.inre.asu.edu>, "T. V. Raman" <raman>,
rvc@research.att.com, thatch@watson.ibm.com, u15430@f.nersc.gov,
wab1@physics.orst.edu, weber@informatik.uni-stuttgart.dbp.de
%%% end overflow headers %%%