[ossrp-control] Re: What Is A Screen Reader?

Hi Jamal,

No, I haven't touched a Mac in quite some time. From what I've seen it's got something of a mixed response. I do think it's got one or two good features of the limited set of features I've heard about. One particular one that I quite like, as I've been advocating the same thing for both web browsing using Mozilla, and for inclusion as part of the W3C's SVG specification, is directional navigation. If you can move focus in a given direction, rather than simply through a pre-defined linear sequence, you can get some idea of the directional relationships between controls and start to access the semantic content encoded through this technique. There's also situations where directional navigation will enable a user to skip groups of controls, making navigation a little quicker than the conventional linear sequence. I don't know whether this made it into the final cut of features, as I heard about this last year whilst I was a participant in the discussion on Mozilla.

Will
----- Original Message ----- From: "Jamal Mazrui" <Jamal.Mazrui@xxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Thursday, June 02, 2005 5:04 PM
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Will,
I'm curious whether you've had a chance to assess Voice-Over on the Mac,
and if so, what you see as some of the pros and cons of this recent
approach to GUI access.

Jamal



-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
Sent: Thursday, June 02, 2005 11:52 AM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Dennis,

In part I agree with you.  The extent to which features from other
screen
readers need to be somewhat cloned comes down to psychology.  If we do
things differently, and we also give the user motivation, in the form of

rewards and benefits outweighing the work in learning the new system,
then
the user should be motivated to learn the new system.

I'm a bit reluctant to simply create a clone of JAWS, Window Eyes and
Hal,
as I  firmly believe that better screen readers can be created than
those
that currently exist.  There's techniques available for gaining access
to
diagrams and images, as well as for giving the user more information
about
wwhat's on the screen, which will lead to the user having a better
understanding of what actions they should perform when.  All in all, I
think
that computer use can be made easier, simpler, quicker and more
accessible
than it currently is, and the reason it hasn't happened already with the

other screen readers is more for commercial reasons rather than the myth
of
technical limitations that is often presented by the spin doctors of the

access technology vendors.

So, if there's ways to do things better than the existing screen readers

then I would really like to take those.  One fundamental aim of this
project
is to investigate and research techniques for improving screen readers,
it's
mission isn't really to create a JAWS clone, any way, bugs are hard to
clone
:-).

Will
----- Original Message ----- From: "Dennis van der Heijden" <dennis.vanderheijden@xxxxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Wednesday, June 01, 2005 9:47 PM
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi David,

Copyright a good point, but HAL, ZoomText, Windows-Eyes and Jaws have
things
in common... by copying the features of each other... but naming them
different. So don't forget to do the same ;-)

