Thanks everyone for the input provided so far. Even the 'flames' provided data! (feel used?:) This post is long,(you have been WARNED) Based on the responses to the issue of scrolling, I think there may be a partial mis-communication of my (sighted) scrolling concepts. Please forgive me, but I have never before tried to explain anything omitting any visual references. Its a new paradigm shift. Things I totally understand so far. Any reader requires minimum of 2 fingers worth of data always available. The 2 finger positions if width adjustable(rigid/slideable) should be incorporated if possible to improve ease of use. Requires ability to easily jump around on the line for review etc. Without those minimums usage would be miserable at best. The thing I think is mis-understood is the scrolling part. I am talking about SMOOTH scrolling, not jumping a whole character or even necessarily a whole column at a time. Many smaller in between jumps are displayed. The brain fills in the blanks reliably at some point. Thats how movies,TV, and computer audio do it too. With a standard text LCD display driver chip... Worst case with 1 braille character mapped to 1 ascii character would be only 5 steps of smoothness per full character position. This = 1 LCD dot/1 braille dot ratio. If each COLUMN of braille were mapped to 1 ascii character it would be 10 steps per character position. The ratios are flexible depending on required space between dots. With a 1/2 ratio only 16 seperate column patterns are needed(only 4 bit/dot positions). 5 steps may be too small for everyone but 10 might suffice. If not, so much for using text LCD drivers for braille! With a text LCD driver chip only 1 height is supported. They are already capable of smooth scrolling a 5or10 column chr. With a 'graphics' LCD driver chip... Imagine each DOT made up of 64 smaller dots in a 8x8 grid. To move a dot just one whole braille column position would require 8+x seperate sub-dot column shifts. The first 8 just to shift the current dot away, and bring the possible next dot into center position (the space between columns and chrs is flexible). To move a set of dots a whole character position would produce a minimum of 16+x seperate interim dot feelings (x=additional space between columns and characters). Put a caterpiller on your finger and feel the sensation of ??? moving with their many legs as they walk. (yuk) Circular dots are simulated if required by not raising the corner sub-dots. The corner sub-dots are still needed because they will be middle sub-dots as the dot is scrolled by sub-column. With multi height per sub-dot round dot tops can be made, else flat top. Concave and other non round shapes are doable with multi height. The difference between economy and elite now becomes the number of sub-dots/dot over some acceptable/useable minimum. Graphic LCD driver chips are available in B&W(single) and greyscale(multiheight). The sighted analogy of a 1 character display provided was EXCELLENT. If text moved smoothly into and out of view I could read accurately slowly. If each character was instantly replaced by the next I would have trouble reading accurately even slowly. My sighted and braille analogy is to cut two 1-2 character holes or in a piece of paper and read a line of text/braille with it by moving it smoothly aover a line of text. If you had to close your eyes or lift your fingers between the time each character lined up exactly, it would be quite difficult to read I agree. (even if someone else was doing the moving automatically) If you can sample even 1 or 2 times more between characters centers it gets easier quickly. A sound analogy is listening to someone speak normally, listening to them speak from behind a slow and fast spinning window fan. Worst case here would be a fan blade made out of a solid disk with just 1 slot cut out also spinning slowly. you would only hear the speech when the slot was lined up with the speakers mouth. (jerk scroll) Think window fan, and you cant hear around the fan, because of the house wall, only between the fan blades. Different fan speeds represent different resolutions of sub-dots. Each sounds different and provide different amounts of data and the same words. At some point the words are lost representing minimum useable resolution. The PC speaker/piezo can make OK understandable words with only about 1/8 the samples considered minimum for audio! A simple thin soft flexible covering on the whole thing would further 'average' the heights during and between steps, and enhance overall response. Consider this the only possible consumable necessary besides power. Similar averaging is responsable for the success of audio digitization and all lossy compression. (results vary) I have a few solutions to the jumping around the line. Put wheels on the bottom of the 2 finger reader and run it back and forth in a simple hot wheel track. A pot attached to a wheel does the mech/electro part and the SW the rest. (many variations possible) Put a thumb operated slider pot to indicate where in the line the fingers are desired and the same SW as above. (most portable idea) The slider can be placed upside down under the finger positions for better ergonomics. It would be held between the thumb and fingers IN the hand. To convert one of theese to 'graphic' start mid-res and scroll whatever in x and y instead of just x. The multi sub-dots already puts it in the graphic league! Add more fingers too! The software needed is not exotic at all. Again a portable model would use thumb positioner within a smaller frame and just have small thumb movement equal large 'screen' movement. This also easily ergos into an IN hand model. This is how a mouse user moves a pointer everywhere on a big screen on a smaller mouse pad in one movement. The acceleration becomes unnoticeable when adjusted properly. The touchpad on my laptop is way tiny but it works! To read text on such a 'screen' with linux it is just a matter of selecting braille as the display font in the size desired. Questions follow: Is my description of smooth scrolling comprehensable to the non-sighted? Is my concept of SMOOTH scrolling different that your concept of text scrolling? Is SMOOTH scrolling what was described that works only so/so now??? If one existed does it sound useable? That it cant be done I do not accept, I am incapable. That it wont be done can be arranged. I dont claim to be the best man for the job either just willing. SOMEONE ought to define whats needed in minute detail and isolate the engineering obstacles remaining. Every USER will need to understand same anyways at first for sure!!! Jan P. Finegan jf.blinux@dynolink.org