<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Timothy,<br>
<br>
In a highly-line-oriented world (which, perhaps many OLPC apps of
interest are), going by point size or by your magnification increments
might be workable. I am thinking of the GUI in general, and of the
software being driven not necessarily only by focus tracking (e.g. a
"lens" that might also be tied to the mouse). Also note that more
generally in text (e.g. an ODF text file), line boundaries might not be
uniform, with some paragraphs having extra space above/below, etc.
Therefore, I imagine for the most smooth and satisfying experience, you
would want the sort of transforms available under something like OpenGL.<br>
<br>
But fundamentally these are just "armchair programming" thoughts.
Until someone does a prototype that we can play with, it is simply
speculation.<br>
<br>
<br>
Regards,<br>
<br>
Peter Korn<br>
Accessibility Architect,<br>
Sun Microsystems, Inc.<br>
<br>
<blockquote
cite="mid:650efde80802112239l76206f23sd57aaf1c76983173@mail.gmail.com"
type="cite">
<pre wrap="">On orca: I tried orca the day that I sent that email. However I did
so on an ubuntu box which I hardly ever use and have not updated for
about a quarter.
On the squished behavior, I had anticipated that response. I would
imagine that since the Sugar Activity will already be providing text
to the screen reader software, that the magnifier could use this text
as well, and instead of doing bitmap magnification, show the text as
say
size 12
size 9
size 22
size 9
size 12
Also, if one is to wish to magnify icons, and or images, and thus
bitmap magnification is necessary, than for the purposes of context
and not an eye candy smooth squish, bit map squishing can be done
along side quite as easily as the bit map magnification:
1.0
0.5
2.0
0.5
1.0
If the XO is capable of computing the magnification to 2.0 than I
can't imagine that there would be that much extra strain put on it by
squishing two other rectangles to 0.5...
Thank you
Timothy
On Feb 11, 2008 10:13 PM, Peter Korn <a class="moz-txt-link-rfc2396E" href="mailto:Peter.Korn@sun.com"><Peter.Korn@sun.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Timothy,
</pre>
<blockquote type="cite">
<pre wrap="">Though I had not used orca before I had used the gnome accessibility
tools. Now, I'm not sure, I've either used both, or they are the same
thing. For me, orca is useless. Magnification alone does not help me
at all and tracking is infact harder for me with the weird "the screen
is the minimap". My grandfather, who has macular degeneration(and
thus needs magnification) found that setting the dpi to be extra high
was the least confusing. I have used speech dispatcher quite a bit
for my own personal scripts and with emacs' speechd.el In these
scenarios, speech dispatcher-application communication was direct and
no locational information was sent. Given the nature of orca's
magnifier utility, I assume that while locational information is sent,
geometric information is not. This actually leads to a bug when using
orca with only the keyboard: text boxes are often focused by keyboard
without the magnifier moving to show their labels.
</pre>
</blockquote>
<pre wrap="">Have you filed a bug or RFE against Orca for this feature (including
labels in the magnified field of view when Orca magnification is
tracking focus changes)? Also, when was the last time you played with
Orca magnification? In the last few weeks there have been significant
changes in how Orca drives the GNOME magnifier (gnome-mag), and I
believe Joanie Diggs is still actively soliciting feedback to her
magnification updates to Orca.
</pre>
<blockquote type="cite">
<pre wrap="">What I envision in
my line based interface is that the screen would be in regions:
empty | Normal | empty
empty | squished | empty
magnified
empty | squished | empty
empty | normal |
So the current line would be magnified IN PLACE, a small area above
and below it would be squished, and the rest would be normal in size.
This requires that we know the height of the current line as well as
it's location. The reason why I suggest squishing is simply that I do
not believe it technically feasible to 'cut' the window in two and move
the bottom half downwards to make way for the in place magnification.
The reason I propose this be line based is that in place magnification
would be weird if there was squishing on the sides as well. The way I
imagine things, the window manager could tell the window to be a
certain amount less wide to make way for the wider magnified bar.
Line based thinking also works well when we look at keyboard
accessibility, especially navigating with the keypads on either side
of the screen. I do not think that these things will work out, though
if we don't mandate line based navigation from the start.
</pre>
</blockquote>
<pre wrap="">Without question, a magnification system built into the window manager
would have the ability to make some of these changes. For the
squished/magnified lens that you are suggestion, we probably will want
the kind of functionality that we have in OpenGL (and to which the
Compiz window manager is taking advantage of) - at least if we want such
functionality to be performant. If I'm not mistaken, that is not
underlying graphics functionality we have on the OLPC XO.
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
_______________________________________________
accessibility mailing list
<a class="moz-txt-link-abbreviated" href="mailto:accessibility@lists.laptop.org">accessibility@lists.laptop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/accessibility">http://lists.laptop.org/listinfo/accessibility</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>