Published Quarterly by Raised Dot Computing, Inc., 408 South Baldwin Street, Madison, Wisconsin USA 53703. Telephone: 608-257-9595. Fax: (608) 241-2498.
Subscriptions: $18/year Print, $20/year Audio Tape, $24/year Apple II BEX data disk or MS-DOS data disk. (Kindly add $20/year for postage outside N. America.)
Single issues: $4 each (specify medium).
Submissions are always welcome, especially on diskette. All are subject to editing for style and clarity. All opinions expressed are those of the author. Editors: Caryn Navy and David Holladay.
Entire contents copyright 1992 by Raised Dot Computing, Inc., All Rights Reserved. Nothing may be reprinted in any medium--print, braille, audio, or electronic--without prior written permission from RDC Inc.
The NFB and ACB conventions once again gave us a valuable opportunity not only to demonstrate MegaDots and our other products but also to share valuable information with some of our customers and with other developers and vendors. We raffled off a free copy of MegaDots at each convention. Since we conducted the two drawings after returning to RDC, it was up to the RDC staff to generate enough excitement. They did a great job. The winners were Era Mae Brown of Dallas, Texas for the NFB convention and Rick Plath of Burbank, California for the ACB convention. Congratulations, Era Mae and Rick!
The next major conference that we will attend is the Closing the Gap conference in October. We missed the deadline for scheduling a workshop. But let us know if you would be interested in an unofficial MegaDots training session.
We have been moved by the reports of flooding in the Midwest. We extend our sympathy to any Newsletter reader who has had to deal with this crisis. If you have RDC written software that was destroyed by flooding, first see if your insurance covers the loss. If the damaged disks and/or manuals are not covered by insurance, please send them to us for replacement with a note of explanation.
We greatly appreciate the articles contributed by our readers for this issue. Professor Richard Wright's article about his experience with the Reading Edge from Kurzweil-Xerox Imaging is very timely. All of the developers of reading machines have recently come out with new products. If you are interested in purchasing a stand-alone or PC-based reading machine, you should get the latest literature from these companies to learn about their different models. In addition, the July 1993 issue of Technology Update is devoted entirely to reading machines. It compares the current stand-alone models from three manufacturers.
Faithful readers of this Newsletter know that in the April edition we print the catalog of "Sensory Overload, Inc.," an entity which exists only in the twilight of April Fools Day. While we are long past April 1, there is still time for us to provide a glimpse of a most unusual line of products.
While the rest of the braille industry is focused on brailling on paper or signs, Sensory Overload does it again with the first ever tombstone embosser--the Ever-Rest Brailler. This high technology product contains a built-in version of the Dux-Burial Grave Two Translator. (At Raised from the Dead Computing, they wish we had used Maggot-Dots instead.) For those with unlimited budgets, there is an optional Automatic Monument Feeder.
The Ever-Rest Brailler will be distributed by TeleCemetery Systems, Inc. Once the use of this product becomes widespread, there will be no more need for the MarkInStone reading machine.
At Sensory Overload, we asked ourselves the question "What would happen if you put a single dot of a braille cell on a braille notetaker?" Immediately we knew we were onto something! Think of it--with just a mode change, the unit could shift between six dot braille, eight dot braille, and even New York Point. By pressing the spacebar, the reader learns the status of dot 1, then dot 2, then dot 3, then dot 4, then dot 5, then dot 6, then the next cell! The unit has been thoroughly tested by blind prisoners.
What is the ultimate sensory aids device? The GOLIATH of course! GOLIATH stands for Gadget Only Located In Affluent Techies' Households. The GOLIATH contains the new Pentium processor, 32 megs of RAM, 500 megs of hard disk space, an 80 cell braille display, a braille embosser, and superior voice technology. Achieving all this in a tiny package was not cheap! The unit costs 1.5 million dollars, a bit on the high end of most budgets. We figure if we sell to all the resource centers that buy "one of everything," we will break even.
Sensory Overload has been paying attention to the lively discussion among blind persons about the possibility of hearing travel cues while moving through the environment. Sensory Overload has a simple approach.
We have been training small rodents to provide travel cues. In our Gerbil Landmarks system, each furry creature learns how to say one phrase, such as "Gate 17" or "X-Ray Department." The blind travelers do not have to carry any special device. They just have to listen to our training tape to learn how to understand gerbil speech. The general public does not recognize the pleasant noises as speech and is not bothered by them. We invite you to compare our product with the bird-based competition, Squawking Signs.
At Sensory Overload we heard a plea from blind parents of active young children. They told us that nowadays the playground equipment is much more complicated than it used to be. They want to help their children on the ladders, platforms, and slides of these multi-level contraptions, but sometimes it is hard to figure out which way to climb. So Sensory Overload is introducing PAWS, Playground Access With Sound. Using PAWS is like using a guide dog, but a guide dog that can climb ladders. PAWS beeps to show you the right direction to go next. In addition, PAWS screams "Look out!" when you are in danger of falling or being hit by a swing, sea-saw, ball, head-level obstacle, or anything else.
A limitation of conventional reading machines is the inability to scan more than one page at a time. This makes the process of reading an entire book a time-consuming, boring task. Now the new DOG Scan, with its Digitally Organized Guessing, totally eliminates this problem. Using directed X-Ray beams and state-of-the art computing technology (a more advanced version of the CAT scan used in medical applications), an entire book can be read in seconds without opening a single page. With any luck, the book won't be chewed to bits.
[Acknowledgements: Many of these items were developed by group discussion, some here at Raised Dot and some at conferences. We would like to acknowledge some special contributions. Aaron Leventhal came up with the name "Ever-Rest Brailler." Warren Figueiredo, the Head of the Braille and Technology Center at the Louisiana School for the Blind, came up with the phrase that makes "GOLIATH" an acronym. We thank David Holladay for the CellMate and Caryn Navy for Gerbil Landmarks and PAWS.]
A major MegaDots bug has been fixed! We are delighted to announce that the Enhanced Edition of MegaDots now works with the screen access programs Artic, JAWS, and Vocal-Eyes. Until now there have been incompatibilities between these screen reading programs and the Enhanced MegaDots. At this point, we are not aware of remaining incompatibilities between MegaDots and any voice or braille access systems.
Any MegaDots customer who has been affected by this bug can call Raised Dot Computing to get a free update to version 1.2c. When you call, please tell our staff which screen access program you use.
It was Doug Geoffrey of GW Micro (the firm that sells Vocal-Eyes) that worked out the solution. We are indebted to Doug for his hard work and dedication!
We want our readers to know that the problem was not a bug in Artic, JAWS, or Vocal-Eyes. We also would like to express our appreciation to our customers who have been waiting for us to fix this problem. The wait is over! You can now use the full power of MegaDots with your favorite screen access program.
MegaDots will still cost $500 during 1994. Close readers of our sales literature may have noticed that until now, we had been careful to state that the published MegaDots prices were only good until the end of 1993.
Right now, persons with Hot Dots 3.0 can upgrade to MegaDots for only $125. That exceptionally fine deal expires at the end of December, 1993. You have only 5 more months to trade in your Hot Dots 3.0 for MegaDots.
When people purchased Hot Dots 3.0, they had no idea that we were actively developing MegaDots. We thought it would cause resentment if we announced MegaDots a few months after someone purchased Hot Dots 3.0. By offering a MegaDots upgrade for only $125, we keep the total outlay at $475 ($350 for Hot Dots and $125 for the MegaDots upgrade), which is $25 less than the straight price for MegaDots. This plan reverses the usual pricing trends in the sensory aids field, which have tended to punish early purchasers.
Starting in 1994, all MegaDots upgrades (from BEX, Hot Dots, and Duxbury) will be $250. If you have any questions about MegaDots pricing, feel free to contact Raised Dot Computing.
We are conducting a special sale on Echo synthesizers for Apple computers. Until October 15, 1993, we will charge $100 for the Echo 2 and for the Echo LC. This is a reduction of $30 from the regular price. The Echo 2 is for the Apple 2e or Apple 2gs computer, and the Echo LC is for the Apple 2c, Apple 2c+, or Macintosh LC computer.
We are excited to announce that Flipper version 4.0 is now being shipped. Omnichron's Flipper 4.0 provides speedy and flexible voice access to hundreds of mass-market applications on the IBM-PC and compatibles. Combined with any of a wide variety of speech synthesizers (Audapter, DECtalk, internal DECtalk card, Accent, DoubleTalk PC, Echo PC, Symphonix, Braille 'n Speak, SoundBlaster, and others), Flipper lets you selectively hear portions of the IBM screen, learn about visual cues that communicate program features, and review any material on the screen without affecting the underlying application.
Flipper offers an excellent balance between automatic operation and control over what is spoken and how. Flipper's features are available right out of the box, as it automatically configures itself for many programs. You can easily do simple functions, like reading the current line or the current field. Changing the way Flipper works is easy as well with the new "definition interviews." Flipper simply asks you questions about what you want it to do. You can describe a series of things for Flipper to do when you hit a key, when something pops up on the screen, etc. In tailoring Flipper's operation to your own needs, you can combine Flipper's comprehensive automatic features in just the right way to complement whatever software you are using.
Flipper 4.0 occupies about 60k of memory, and can "load high."
Flipper 4.0 costs $495, which includes the program disk, manual in print and braille and on disk and technical support from RDC and Omnichron. A Flipper demo disk is available from RDC. When ordering Flipper, please indicate the disk size you want. Updates from earlier versions of Flipper are available from Omnichron for $88. You can call them at (510) 540-6455 or fax them at (510) 540-8550.
RC Systems has once again improved the speech on its DoubleTalk family of speech synthesizers. This includes the DoubleTalk Apple Synthesizer (for Apple 2 computers), the DoubleTalk PC (internal card for MS-DOS machines), the DoubleTalk LT (external synthesizer for MS-DOS machines), and the LiteTalk (external synthesizer for MS-DOS machines sold by MicroTalk). If you already have one of these synthesizers, you can purchase the new replacement speech chip from RC Systems for $25.
The major improvement introduced in the latest speech chip is in word pronunciation. Randy Carlstrum of RC Systems says that the new chip corrects the pronunciation of 2500 different words (and many more words based on these corrected words). The speech chip upgrade also includes cumulative improvements made over the last few years. These include faster response time, better tone (with normal tone in addition to bass and treble), and voice indexing. Voice indexing allows screen reading software to know what the DoubleTalk has just spoken in order to coordinate cursor movement with what is currently being spoken. With voice indexing the shut-up command can leave the cursor at what you just heard. Note that not all screen reading programs take advantage of voice indexing.
If you would like, you can send your synthesizer to RC Systems and have them do the installation for you. Otherwise, you can avoid down time by having RC Systems send you the speech chip for you or a friend to install. In this case, you must tell RC Systems which of two microprocessor chips your synthesizer contains. The microprocessor chip is the large square chip in a socket. The microprocessor chip is made either by NEC or by Intel. The NEC chip says "NEC V40." The Intel chip has a stylized I and also says "TN80C188EB." The chip being replaced is the only chip in the synthesizer with a little window showing an inner chip, and it is also the only 32-bit chip.
You can contact RC Systems at (206) 672-6909 (address in Facts on File).
Index is a manufacturer of embossers in Sweden. The Index Basic and Index Advanced are two models that have been fairly popular in the United States. The current US distributor for these units is CELEXX Trading Company. Their address and phone number is: 8 Tami Court, Bloomington, IL 61701 (309) 828-2097.
CELEXX sells through a network of dealers. If you are interested in purchasing an Index, call CELEXX to find the closest dealer. CELEXX does not sell the Everest, which is also manufactured by Index. The US importer of the Everest is TeleSensory Systems.
In the last few weeks, Raised Dot Computing has been
logging onto the Internet regularly. Messages to Raised Dot Computing can
be directed to Aaron Leventhal at dnavy@well.sf.ca.us (we use
the Well bulletin board as a convenient access point to the Internet).
If you like to chat on-line, please drop us a line. We will also try to monitor BlinkTalk and other chat lines to keep in better touch.
Sometimes it is necessary to mark some text as both emphasized (e.g., italics) and as grade one braille. Marking something in italics is easy. Get the cursor at the beginning, and press Control-X to begin highlighting. Then move the cursor to the end of the desired text. To specify italics, type Control-F I.
If you try to highlight the same block again and mark it for grade one braille, MegaDots usually gives an error message about "overlapping markup." Overlapping markup means that you have an alternating pattern: start markup A, start markup B, end markup A, end markup B.
You can specify grade one for the same text if you follow these directions. Go into show markup mode (by pressing Alt-W if necessary). Move the cursor on top of the left pointing arrow that makes up the start italics markup. (In MegaDots 1.2, you can land on this only when you move backwards. If you are approaching the start markup from the left, you must go past it and then press the left arrow to land on the left pointing arrow. This will be fixed.) At that position, press Control-X to start marking a block. Move the cursor to the right so that it rests on the space after the end markup. The highlight of the block should exactly match the highlight of the italics. Now press Control-T O for grade one braille.
Now wasn't that easy! With these directions, you place the grade one markup outside of the italics markup. In the course of writing this article, we have noticed that you do not get correct braille if the grade one markup is inside of the italics markup. This will be fixed in an upcoming edition of MegaDots.
MegaDots knows about importing three kinds of ASCII files: ASCII document, ASCII line, and ASCII quick. What do these terms mean? To find out, you need this article. These terms are quirky Raised Dot jargon and are not likely to be defined elsewhere.
An ASCII document file is the kind of textfile most people have seen now and then. These are files formatted to be printed out on an inkprint printer. Each inkprint line has its own carriage return. Each new inkprint page may have a form feed.
For the purpose of translation into braille, ASCII document files bring a number of formatting problems. It is difficult for the software to guess which lines are the start of fresh paragraphs and which lines are inside of paragraphs. MegaDots uses special software which compares the line lengths of each line to help decide which lines are the start of new paragraphs. This software works best when a file has been systematically formatted by a computer (as most of them have been).
An ASCII line file uses a carriage return for each new paragraph, but not to show the end of each inkprint line. ASCII line files cannot be edited on some word processors. These programs choke on files containing "lines" that are too long (i.e., these programs can handle only ASCII document files). An ASCII line file is less ambiguous than an ASCII document file. There is no question about where new paragraphs start, since each carriage return means the start of a new paragraph.
An ASCII quick file is really an ASCII document file. However, when you ask MegaDots to load a file as an ASCII quick file, MegaDots divides the file into paragraphs without using its special routines based on a fixed maximum line length. If your ASCII file is not divided into lines as evenly as possible (i.e., has a ragged right edge on the screen), MegaDots will do a better job of breaking it into paragraphs by importing it as an ASCII quick file. Which files are likely to have this problem? In general, they are files manipulated by a human or files optically scanned from proportionally spaced material.
How do you tell MegaDots to import an ASCII quick
file? You cannot do it from inside of MegaDots. You must do it at the DOS
command line. Add -0109 to the command line calling MegaDots.
For example, typing MEGA FETCH.TXT -0109 <Enter>
imports the file FETCH.TXT as an ASCII quick file.
Where does the number 0109 come from? In the MegaDots
Reference Card, the section called "File Conversions" lists all the file
types that MegaDots can import. Each file type listing includes a
four-digit code number to use at the command line to force MegaDots to use
that file type. Each copy of MegaDots comes with the Reference Card in
print, in braille, and in the MegaDots file REFCARD.MEG in
your MegaDots directory.
Recently, we got a file in the mail with a note saying that it did not import into MegaDots. We looked at the file and immediately saw what the problem was.
The file was an ASCII textfile, but it was never designed to be printed. It was designed only to be displayed on the screen. It was loaded with decorative high bit and control characters to make the display more visually appealing. The automatic file recognition software in MegaDots could not classify it as an ASCII textfile, or as being associated with any word processing program.
The solution was simple. Just add -0101
to the command line calling MegaDots to force ASCII document
(see the discussion just above about the list of file conversion types in
the MegaDots Reference Card). The lesson is that the automatic file type
recognition is not perfect. The automatic file type recognizer is fairly
conservative: it will refuse to classify a file if there is the slightest
doubt about its file type. Fortunately, MegaDots has a feature that lets
you tell reluctant files where to go.
We recently had a series of tech calls from a customer who complained that MegaDots was scrambling some characters. The investigation into the problem was not easy. It turned out that the original files were created by a Macintosh Word Processor supported by the MegaDots importer. Yes, MegaDots can directly read Macintosh files.
But the customer was not dealing with the Macintosh files himself. Someone else converted the Mac files into DOS WordPerfect files using software that was less than perfect. This conversion system did not change Macintosh high bit characters to PC high bit characters. The result was that the Macintosh curling quotes (single or double) became random graphics characters.
The solution was simple. We instructed the customer to stick to the method described in the MegaDots manual on page 13-2 for importing Macintosh files (using Apple File Exchange). The MegaDots file importer is smarter and does know about Mac and PC high bit characters.
The lesson is to avoid using additional file conversion steps unless they are absolutely necessary. If you have a big project and you are unsure how to bring the files into MegaDots, call the Raised Dot Computing technical line for advice at (608) 257-8833. We would rather help you on the front end than deal with a "MegaDots problem" on the back end.
OK, its no secret: MegaDots is relatively new software. It is formatting your text live as you type. Occasionally, MegaDots fails. When this happens, the keyboard locks up, and you lose some of your work.
This can be very distressing. You are most vulnerable if you are using textbook format with all the trimmings: tables, transcriber's notes, glossaries, switching translation modes, etc.
Here is a protocol which should help you through
MegaDots' worst spasms. At periodic intervals (say every 45 minutes
or every hour), save your file twice. Press F4 and give the file name with
a .MSV extension (MSV is for MegaDots save). Immediately
press F4 again and give the same name with a .MEG extension.
If things go wrong, and MegaDots offers you a chance
to save what is left in a file, do so. That will put the suspect material
in the .MEG file (the last file name that you saved to).
Now go back into MegaDots and load both the
.MSV and the .MEG files. Use the clipboard to
move recent work from the .MEG file to the .MSV
file. After that, you can abandon the .MEG file. Hopefully,
at worst case, you have lost just a few minutes worth of work.
Of course, we take all reports of program problems and data loss very seriously. If you have a file which crashes when you move the cursor to a particular position, contact us immediately. Your file is very useful to us as a debugging tool. Call us on our 800 number. We will give you our Federal Express account number so that we can get the file quickly on our nickel.
Recently we produced a special newsletter just for MegaDots dealers. In it we addressed the most common questions that come up about the MegaDots program. We thought it would be a good idea to print these in our regular Newsletter as well. In no particular order, here are the most common questions that come up about MegaDots.
Yes, MegaDots has a Quick Mode, which lets you process a file from the command line to your embosser. The Quick Mode is documented in Chapter 12 of the manual and in the Reference Card.
Yes, MegaDots works with all commercial embossers. Chapter 19 of the manual documents how to get different kinds of embossers working with a PC running MegaDots. If you have any questions about getting MegaDots working with your embosser, you can call our technical help line at (608) 257-8833.
You need a PC computer. We recommend a 286 computer or above with at least 1 megabyte of memory. If you have 2 megabytes of memory, then you can use the Enhanced Edition of MegaDots (and work with larger files). For sighted users we recommend a color monitor and a mouse.
MegaDots is designed to be useful to everyone--blind individuals, teachers, business persons, students, and transcribers. Feel free to use a MegaDots demonstration disk to find out how it works.
It depends. We have noticed that teachers like the ease of use of MegaDots, transcribers like the formatting features and the feedback, and blind individuals like the speed and the ability to go back and forth between print and braille.
MegaDots is friendly to speech and is also friendly to sighted users. In the "blind friendly" mode, MegaDots does a lot of tricks to make sure that all the screen access programs say appropriate things. Try out a demo disk to see for yourself.
We have tested MegaDots with the Navigator system. At present we believe it works with all refreshable braille display systems for the PC. Anyone can test their equipment with a demo disk if they have concerns.
When you install MegaDots, you have a choice of installing the Regular Edition or the Enhanced Edition. The difference is the size of the data files you can work with. You are limited to small files in the Regular Edition. Using the Enhanced Edition, we loaded the entire text of the novel War and Peace into MegaDots (3.3 megabytes in size) and translated it into braille in 80 seconds. This required a 33 MHz 486 machine with 8 megabytes of RAM. As a rough guide, take your RAM size, subtract 1 megabyte, and then divide by 2 to figure the maximum size of a data file you can work with in the Enhanced Edition.
Both MegaDots and Duxbury can produce high quality braille. If you are interested in modifying the default output, Duxbury depends on the user's being familiar with braille transcribing rules. MegaDots automates a considerable number of the details which complicate the task of producing braille. We have received considerable feedback that MegaDots is much easier to learn than Duxbury; that our documentation is much easier to read and understand; and that our commands are much more straightforward.
Many users of Duxbury are using the Duxbury WordPerfect Bridge. The user can operate a batch file to turn the WordPerfect file into a braille file. To guarantee the braille results, the user can type braille formatting commands inside the WordPerfect file.
MegaDots at present does not offer a facility to guarantee the braille output from inside of a WordPerfect file. Instead, the user works from the MegaDots editing environment. The advantage of MegaDots is that the user can tell exactly how the braille will be formatted while editing and making changes.
We invite informed comparisons between Duxbury and MegaDots. Duxbury demo disks are now available from Duxbury Systems. It is a good idea to obtain a copy to compare MegaDots with Duxbury.
Hot Dots is the previous PC translator sold by Raised Dot Computing. Turning a file into braille is simple with Hot Dots. But if you need to make changes to your file (to improve the translation or to fix the format), you are out of luck. It is very difficult to improve the output with Hot Dots. The translation and format are better in MegaDots than in Hot Dots, and in MegaDots you can easily modify and improve your work. MegaDots also works with a more modern list of file formats.
MegaDots is a DOS program, not a Windows program. However, it is easy to launch from Windows. For a sighted user, MegaDots appears just like a Windows program (since it uses a simple pull-down menu and has a logical structure). MegaDots can automatically read many file formats of Windows word processing programs.
No, there is not a Nemeth translator in MegaDots now. We are working on a Nemeth translator. It will take a lot of time to finish. When it is available, it will be quite expensive (an add-on more expensive than the base product). Anyone can use MegaDots right now to produce Nemeth Code--as long as they can write the Nemeth sequences themselves and mark them as "exact translation."
While some companies are happy if their software can handle ASCII files and WordPerfect files, MegaDots can transparently import over 90 different file types. To see the list yourself, look at the last section of the MegaDots Reference Card. You need to purchase the Supplemental Conversion Package to import the file types marked as "Supplemental" in the Reference Card.
MegaDots can do grade one Spanish, French, German, and Italian. Material written in foreign languages for Americans should be in grade one. If you need to produce foreign language material in grade two (typically only needed by persons operating outside of the United States), you need to purchase Duxbury with the appropriate foreign language module.
Yes. It currently supports large print on dot matrix printers. We will soon support large print on laser printers.
[Editor's note: This fine paper, written by Joseph Sullivan of Duxbury Systems, addresses many issues that have come up in the Raised Dot Computing Newsletter. Since Joe is a member of the Uniform Braille Code (UBC) Committee, he brings a unique perspective to these issues.]
Many of today's technologies seem to evolve so fast that there's no keeping up with them. For instance, practically all of the latest and greatest computers of the 1970's are no longer seen outside of museums and reruns of the science fiction movies of that era. Many computers of the early 1980's are now serving as bookends. Even last year's computers suffer noticeably by comparison with this year's, and so it goes. Compared with computers, braille -- invented in the early nineteenth century - would seem to be a model of solid and mature technology, one that does not and probably should not evolve very rapidly. While that is basically correct, braille too can profit from the inevitable march of progress, and at the present time there are two technologies being developed that are, in my opinion, of particular importance to the entire community of persons who produce or use braille.
Those technologies are SGML (Standard Generalized Markup Language) and UBC (Unified Braille Code). Once you get past the alphabet soup, the concepts behind these technologies are not really difficult, even though they are a bit "technical" if you get down to some of the details. This paper concentrates primarily on SGML, attempting to explain it in nontechnical terms, and its benefits for braille, to the layman who may not know much about either markup languages or braille. It goes on to explain why certain problems with braille are not solved by SGML, and it touches on UBC as a promising complementary technology. For those readers who are already well versed in one or another aspect of these subjects, it will be obvious (I hope) which paragraphs may be skipped over.
Since the 1960's, one of the more routine uses of computers has been to format text, that is to produce "finished" documents from text stored as a file on the computer. To make this a bit more concrete, let us assume that we wish to produce a simple document that has several sections, each section having a heading and one or more ordinary paragraphs. Let us further assume that, in the print edition, we want the section headings to be centered and the paragraphs to be separated from each other, and from the headings, by a skipped line. Then we might start with a computer file that contains the following text:
[start-centering] First Heading [end-centering] [skip-line] This is the text of the first paragraph, which would normally be much longer but we do not wish to belabor this example. [skip-line] This is the text of a second paragraph. Again we will be unusually brief. [skip-line] [start-centering] Second, Somewhat Longer Heading [end-centering] [skip-line] This is the first paragraph in the second section ...
The items enclosed in brackets in the above example are obviously not part of the text that is intended for the eventual human reader, but rather "formatting codes" to be used by the computer program that is to do the formatting. The formatting program uses them to tell what text to lay down in ordinary paragraphs, what text to center, and where to skip lines. Those codes, and the text itself, are all that is important in this file. In particular, line endings in the original file signify nothing more than a break between words, and so are exactly equivalent to spaces; to emphasize this, we have deliberately shown the file as running on in a kind of stream that is a bit hard to read (sorry about that).
Starting with the above file, the output of the formatting program would be something like this:
This is the text of the first paragraph, which would normally be much longer but we do not wish to belabor this example.
This is the text of a second paragraph. Again we will be unusually brief.
This is the first paragraph in the second section ...
"Codes" may also be called "tags" or "markup." In the example given, the codes are obviously related directly to the appearance, or format, of the resulting document, and so would be called format codes or appearance-oriented markup. This general kind of markup is no doubt familiar to most users of word processing software. In WordPerfect, for example, you need only press the "Reveal Codes" function to see markup much like our example, although the actual codes are different. There are a great many computerized formatting systems based on this type of coding, some of them designed to accommodate braille formatting as well as print, and much useful work has been and continues to be done by them. Even if you do not use such computerized formatting systems, if you have had occasion to re-type several pages of a paper just because of a few editorial changes, you can appreciate how much labor is saved by having the computer re-do the tedious page formatting after you have made just the essential text changes in the original file.
Superficially, SGML codes are a lot like format codes, but they have important additional advantages. Again to keep this in the concrete, let us re-code our original example SGML-style:
[start-heading] First Heading [end-heading] [start-paragraph] This is the text of the first paragraph, which would normally be much longer but we do not wish to belabor this example. [end-paragraph] [start-paragraph] This is the text of a second paragraph. Again we will be unusually brief. [end-paragraph] [start-heading] Second, Somewhat Longer Heading [end-heading] [start-paragraph] This is the first paragraph in the second section ... [end-paragraph]
The first thing we notice is that now the codes no longer refer to skipped lines, centering and such matters of appearance but rather to the CONTENT of the material, that is the nature of the text in the logical organization of the document. This corresponds to the way that the original author thinks about the document. That author may not know and may not care what formatting devices, such as line skips and centering, may eventually be used to format the document for presentation, but he or she (or an allied specialist) can still enter these content-oriented codes because they correspond to natural divisions of the material itself. When it comes time to publish, a person whose specialty is document appearance can decide how to turn these codes into formatting rules. There are various ways of doing this. One way might be to specify what the SGML tags "mean" in terms of formatting tags, for example:
These rules aren't quite right, because if they are taken too literally, then for example, we would wind up with two skipped lines between paragraphs. But we did promise to stay clear of technical details; you get the idea.
With respect to the eventual formatting, then, SGML coding may be said to be "indirect." That is, you can't really tell, from the original file alone, what the document will look like, but must reference the rules in order to figure that out. This is sometimes a disadvantage, but in many important situations it is more than offset by advantages that also derive from this indirectness. One is that, as we have seen, the text coding on the one hand, and the drawing up of the formatting rules on the other, can be done by separate people each of whom is especially appropriate for the particular task. Another is that it remains possible for each to work independently of the other. The author may change the text to improve or update the content, while the document designer may alter the document formatting rules, yet neither gets in the other's way. An important corollary is that eventually there may come to be multiple sets of formatting rules, each for a particular type of document, such as a magazine article set in columns, a hard-cover book, and a paperback - some of which may not even have been contemplated at the time of original composition.
That's why SGML is "generalized" markup: it does not specifically determine the format but rather can work with many different format styles.
People who work regularly with word processors may recognize a closely related concept here, namely the notion of a "style," as they are now usually called. (Especially in older word processors, the term "macro" may be used with much the same meaning.) Basically, defining a style is equivalent to giving a name to a collection of formatting codes. After defining a number of styles, the codes that you use thereafter in the text may consist only of the style names, with no further need to reference the basic formatting codes directly. If, for example, the styles defined had the same names as our four SGML tags, and were equated to sets of format codes similarly to the four rules listed above, then the coding of the file could be entirely indistinguishable from SGML, and have the same quality of indirectness and consequently the other, mostly beneficial, qualities that derive from indirectness.
Thus styles, consistently used, can have many of the same benefits of SGML. However, with styles there is generally no mechanism to enforce consistent or logical use. Thus, for example, nothing would prevent using a "start-paragraph" tag between a "start-heading" tag and its corresponding "end-heading" tag. It is chiefly on this point that SGML goes beyond styles. With SGML, the set of tags that can be used, and the ways that they can be used, is precisely defined in a separate file called a Document Type Definition (DTD). For example, the DTD defined for our simple case would not only list the four desired tags, but would undoubtedly also specify that paragraphs may not occur within headings, nor vice versa. Thus the user of an SGML system is spared the possibility of making illogical coding errors.
Consequently, from the perspective of the DTD designer, it is possible by means of the DTD to enforce a required "structure" on the document. That is, he or she may specify, for example, the order in which various kinds of headings can appear, whether they are mandatory or not, and many other matters that ultimately determine what authors may do when writing documents governed by that DTD.
With respect to what can be in an SGML document, then, we may say that it has an "enforced structure." As with indirectness, this quality can sometimes be a drawback, because you can't simply introduce a new tag into the text file, any more than you can directly specify an imaginative new format. Rather, you must first define the tag (or more properly the start-end tag pair, enclosing a "text element") in the DTD, and also specify how it must be used; only then may you use the tag in a document associated with that DTD. This may be viewed as a loss of flexibility or at least spontaneity, but it is a positive gain in many cases where it is necessary to ensure uniformity over large classes of documents. Examples of such cases would be military procedure manuals and the software user's guides within a series for a computer system. It is obvious, then, why SGML is most popular in those organizations that must regularly issue such documents.
As computer-related technologies go, SGML is rather old. Deriving from work by William Tunnicliffe, Charles Goldfarb and others in the late 1960's and through the 1970's, it has become both a standard of the International Standards Organization and the technology behind several commercial products.
Today, though, SGML is still not widely used for general document production. Rather, its use remains largely tied to those situations where enforced structure is highly desirable. Most documents are produced in circumstances where there is less need for formality, where the task at hand is primarily to produce one specific edition, and where it may even be desirable to use innovative format techniques to enhance document content through visual aesthetics and interest. These characteristics run counter to SGML's properties of indirectness and enforced structure. Consequently, it is not surprising that the great bulk of document production still takes place using systems that are appearance-oriented. All of the most popular word processors used in business offices, such as WordPerfect, Microsoft Word and Ami Pro, and all of the most popular page composition programs favored by professional publishers, such as CorelDraw and PageMaker, are of that kind.
Despite the fact that appearance-oriented methods still dominate after all these years, SGML has remained an important technology, and more to the point now appears to be gaining in importance as its strengths are more recognized and needed. As always, things are changing. Increasingly, publication in a specific paper format is not the end of the story for a typical document. Instead, it is now more likely that the information will be retained in a database to allow for electronic reference, and also that it will be retained for possible publication in alternative formats, including those specifically adapted for persons with disabilities. Information in a database is more useful when it is structured, so that for example you can retrieve just those documents where a particular person is listed as author, without retrieving those where that person is otherwise mentioned. As we have seen, both this kind of structure and the indirectness that favors alternative formats are defining strengths of SGML. Consequently, there seems to be increasing interest in SGML, with attendant progress in technology, especially along the lines of combining SGML with appearance oriented methods so that it is easier to experience the best of both. For example, SoftQuad's Author/Editor, which is firmly SGML-based, nevertheless allows viewing and working with the document in formatted form on screen, as is typical of appearance-oriented word processors, and also provides many other convenience functions to reduce user involvement with the technical aspects of markup. We are also seeing general-purpose DTD's being adopted as standards, so that organizations and authors typically do not need to design DTD's unless their needs are quite specialized. Lastly, from the appearance-oriented end of the spectrum, connections to SGML or at least SGML-like facilities are beginning to appear. Thus the direction that all of this is going is clear, in my opinion, even if the final form of the technology is not so clear because there is quite a ways yet to go.
As already discussed above, the indirect way that SGML specifies format makes it especially suited for cases where a document is to be produced in multiple formats. It is really just a corollary of this principle that makes SGML beneficial for braille production, for in most cases braille is an alternative publication format for a document already produced in print.
The treatment of ordinary paragraphs provides an example that is both simple and of practical importance. Let us assume that the print copy skips lines between paragraphs, as in our example of the previous section. Even though that is now probably the most common format used in print, it is not customarily used in braille; rather, simple paragraph breaks are usually shown only by an indentation of the first line, without skipping a line. On the other hand, there are cases where a skipped line in print could correspond to a skipped line in braille -- around headings and tables, for example. Consequently, a file coded for the appearance of the print document, as in the first coding presented above, cannot be used just as it is. Nor can it easily be converted by automatic means, because some of the line skips are for paragraph breaks and some are for other purposes. Thus, especially in practical cases that are naturally more extensive and complex than our example, considerable human labor, of a tedious nature, is needed to help sort out the various purposes of the skipped lines and other print formatting devices. By contrast, the SGML file contains exactly the needed information: paragraphs and headings are clearly and separately identified and so the appropriate braille formatting is readily automated.
Perhaps this is the place to mention that, from what I have observed, a saving of human labor in braille production generally translates into more and better braille, that is to more productive and interesting jobs for those who work with braille, not lost jobs!
Coming back to the subject, another way of looking at SGML files is that they are more useful than appearance-coded files because they contain more information. That is, they not only determine (indirectly) WHAT is done in the way of formatting but WHY, in terms of the author's intended structural divisions. That additional information happens to be quite useful for braille production.
The potential benefits of SGML have long been evident to the community involved with automating braille production. Back in the early 1980's, the National Braille Press carried out a project called POINTS, under the sponsorship of the Library of Congress, to investigate among other things the viability of using SGML (then called "generic coding") as a common target for conversion of text coming from various typesetting systems and other disparate sources, and as a common source for text to be published in various alternative formats including braille. By obvious analogy, this idea was called the "hourglass" principle at the time, with SGML serving as the narrow working center of the hourglass. All of us involved with that project believed in SGML on theoretical grounds, and at the end of the project felt that our beliefs had been substantially confirmed.
It must nevertheless be acknowledged that, when it comes down to the production techniques developed in the POINTS project that continued to be used, most of them actually "went around" SGML in most practical cases. That is, the print format coding was, and still is, mostly converted directly to braille format coding without ever going through an SGML stage. Why? Because most real braille production is concerned with just that specific format, and takes place under get-the-job-done constraints on the use of personnel and other resources. Many different kinds of literature, some of them requiring innovative format treatment in braille, must be processed. In other words, the same practical realities that have led to the dominance of appearance-oriented methods in the print world are also operative in the braille world. Under those circumstances, conversion into SGML first seems like unnecessary overhead, an extra step into an indirect language, that is insufficiently rewarded by SGML's benefits because additional production formats are not often contemplated. Even when one other adaptive format, such as large print, is regularly produced, the practical balance has seemingly not yet tipped towards widespread use of SGML.
Despite these sobering realities, it has long been quite plain that SGML would work well for the braille community if only it were more widely used in the print community, that is if SGML files, coded for a commonly understood DTD, were more generally available as the starting-point for braille work. As discussed earlier, the print world for its own reasons seems to be showing increasing interest in SGML, and so that long-awaited condition may finally be on the horizon. Moreover, we can point to at least three other factors in our favor. First, there are initiatives, such as the recent "Texas Braille Bill," that promote the regular transfer of electronic media from the print publishing industry to alternative-format producers. This has the effect of linking the two kinds of organizations economically, so that the efficiencies of SGML are more operative at the time of original coding. Secondly, the efforts of the International Committee on Accessible Document Design (ICADD) have led to standard DTD's that serve as a well-defined conversion target, in effect an accepted concrete declaration as to "this is what we want," so that the designers of systems for print production can begin to link them to the needs of the braille world. Thirdly, stimulated by those other factors, both commercial efforts and academic projects, such as the one on mathematics braille at Bradford University, now seem more centered on SGML technology.
No. Many of the problems associated with braille production are more properly associated with the rules for transcribing the text itself, as distinct from arranging the text on the page. As an example, the current rules of English literary braille require that acronyms and abbreviations be treated differently from regular English words that happen to be capitalized. It is beyond the scope of this paper to detail the reasons behind this distinction, though it should be noted that they are well rooted in braille tradition and can be seen as neither arbitrary nor foolish when considered in the entire context of that tradition. That distinction, however, can at times be difficult even for human transcribers. Suppose, for example, the following capitalized headline were to appear in a newspaper in the United States: EUROPE JOINS US IN TRADE PACT. It would be impossible to tell whether "US" stood for "United States" or was simply a pronoun, yet the braille rendering would require such a distinction. Automated conversion, perhaps needless to say, runs into difficulties with this distinction even in the much more numerous cases where human judgment is not so challenged.
It is easy to imagine an SGML "solution" to this problem. We could invent a tag pair to make the required distinction; for example we could project that the original author or someone else along the way would enter something like EUROPE JOINS [begin-acronym] US [end-acronym] IN TRADE PACT when "United States" was intended, leaving the unannotated case to imply that the pronoun was intended. It could even happen that such a tag could serve some print purposes, such as in a book where distinctive "small caps" are used for acronyms and regular capitals for other purposes. Realistically, though, the need for such a distinction would not be commonly felt in preparing print, and so could not be relied upon as a solution for braille purposes. This fact becomes even more obvious when we consider other kinds of distinctions required under current braille rules, some of which are even harder to relate to any conceivable print need. For example, the word "tuberose" would be brailled differently when it is a noun (a tuberous plant) as opposed to when it is an adjective (a variant spelling of "tuberous"). For another example, depending on the specific braille code being used and other judgment factors, the expression "(b)" (not counting the quotes) might be brailled differently in each of the following circumstances: (1) when it is used in parallel with "(a)" etc. as an enumerator in a list or outline; (2) when it is a parenthesized reference to the letter b; (3) when it is an expression in a mathematical context; and (4) when it is an excerpt from a computer program.
These considerations, and others, have given rise to the "Unified Braille Code" (UBC), which is not yet an official code but a research project of the Braille Authority of North America (BANA). UBC aims at defining the relationship between print symbols and braille symbols in a way that minimizes ambiguity and judgment problems, in BOTH directions of conversion, and further encompasses the needs of technical literature, all while preserving all the essential characteristics of current English literary braille.
It would take us too far afield in this paper to elaborate further on UBC; that of course has been done elsewhere as to motivation, and is still under development as to methodology. Suffice it to say that SGML and UBC are both positive developments for braille; that neither is sufficient in that each solves problems that the other does not; and consequently that they are entirely complementary, which is the main point of this paper.
As a concluding footnote, in case it may appear SGML and UBC taken together bid fair to solve all braille problems, it may be worth mentioning that they do not. When we consider all the ramifications of foreign languages (even in English context), music notation, and graphics, we find ourselves at the threshold of the problems that we will be pondering for many years to come. Human experience and judgment remain a valued part of the braille transcription process, all the more so because an increased volume of automated transcription can only be accompanied by an increased incidence of the "hard" problems that only people can solve. SGML and UBC will, we expect, free those people to concentrate on those kinds of problems.
At last October's Closing the Gap Conference, Xerox-Kurzweil demonstrated a prototype of its new Reading Edge portable reading machine. The first production models of the Reading Edge were shipped in mid-December. The university where I am employed purchased one of these units for my use.
This article describes my experience with the Reading Edge and makes some comparisons with other Kurzweil products. No attempt is made to compare this technology with that from other producers. Although I have seen other reading technologies demonstrated, my experience has been exclusively with Kurzweil products.
Several years ago, my university purchased a Kurzweil Personal Reader. This unit is housed in the university library and is available to members of the university community who cannot read small print. I have made extensive use of this machine.
In the summer of 1991, I had an opportunity to evaluate a Kurzweil PC KPR Model 35. This opportunity came about through the efforts of Mr. Harold Abraham, the regional distributor of Kurzweil products, and officials at Xerox/Kurzweil. The PC KPR Model 35 is a hardware/software combination consisting of boards which fit inside a personal computer, OCR software, and a special book edge scanner. In 1992, the university's Office of Student Supportive Services purchased one of these units for student use.
Anyone who has used any of these products will have a fairly good understanding of all other products in the line. The Personal Reader shares with its predecessors external keyboard control through a keypad, or in the case of the PC KPR Model 35, the computer keyboard. All of these units utilize DECtalk speech, and all employ, or can employ, versions of the book edge scanner. This scanner permits users to place material, including one side of open books, on the face plate of the scanner. Most other scanners have some difficulty in scanning books since the entire open book must be placed face down on the scanner plate. Under these circumstances, text near the binding may not scan.
In spite of these similarities, the Reading Edge differs in a number of important ways from other Kurzweil products. Three of the most important differences are portability, price, and the type of laser. The Reading Edge, as far as I know, is the first reading product designed to be portable. The unit is 19.5 inches wide, 15 inches deep, and 7.5 inches high at its highest point (without being raised on supported legs). It weighs 24.5 pounds. Xerox supplies an optional carrying case for the unit and accessories, for approximately $150. Although the 24.5 pounds listed in the documentation appears to be an accurate weight, the unit, when packed in its carrying case, subjectively feels much heavier. This is, perhaps, because of the balance of the unit in its case. It is somewhat awkward to handle. At the time the university purchased the unit I am using, Xerox was charging $5,500 for the Reading Edge and documentation in two of three available forms. Actually, the unit I am using came with documentation in cassette, print, and braille at no extra charge. I have been told, but cannot confirm, that all three forms of documentation are now being shipped at no additional charge.
Both the Personal Reader and the PC KPR Model 35 use a red laser in their scanners. In scanning and photocopying equipment using lasers, the laser will be of some specific color. Printed materials in that color or, in some cases, colors close to that color, will be unreadable. This drop-out color effect is actually utilized by producers of some materials to render these materials uncopiable. Both game manufacturers and universities, for example, sometimes produce materials in colors which cannot be photocopied. The Reading Edge uses a light-green laser. Although theoretically this means that materials printed in or on this shade of green should be unscannable, I have yet to find an example which would not scan.
Besides being able to scan a wider range of colors and contrasts than its predecessors, the Reading Edge also handles difficult materials such as the output from line printers attached to the university's mainframe computer. This material absolutely would not scan on the PC KPR Model 35 regardless of the settings I used.
This is not to say that the Reading Edge effectively scans or recognizes everything. I have found that very light print as well as some unusual type styles will create enough errors to make the recognition unusable. I have also found, however, that by playing with various settings, including brightness, or by placing a backing sheet behind some difficult materials, I can greatly improve the recognition.
The Reading Edge shares many of its features and adjustments with earlier Kurzweil products. Beyond the differences already noted, this unit is both smarter and faster than earlier units. One feature I particularly appreciate is the automatic page orientation. The unit can tell whether the material is portrait or landscape and how the page is oriented. The central-processing unit, a 50 MHz processor, is far faster than anything previously available. A control on the right side of the unit allows virtual infinite variation in speech rate without cycling through all previous settings. Features on the keypad have been expanded and are self-documenting using a help key.
As Kurzweil users would expect, the documentation is well organized, clearly written, and fairly complete. The first time I had an opportunity to use a Kurzweil product, the Personal Reader, I used the documentation to connect the unit to my laptop computer and was downloading text within 30 minutes. The documentation for the Reading Edge is at least as good. As an example, there is a section on serial communications which novices should be able to understand. My only real complaint with the documentation is that much of it is too elementary. I believe the company should consider an approach RDC used when preparing documentation for BEX. As an experienced user, I would like to have been able to skip the elementary descriptions and to go directly to the "Master Level."
At this point, a reader might wonder if there is a downside to this unit. My answer would be "not really." As indicated previously, there are some materials with which the Reading Edge has difficulty. These appear to be much more infrequent than with earlier products. The unit does have one annoying problem that I hope the company will solve in the future. On occasion, when engaged in some difficult recognition, such as a complex statistical table, the system will appear to go catatonic. It simply stops and fails to respond to any input. The only recourse is to turn the system off and back on. All text recognized up to that point is safe in non-volatile memory, but it is a nuisance.
It is impossible, in an article of this length, to give a complete description of the Reading Edge. I have not described most of the controls, ports, keyboard features, memory, translation capabilities, and a number of other capabilities. If you want more detailed information, you should contact Xerox Imaging Systems Incorporated at (508) 977-2000 [see Facts on File for more complete information] or contact your regional Xerox representative.
[About the author: Richard Wright is Professor and Head of the Department of Sociology/Social Work at Northern Michigan University.]
For sale: Hewlett Packard ScanJet with Calera recognition card and software. Daughter card has 4 megabytes of memory built in. Will scan up to 300 dots per inch and change scanned text into ASCII or most popular word processor formats. Works with 100% IBM compatible computer. Asking $1695. Price negotiable.
TeleSensory VersaPoint 40 embosser. Uses continuous feed paper. Does graphics, wide and narrow paper, and sideways printing. Two units, both are 4 years old. Asking $1895 plus shipping for each.
Please contact: Isaac Obie, 755 Tremont St., Apt. 205, Boston, MA 02118; (617) 247-0026.
Munio Makuuchi is a third generation Japanese American whose poetry and art reflect his childhood experiences in a relocation camp in Southern Idaho during the Second World War. He lives in Madison, and is part of the Raised Dot extended family. If you are interested in obtaining a copy of some of his poetry in braille, please contact Raised Dot Computing.
The Beates Notation Guide is a musical staff made of metal lines pinned on a cork board. Notes can be pinned on the staff to write musical phrases. APH no longer distributes the Beates. I am looking for extra notes and would appreciate information about where I could obtain part or all of a set. Thanks! Contact: Margery Dotson, 1901 N. Baylen St., Pensacola, FL 32501; (904) 432-0894.
Susan Haldiman, Shipping Magnate;David Holladay, President; Aaron Leventhal, Programmer; Linda Millard, Bookkeeper, Susan Murray, Office Manager; Caryn Navy, Vice-President.