[Blindmath] Announcing SVGExplore01 from the creator of SVGDraw01

Sat Oct 29 01:48:39 UTC 2011

Without getting into the gory programming details, the issue involving the
return line is, so far, a very difficult programming problem resulting from
the somewhat difficult process of converting SVG elements to Java2D Shape
objects that incorporate AffineTransform objects along with Java2D clipping,
strokes, etc. There may be an easy way to do it, but I have approached it
from several angles and haven't yet discovered an easy way.

The problem doesn't lie in getting the SVG information. JDOM provides for
that very well. The problem lies in making the conversion from SVG to
Java2D.

I would be happy to examine the source code for a Java program that converts
SVG elements to Java graphics. As near as I can tell, except for the most
trivial cases, such source code doesn't exist anywhere on the web. So far, I
have restricted my search to pure Java and haven't seriously looked into the
possibilities using SWT graphics or other non-pure Java graphics libraries.
However, a cursory examination led me to believe that Java2D is probably
superior to SWT graphics in this regard. Let me know if you find or write
any such code.

Dick Baldwin

On Fri, Oct 28, 2011 at 8:28 PM, Michael Whapples <mwhapples at aim.com> wrote:

> Hello,
> Yes valid points that many of the issues disappear when using a trackpad.
>
> Quick note on using things with the left hand looking awkward, well it
> wouldn't be awkward if the world was built the correct way round :-).
>
> Now to some of the sound representations. Thinking about the information
> when just off a line, well may be this way round makes more sense. The sound
> possibly makes more sense representing the line's position relative to the
> pointer (IE. the user hears things from the view of the pointer and the line
> is giving off the sound). There are probably other cases where the reverse
> is more sensible (we seem to have gone with which way I am pointing for my
> shooting). May be using questions to find out the meaning of the information
> (which does it answer, where is the line or where am I pointing?).
>
> As for the final one, the closing line for open objects. If the line which
> is created to close the shape is marked as "virtual" (or choose another term
> if you prefer), then surely couldn't the software simply do a check of
> isLineVirtual and if true then make the different type of sound. May be this
> isn't the perfect answer to the problem, but it at least tells the user the
> line they are following isn't really part of the diagram.
>
> Michael whapples
> On 29 Oct 2011, at 00:41, Richard Baldwin wrote:
>
> > Hi Mike, I will respond to your comments embedded in the text below.
> >
> > On Fri, Oct 28, 2011 at 6:07 PM, Michael Whapples <mwhapples at aim.com>
> wrote:
> >
> >> This sounds interesting, I will have to try it out. Also I have a few
> >> comments which I have put in your message below, some of them said a
> little
> >> tongue in cheek although they may have a bit of a serious point behind
> them.
> >>
> >> Please also keep in mind this is comments from your description.
> >>
> >> Michael Whapples
> >> On 28 Oct 2011, at 18:45, Richard Baldwin wrote:
> >>> […]
> >>>
> >>> My hope is that this will provide an economical "quick look"
> alternative
> >> to
> >>> the use of fully embossed drawings for the purpose of allowing the user
> >> to
> >>> form a mental image of the shapes in the drawing.
> >>> I also hope this will be true. Sometimes you know what you have done to
> a
> >> diagram, you want to check it is about right but may not want to emboss
> it
> >> at that point as you may still have a bit more editing to do before it
> is
> >> "final". It will be a good way to get a general overview.
> >> […]
> >>> This is a mouse version of the program
> >>>
> >>> A fully operational touchpad version of the program is still in
> >> development.
> >>> I am providing a mouse version at this time to allow potential users of
> >> the
> >>> program to get a taste of how it works. I am hopeful that those users
> >> will
> >>> try it out and provide feedback and suggestions for improvement.
> >>> I am glad that you recognise some of the limitations of the mouse for
> >> this, good to see a touchpad being considered for the final one.
> >>>
> >>> […]
> >>> Grasp the mouse in your right hand with your thumb touching the
> >> upper-left
> >>> corner of the grid. Try to hold the mouse so that the front-to-back
> axis
> >> of
> >>> the mouse is parallel to the left edge of the grid.
> >>> You right handed bigot, what about us left handed people :-(. May be a
> >> top right corner calibration option would be good as well. OK, don't
> know if
> >> that is needed, could it all work fine with a left hand on the mouse and
> so
> >> calibration being to the right side of the mouse?
> >>
> >
> > rgb] I have been married to a left-handed person for almost 53 years and
> > doing things with the left hand still looks awkward to me :-)
> >
> > rgb] Seriously, it will still work with the mouse in the left hand. I
> prefer
> > an upper-left calibration point because it is always the same regardless
> of
> > the size and resolution of the screen. This won't be an issue with a
> > touchpad.
> >
> >>
> >> Also any tips on how to ensure alignment of the mouse axis? I could
> imagine
> >> some of the weird and wacky ergonomic mouse designs with curves and such
> all
> >> over may make the task harder.
> >>
> >
> > rgb] Don't have any tips on this other than to buy a cheap mouse without
> the
> > fancy curves. Again, not a problem with a touchpad.
> >
> >>
> >>> Press the 'h' key with your left hand. That will position the mouse
> >> pointer
> >>> in the upper-left corner of the drawing. Any time you feel lost you can
> >>> repeat that procedure to reposition the mouse pointer in the upper-left
> >>> corner to get your bearings again.
> >>> Does this do anything with the mouse pointer on screen? I ask this as
> >> could potentially one corner oneself in the bottom right corner of the
> >> diagram? Mainly I am thinking of either the first time one calibrates if
> the
> >> mouse got to the bottom right corner of the screen or if having lifted
> the
> >> mouse the pointer finds itself in the bottom right corner. It may be a
> good
> >> idea to suggest swipe the mouse up and left a few times if cornering
> >> yourself is an issue.
> >>
> >
> > rgb] It actually moves the mouse pointer to the upper-left corner of the
> > screen with compensation for the top and left insets of the Frame that
> > contains the drawing. Nothing else is needed.
> >
> >
> >>> If you move the mouse to the right while dragging your thumb along the
> >> top
> >>> edge of the grid (or along any horizontal grid line), you will
> >> (sometimes)
> >>> hear a deep rumble in both ears similar to a motorcycle idling.
> Whenever
> >> you
> >>> hear that sound, it means that there is a shape somewhere along a
> >> vertical
> >>> line that is parallel to the left edge of the grid and below (or above)
> >> the
> >>> mouse pointer. Note that you will only hear sounds when the mouse
> pointer
> >> is
> >>> moving.
> >>> When you say dragging, do you mean just moving or do you mean dragging
> as
> >> in holding left mouse button down at the same time?
> >
> >
> > rgb] Very good question. For the version that I posted, it means to move
> the
> > mouse without pressing the mouse button. Originally, I had the user press
> > the mouse button, but I found that this made it more difficult to get
> fine
> > control over the mouse motion, for me anyway, so I changed it to simply
> > moving the mouse. However, in order to run the program on my Wacom pad, I
> > have to change the program to correspond to moving the mouse with the
> left
> > button pressed. I will make this an optional choice in the version that I
> > write for use with touch pads.
> >
> >
> >> Interesting you decided to only have it make a noise when moving, any
> >> reason? I hadn't really thought about that until I saw this but I
> probably
> >> would have naturally had it go regardless of whether the mouse is
> moving.
> >>
> >
> > rgb] Sometimes peace and quiet is nice.
> >
> >
> >
> >>> […]
> >>>
> >>> There are three pitches associated with each shape. In addition, the
> >> three
> >>> pitches associated with one shape are readily distinguishable from the
> >> three
> >>> pitches associated with each of the other shapes.
> >>>
> >>> When you have placed the mouse pointer squarely on the center line of
> the
> >>> boundary of a shape, you will hear a series of pulses at a pitch that I
> >> will
> >>> refer to as the center pitch. When the mouse pointer is slightly below
> >> the
> >>> center line, you will hear a slightly higher pitch. This means that you
> >>> should slowly move the mouse toward the top of the grid to place the
> >> mouse
> >>> pointer on the center line. When the mouse pointer is slightly above
> the
> >>> center line, you will hear a pitch that is slightly below the center
> >> pitch.
> >>> This means that you should slowly move the mouse toward the bottom of
> the
> >>> grid to put the pointer on the center line.
> >>>
> >>> You will also hear the pulses in your left ear, your right ear, and
> >> evenly
> >>> in both ears. When the mouse pointer is positioned squarely on the
> center
> >>> line, you should hear the pulses with equal intensity at the center
> pitch
> >> in
> >>> both ears. If you hear the sound in your left ear only, you need to
> move
> >> the
> >>> mouse slowly to the left in order to place the mouse pointer on the
> >> center
> >>> line. Similarly, if you hear the pulses in your right ear only, you
> need
> >> to
> >>> move the mouse slowly to the right to acquire the center line.
> >>> A question, not really sure if there is a wrong or right answer. Why
> did
> >> you choose to go with direction to find the target? The alternative is
> say
> >> where the person is pointing relative to the target (eg. if I am
> pointing to
> >> the left then I get a signal saying/indicating left). May be I am
> >> particularly aware of the two systems as with my shooting the audio
> scope I
> >> use only gives me useful tones when it is pointing at the target
> diagram, so
> >> if I am not pointing at the target the assistant tells me the direction,
> but
> >> I noticed some were saying which way I needed to move when others were
> >> saying which way off the target I was pointing, a bit confusing until I
> >> realised what was going on.
> >>
> >
> > rgb] That decision was essentially flip of the coin. I can program it
> either
> > way. Maybe I will take a poll to see what people prefer before casting it
> in
> > concrete.
> >
> >
> >>> […]
> >>> In order to help you maintain your orientation, all shapes are forced
> to
> >> be
> >>> closed, even if they weren't originally closed when the drawing was
> >> created
> >>> in SVGDraw01. By this I mean, for example, that if you plot a series of
> >>> points using the Polyline action in SVGDraw01, a line will be drawn
> that
> >>> automatically connects the last point back to the first point in this
> >>> program. That will help you to identify the ends of a curve and avoid
> >>> falling off the end of a curve only to search in vain for the rest of
> the
> >>> curve.
> >>>
> >>> On the other hand, this is not completely without its problems. The
> >> return
> >>> stroke can sometimes cross the curve and create a crossroads where
> there
> >> is
> >>> no difference in the pitch of each of the four directions of travel at
> >> the
> >>> intersection. (Think of the center of a figure 8.) I'm still thinking
> >> about
> >>> how to solve this problem and suggestions are welcome.
> >>> Would it be possible to give the closing line a different sound? An
> >> example might be use a different wave form for the tone, so actual shape
> >> sides are sine waves, the closing but non-existent side is a triangular
> >> wave. Another alternative might be to give a sound indicating end of
> line
> >> (eg. a pulse of white noise) or a click.
> >>
> >
> > rgb] This is a very difficult problem. Creating different sounds is easy.
> > Knowing when to change sounds is very difficult. I don't have a solution
> to
> > this yet, but I am working on it.
> >
> >
> > Thanks for your feedback.
> > Dick Baldwin
> >
> >> […]
> >> _______________________________________________
> >> Blindmath mailing list
> >> Blindmath at nfbnet.org
> >> http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
> >> To unsubscribe, change your list options or get your account info for
> >> Blindmath:
> >>
> >>
> http://nfbnet.org/mailman/options/blindmath_nfbnet.org/baldwin%40dickbaldwin.com
> >>
> >
> >
> >
> > --
> > Richard G. Baldwin (Dick Baldwin)
> > Home of Baldwin's on-line Java Tutorials
> > http://www.DickBaldwin.com
> >
> > Professor of Computer Information Technology
> > Austin Community College
> > (512) 223-4758
> > mailto:Baldwin at DickBaldwin.com
> > http://www.austincc.edu/baldwin/
> > _______________________________________________
> > Blindmath mailing list
> > Blindmath at nfbnet.org
> > http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
> > To unsubscribe, change your list options or get your account info for
> Blindmath:
> >
> http://nfbnet.org/mailman/options/blindmath_nfbnet.org/mwhapples%40aim.com
>
>
> _______________________________________________
> Blindmath mailing list
> Blindmath at nfbnet.org
> http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
> To unsubscribe, change your list options or get your account info for
> Blindmath:
>
> http://nfbnet.org/mailman/options/blindmath_nfbnet.org/baldwin%40dickbaldwin.com
>

-- 
Richard G. Baldwin (Dick Baldwin)
Home of Baldwin's on-line Java Tutorials
http://www.DickBaldwin.com

Professor of Computer Information Technology
Austin Community College
(512) 223-4758
mailto:Baldwin at DickBaldwin.com
http://www.austincc.edu/baldwin/