Shortcut keys that are difficult to reach I understand and agree they
should
be fully customizable. But work with well know predefined sets (Jaws,
Windows-Eyes, Zoomtext key. Just like Dolphin did in there 6.5
releases.
They have all shortcut of competitor product in there and you can
select 
that shortcut set as well (for transition of other products).

Which product will be developed first (the screen-reader I guess) on
what 
platform etc... where can I find that info?

Dennis

-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of David Lant
Sent: woensdag 1 juni 2005 22:01
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?

Hi Dennis,

Just to pick up on your point about not changing the layout, and to
use 
JAWS.... I'm not exactly sure what you're referring to.  But if by any
chance you're referring to things like the JAWS Control Panel or other


parts
of the JAWS user interface, then I don't think copying it is an
option.
There are such things as copyright restrictions, and as has been
pointed 
out
more than once, personal preference.  Keyboard shortcuts, just as they
are
in JAWS, should be customisable, so that the user can set them how
they
like. Choosing a good set of starting values for keyboard commands is
a
worthwhile exercise. But my own view is that the JAWS approach is not
a
good one, and I defy some people with only the regulation number of
arms 
and
fingers to physically reach some of those keyboard combos on non-US
keyboards. <grin>  Oh, and using your nose is not allowed!

In terms of laying out the information from the Windows or operating
system's GUI, then that needs to be thought through carefully.  I've
seen 
advantages and disadvantages to the decision to reformat the screen
presentation for use by screen reader users.  An advantage, is that
you 
can
allow the user to do things with the information that would otherwise
be
more cumbersome, if not impossible. However, it does also introduce
the
possibility that the screen reader might get the reformatting wrong.
A 
simple example is that on all the development systems I've tried at my
workplace, creating a basic web form using Visual Studio.NET is all
very
good. But JAWS, for some inexplicable reason, insists on rendering
the 
entire page upside-down.  Not good. <smile>

All the best,

David


-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Dennis van
der 
Heijden
Sent: 01 June 2005 07:35
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi there,

My name is Dennis van der Heijden from the Netherlands and I am new to 

this
forum... but ready to jump right in. My job is to write on AT product
and 
watch the market for AT (computer related) products.

The problem with screen-readers is that all layers, catching XML etc.
never
worked in the past, because no programmer follows a guideline. So in
order 
to 'catch' the text on a the screen (for, reading, Braille of
magnification)
they all now use the DCM (Driver Chain Manager)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc/h
tml/
atg_driverchain.asp if the software runs on a Microsoft platform. This
is 
the location where your software should hook into the video driver and
extract the data from. Not from applications, webpages etc. If you
want a
uniform system, hook into the DCM that is out there and not think of a
new 
guideline or one code that only some applications use.

When you got the images transformed into text, SAPI speech is the most
supported so again please stick to a standard (even if it is Windows).

Scripting is great I indeed would create an API and a wizard. The
wizard 
allows a user to adjust web pages, programs etc. (with own tags for
fields,
buttons, images, links etc).

Last suggestion of this newbie here. Don't change the layout, but use
a
simulair layout. Might not be revolutionary but just stick to things
that 
work in Jaws and just copy it. They really know what their doing and a
complete new GUI will take lots of training (difficult to support).
Maybe 
even use the same shortcut keys... and final... make a multi-lingual
system
from start (let others translate if they wat... nice job for me ;-)

I fully support inexpensive AT program, the need is everywhere in the
world
(low-tech) AT solutions that run on simple machines with little fancy
features... just do the basic right!

Good luck and if you need me for simple stuff (I can't program
anything 
but
my microwave) let me know,

Dennis



-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of rjc
Sent: woensdag 1 juni 2005 19:53
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?

There seem to be two diverging needs here:
1. Do everything *right* from the outset. This is fine until the
application

author decides he doesn't want to right his widgets using UI
automation or 
MSAA or Swing or whatever API is required to maximize accessibility.

2. So now we have hacks which can try and extract information from an
application which doesn't want to provide it in the way required, or
hacks
which give us keyboard access where none is provided by the developer, 

etc.

It seems that both these behaviors are required in today's world in
order 
to

make a screen reader which is truly useful.

-- Rich

----- Original Message ----- From: "Travis Roth" <travis@xxxxxxxxxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Tuesday, May 31, 2005 11:53 PM
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Sina,

Agreed, the screen reader is going to need to be scriptable. I like
the 
idea
of an API. There is a lot to be said about doing accesibility
correctly,
such as implementing a correct MSAA client, and a correct UI
automation
client. However I am quite concerned about the many programs and
vendors 
who
do not and liley will not start conforming with any guideline so that
if a 
user really has to use the product, a hack of sorts still has to be
created,
ala today's JAWS scripts. That's what makes JAWS popular at this
time,is 
you
can force it to work with programs that don't conform to accessibility
guidelines... At least sometimes.


**  Travis Roth
www.TravisRoth.com
travis@xxxxxxxxxxxxxx


-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Sina Bahram
Sent: Tuesday, May 31, 2005 10:25 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Jamal,

That's true, but who is to decide which one of those pieces of
information 
is important?

I thought the O in this project stood for Open?

Why not let the user decide that ...

I'm not being abrasive, honestly.

But even after my long phone conversation with Will ... I just really
don't
like the idea of not having a programmatic way of scripting this
thing. 

Take care,
Sina

________________________________

From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Jamal Mazrui
Sent: Tuesday, May 31, 2005 4:18 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Will,
I agree that a screen reader will often have to guess
probabalistically, 
rather than be able to know determinatively, all the semantic meaning
intended by visual aspects of layout, including spacing, fon choices,
etc.
My hope though is that we develop the huristic analysis capability as
much 
as possible, separating what is functionally significant from visually
decorative or at least redundant.

What is the purpose of the dialog? What task does it enable the user
to
accomplish? These are more importantquestions, in my opinion, than
what 
are
all the visual effects presented to a sighted user?

Jamal
----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
Sent: Sunday, May 29, 2005 2:39 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Jamal,

It's difficult to quantify the semantics conveyed by a particular
physical 
encoding scheme in a general sort of way.  There's multiple
characteristics
of space, namely position, proximity and size.  These can convey
semantics,
or they may not, in one scenario, size may be used to convey relative
importance, whilst in another scenario it may be used to differentiate
between two or more groups of items by having the items in each group
a
different size compared to those in another group. This is also true
for 
other mechanisms by which semantics can be encoded visually, such as
color,
font, and font attributes such as bold, italic, etc.  So, it's very
difficult to determine what semantics, if any, are encoded using a
particular technique in a scenario devoid of context.

There's a couple of ways that this can be presented to a user.
Firstly, 
you
can have some form of intelligent system that will extract the
semantics
from the visual presentation and convey the semantics to the user,
either 
in
raw form using additional spoken words, or by altering the attributes
of 
the
spoken text associated with the item for which the semantics are being
conveyed.  The major drawback to this is that it's very hard to create
the
intelligence to do this in an autonomous manner, and so the system
would
have to be taught the relationships between encoding techniques and
the 
semantics they convey in the various different contexts.

The second method of conveying the content is to take the encoded
semantics,
e.g. spatil position, color, etc. and convey this to the user but
altering 
it's physical presentation.  So, instead of conveying spatial
relationships
through parallel presentation of different elements, you could convey
the
spatial positioning of each element, and thus the rrelationship,
through a 
series of spoken co-ordinates, which would still leave space as the
encoding
technique for conveying semantics, but would modify the physical
representation of that encoding to speech.  A similar thing could be
done 
for color, where instead of altering te wavelength of the displayed
element,
you could just use speech to say the color of the item, which would
still 
leave color conveying the semantics.  Alternatively, you could have
parallel
auditory displays that use different frequencies/wavelengths to
present 
the
information.

That's just some of the ways in which it could be done, and they're by
no 
means designs.  One point that I think needs to be born in mind when
thinking about this sort of thing is the limitations of speech.
Firstly
it's serial in nature, and so the more you produce in terms of speech
the
more time it takes someone to receive that semantic content, and
secondly,
people have a short term memory limit of between five and nine chunks
of
information, at least according to George Miller's 'Magical number
seven,
plus or minus two' theory. Speech being serial in nature doesn't
allow a
user to very easily quickly jump back to a position to review the
content 
at
that position, so people tend to have to remember the content as they
go, 
and this is stored in their limited short term memory.

I think it's something that needs some careful consideration to come
up 
with
the optimal design.

Will

----- Original Message ----- From: Jamal Mazrui <mailto:Jamal.Mazrui@xxxxxxx>
To: ossrp-control@xxxxxxxxxxxxx
Sent: Thursday, May 05, 2005 9:22 PM
Subject: [ossrp-control] Re: What Is A Screen Reader?

Good point. That is a different, more complex example, but certainly 

such
scenarios are also common.  I think the scenario that I described
often 
occurs with order forms on the web, typically asking for contact and
credit
card information in a familiar pattern.

In evaluating this issue, at least two questions seem relevant: (1)
what 
does spatial information convey about the function of the dialog? and
(2) to the extent that functional rather than asthetic information is
being
conveyed, what is the best way to achieve an equivalent result
nonvisually?


If there are optional subgroups of fields, then tabbing through all of 

them
is, indeed, inefficient.  To achieve productive data entry, let us
separate
function from presentation.  The blind person probably does not need
to
know, for example, how many pixels separate controls in order to judge 

which
ones are part of the same subgroup and which are part of another.  The


fact
that the border of group boxes uses a 3D rather than simple style is
inconsequential.  The objective is to enable the blind person to
identify
and navigate to the different subgroups. For the screen reader user,
a
multi-page tab dialog might be the most efficient solution rather than
a 
single page dialog where subgroups are indicated by spatial proximity.

Jamal


-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of David Lant
Sent: Thursday, May 05, 2005 3:46 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Jamal,

Broadly I understand your point.  However, there are situations where
simply
going sequentially through the items in a dialog is not the process
required
for daily use of a facility.  If, for example, your job is processing
pay 
claims, and allocating charge codes to the relevant portions of hourly
rates, overtime rates, expenses and so on, it would, and does, become
extremely tedious having to tab through all the fields that may have
to be 
displayed to inform you what needs to be done.

It may be much quicker, if the pieces of information are all grouped
in 
one
control group, and the fields you need to fill in are in an adjacent
one.
There may very likely be other data on the screen at the same time,
which
don't relate directly to the job in hand. Sighted people visually
skip 
over
that stuff, such as the box at the top giving the identification
summary 
of
the person and their pay reference etc.  They see that the boxes they
need
to work with are all in two rectangles on the right of the screen, one 

above
the other, and so visually concentrate on those.  They will glance
through
the information in the first box, to identify the hours being claimed,
and
will then click in the second box to place an insertion pointer so
they 
can
type in the relevant charge codes.

For a blind person to do this, they would need to have a quick way to
rapidly get to the information in the upper right box, and read it.
Then, 
to
equally rapidly, move to the lower right box, in order to start
filling in
the information. It is true that the fact that these boxes are on the 

right
of the screen may be of no significance whatsoever as far as both the
blind
and sighted person are concerned.  But the significance is that they
separate out the information that has to be dealt with, so that the
details
on the left of the screen can be largely ignored unless something
special 
turns up.

This, I think, is the kind of scenario that Will is talking about. Not 

just
the fact that address fields are grouped together, but that you may
need 
to
perform specific, and isolated tasks on that group, separate from the
rest 
of the data on the screen.

All the best,

David

-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Jamal Mazrui
Sent: 05 May 2005 08:21
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Will,
I agree that spatial relationships can and do convey a lot
of information to sighted users.  I was not arguing that visual
placement 
is
generally irrelevant, but maintain that it can be so for blind users
where
it does not affect the interface we experience and the functionality
of 
the
task at hand.

For example, if the purpose of a dialog is to retrieve
typical contact information (name, address, phone, etc.) through a
well-understood set of fields, then it may be irrelevant to the blind
user
where the controls are placed, as long as they speak properly. The
layout 
of the dialog is not an end in itself, but a means to an end, that of
gathering the data for a contact record.  The database does not care,
and
does not track, where the controls were placed in the input dialog
that 
gathered the data for the record that was saved.

To elaborate, I might press tab successively hearing fields like
"First
name", "last name," etc., filling each one in, including reviewing the 

data
in each edit box.  If the tab order is logical and the field name and
current value speak as expected, than it does not matter to me how the
fields are aligned, what fonts are used for field names, what point
size 
the
entered characters are, etc.

Sighted users, on the other hand, are affected by such
characteristics.
Even if the tab order is the same, logical sequence, they will be
confused 
if the "City" field is placed above the "First Name" field. If a few
fields
are cramped together in one corner of the dialog in an unpleasing
manner 
aesthetically, their productivity will be reduced because of the
disorientation they experience, etc.

Jamal

-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
Sent: Wednesday, May 04, 2005 4:25 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Jamal,

"As a blind user, placement
can actually be irrelevant, having  no effect on functionality."

Based on psychology, semiotics and communications theory, I would have
to
disagree with that statement. A control's relationship to other
controls
and it's absolute positioning can be sources of semantic information
about
that control's functionality. For example. buttons grouped together
may
have similar functionality, buttons placed next to a list box may
perform 
an
action on that list box or it's selected index.  On the web, a row of
links
placed in vertical alignment at the top of a page are often used as a
quick
navigational group of links.

So. spatial relationships and absolute positioning can add a lot of
meaning
regarding functionality beyond that conveyed by a simple text label.
Users
can, and often do, work out the full semantic nature of a control, but


this
is often through trying out the control and seeing what it does, which
is
inefficient at best, and possibly disasterous at worst, imagine
deleting 
something that you didn't actually mean to delete.

Will

----- Original Message ----- From: Jamal Mazrui <mailto:Jamal.Mazrui@xxxxxxx>
To: ossrp-control@xxxxxxxxxxxxx
Sent: Monday, May 02, 2005 2:41 PM
Subject: [ossrp-control] Re: What Is A Screen
Reader?

Just an observation to share.

In trying to program dialog boxes under Windows, I
have experienced the situation where something I developed worked well


with
a screen reader, yet I subsequently discovered that it was almost
unusable 
for a sighted person.  A screen reader can tab from one control to
another,
and as long as each control is properly labeled and otherwise voicing
as 
one
would expect at the time it has focus, then the controls in the dialog


serve
their purpose.  It may be the case, however, that the controls are
placed 
in
visually peculiar, unbalanced, or overlapping places on the screen,
thus 
making the dialog difficult for a sighted user.

As a blind developer, I need to know the location of
controls so that I can meet the needs of both sighted and blind users.
As 
a
blind user, placement can actually be irrelevant, having  no effect on
functionality.

Regards,
Jamal
-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Lyn Eagers
Sent: Saturday, April 30, 2005 11:19 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: What Is A Screen
Reader?


Hi Will and Others,

Will, I found your description of what a screen
reader is quite interesting.

I train people to use screen readers and, from my
experience, some blind folk are interested in where things are on the
screen
(spacial perception) and others are not.  In particular, those who
have 
had
sight and were extremely visual people find it important to know where
things are.  Some, and I say some, so therefore not all, long term
blind 
people don't seem to be interested in the spacial factor.

I am a long term blind person and have always tried
to grasp a mental picture of what is on the screen and where -
probably
because I teach both kinds of blind people and sometimes assist
sighted 
folk.

Anyhow, I thought I'd share my experiences with you.

Cheers,
Lyn

----- Original Message ----- From: Will Pearson
<mailto:will-pearson@xxxxxxxxxxxxx>
To: ossrp-control@xxxxxxxxxxxxx ;
uvip@xxxxxxxxxxxxxxx
Sent: Sunday, May 01, 2005 11:58 AM
Subject: [ossrp-control] What Is A Screen Reader?

Hi,

I thought I'd share my, rather academic, view of
what a screen reader is.  It offers a little glimmer into what screen
readers could potentially do, and some of the pitfalls that the
current 
crop
of screen readers have fallen into.  All this is from the viewpoint of


human
computer interaction, psychology and communications theory.

OK.  So, what is a screen reader?  Well, it's
actually a lot more than people often assume it is.  It's not just
something
that grabs the text from the screen and reads it to you, well, at
least it 
shouldn't be, it is in fact the interface by which user and machine
communicate semantic meaning, relating to thoughts, concepts, actions
and 
states.

So, how did I arrive at this view?  As some of you
may know, I've been researching into semantics and their role in
software
interfaces for a while now. During this time, it's become apparent
that
software interfaces are just intended to communicate semantic meaning,
but 
as we're not capable of extr sensory perception and telepathy with the
computer, we need some way to indicate our thoughts, concepts,
actions, 
etc.
to the computer, and vice versa.  The way this is visually done is by
placing elements on the screen, such as icons, buttons, etc. and
having
their shape, colour, position on screen and relationships to one
another 
act
as encoding channels by which the semantic meaning is conveyed.  Users


then
just point to an object, conveying the semantics of which element they


would
like to interact with, and either click it or select an action to
perform 
on
it from a menu.  All this is just a form of physical encoding of the
semantic meaning between user and machine and vice versa.

So, as a screen reader is a replacement for the
visual interface, it's role is simply to act as an interface between
user 
and machine and convey the semantic meaning generated by the machine.
However, there's a nasty twist, and that is that a screen reader has
to 
get
the semantic meaning that it is to communicate to the user from
somewhere.
As the screen reader has no access to the internals of the machine,
it's
only available source of semantics that the machine wishes to convey
is 
the
visual interface, which uses encoding techniques such as colour,
shape,
position and spatial relationship to convey it's semantics. So, a
screen 
reader should really be about extracting the semantics from the visual
display and encoding them in a non-visual form suitable for a blind
user,
and this is where current screen readers fall down. To maintain
accurate 
and efficient communication with the user, all the semantics that are
conveyed visually need to be conveyed to the user.  This includes
things 
like spatial positioning and spatial relationships between interface
elements, things that are currently lost to the user when they are
using 
one
of the current screen readers.  If this were to happen, then the
number of
errors, and according back-tracks and reissuing of commands that go
along 
with errors, would decrease, and screen reader users would be more
efficient
beasts.

I haven't gone into design specifics, as they're for
another day, and these can dramatically affect efficiency as well, but
that's my thoughts of what a screen reader should be doing.  In
focusing 
on
the semantics, then it's likely that through the use of semantic
translation
access to all those difficult accessibility problems could be
increased. 

Will



To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes



To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes


To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes

To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes

To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes

To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the


quotes




To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes


To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes



To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes

Other related posts: