By: Richard Jones and Scott Flechsig
Part 1This section will only discuss the conversion of printed text materials to grade II Braille. The next section will discuss the process used to convert graphic information to raised line drawings and the final section in this series will discuss the process of converting mathematic and scientific notation into the Nemeth Code Braille.
Converting Text to Braille
In the past conversion of a printed text has been a slow, painstaking process. Trained transcriptionists, using a Braille Writer, manually translated each character or group of characters to its appropriate Braille symbol. Using this method, the transcription of large text can take literally thousands of man-hours and cost an exorbitant amount of money.
The Center for Disabled Resources at Arizona State University (CDR) is seeking to change the time and cost associated with production of a Braille text by using personal computers, optical scanners, and specialized software to speed the process.
Using a microcomputer to convert text to Braille is in principle a relatively simple process. The procedure uses a personal computer, either a Macintosh, an IBM or an IBM- compatible; an optical scanner; OCR (Optical Character Recognition) software and Braille translation software.
The selection of the equipment to convert printed text to Braille is very important. It should be selected with the task of scanning and translating as its primary objective. If you choose to use an IBM or compatible, the computer's processor should be at minimum 386-33 MHz and should have a hard-drive with at least 40 Megabytes of storage space. If you choose to use Apple computers, purchase a Macintosh SE 30 or a higher model. Either computer type, IBM or Mac, should have as much RAM as you can afford, with 6 Meg as a minimum. Access to a printer, a Braille embosser and a scanner is also required.
The market has been flooded by OCR packages and scanners for a variety of prices. There is a large range of scanners available -- flat-bed scanners, hand-held scanners, slide scanners, drum scanners, scanners that scan only black and white, and scanners that scan color. Accordingly, the prices for these scanners also has a large range, from $200.00 to more than $20,000.
Be careful in the selection of your scanner, it can "make- or-break" your text conversion program. Before you make the assumption that you only need a black and white scanner to scan printed material, you should carefully evaluate the work that will be scanned. Is any of the text that you will scan in a different color? Many texts use color as a highlight method and if you purchase a black and white scanner it may not pick up colored and highlighted characters. These characters would then not appear in your scanned document. A color scanner will allow you to scan the widest variety of text and retain the most information. So, if possible, we recommend that you purchase a color scanner. We also recommend a flat-bed scanner. The hand- held scanners must combine many scanning "passes" to produce an integrated document. Controlling the angle and speed of the pass manually is difficult at best. The flat-bed scanner controls these variables for you.
You should also consider the type of materials that you are likely to scan when you consider OCR software. There may be information that is graphical which you must make accessible to the visually impaired student. While it is possible to convert scanned information into raised line drawings, the quality of the scanner and software will determine the amount of extra work that must be done to create an integrated document.
The CDR uses Omnipage Professional (OCR) with an Apple scanner on a Mac SE 30 with 8 Mg of RAM and WordScan Plus (OCR) on a 386-33MHz PC Compatible with 10 Megabytes of RAM, 3.5" High Density Disk Drive, running Windows 3.1 with an HP ScanJet scanner. Apple files are transferred to the IBM format using PC Access on the Macintosh. This enables data obtained on one computer system to be used on the other. While it is possible to use Macintosh file utilities to read and write IBM files, PC ACCESS simplifies the process. The Center uses Duxbury Braille translation software. (Prices and addresses for the various software and devices listed in this article are listed at the end of the document.)
The process for text conversion is relatively simple. The operator enters the OCR software, OmniPage Professional or WordScan, and can set parameters that correspond to the type of text to be scanned. Is the material dot matrix or solid type? Is it text only or are there pictures that must be scanned and saved also? How is the contrast between the foreground and the background?
The operator may choose to scan only portions of the page. To do this "scan windows" are set up and the scanner only scans what you want. There is also an automatic set-up in most software packages that will attempt to do these activities for you. Only through experience can the operator decide when to set up manually and when to let the computer do it.
One of the questions that you must answer is if the document is a single sheet or multiple sheets. If it is multiple sheets the software will collate pages as it scans. Scanning multi-page documents makes a large amount of memory essential. The number of pages that you can scan at one time is directly related to the size of you RAM memory.
After the scanning parameters are established, scan the first page of your document. The software will begin a process of analyzing the scanned material and converting it to ASCII. After you have scanned the first page, it is important that you examine this test page and check it for accuracy. If the scanning parameters relating the type style, brightness and contrast were not set properly, the document will contain many scanning and OCR errors. Change the settings and try again until you get the optimal effectiveness.
Upon completion of scanning, the OCR software can convert the material to ASCII text. The operator may now edit the material for accuracy. It is possible to do this editing in the OCR software or on a word processor. Editing in a word processor is usually more appropriate since most word processing packages now contain a spelling checker with a large dictionary and more effective editing capabilities. To use the file in a word processor, it first must be saved in a format suitable for access by the word processor. Most OCR packages have built in formatting for popular word processors.
The latest version of Duxbury will allow you to convert a WordPerfect file directly into Braille. We have not worked with this version enough to evaluate its performance. Whatever product you use to translate your text, you will usually have to edit the text and you will always have to check it for errors.
The first step in editing is to compare the scanned document for accuracy with the original text. This must be done since OCR, while it has made great strides, is not infallible. When a document is scanned, the OCR software makes many decisions about the correct format of the text as well as the words that make up the document. While the document may appear as an accurate representation of the original, there may be important differences in the document's reconstruction. These differences will affect the format of the Braille document and must be checked at this stage in the process. Some obvious errors in formatting are easily edited, others are more difficult to see. For example hard returns (HRt) often appear at the end of a line in the middle of a paragraph. While these hard returns are not seen in the word processor document, they may be very apparent in the Braille document. Hard returns are one of the most powerful Braille formatting commands. It forces a new line of Braille to begin. Since a Braille document is only 40 characters wide and the Braille translation software shortens and abbreviates combinations of letters, the HRts that appear in the word processor document at the end of a line usually will not end up there in the Braille text. Consequently a new line of text will begin where it is not required and will confuse the reader. This is a very crude form of Braille, one that will force the Braille reader to compensate, unless the problems are corrected at this step in the Braille conversion process.
The obvious way to check for these errors is to use the command in the word processor to show the formatting commands and then to go through the document looking for these errors in formatting, deleting them as you go. Another method is to change the column display to another value, say 60, and visually check for breaks in the formatting.
Another advantage word processors have in the editing process is the use of "Macro Commands" to format the document for Braille. A macro is a method of programming a single combination of key strokes to perform a complex function automatically. For example, it is possible to have the word processor search for erroneous hard returns, centering commands for text, special fonts and format changes and to delete them as it finds them. Other Braille translators have similar features.
Documents will also need Braille commands to preserve formatting. The proper indentation of a Braille document paragraph is two Braille cells. It is possible to program a macro that is capable of entering these Braille commands.
After a document has been checked and edited, it is ready to be converted into Braille. Some Braille translators use only ASCII files for conversions. The word processing file must therefore be saved as an ASCII file. In WordPerfect 5.1 the command CDR used to save ASCII text files is "Control F5, 3 Save as , 1 Generic."
At this point the document is ready to be converted to Braille format by the translation software. After the document is converted to Braille format, it is ready to be embossed, but one additional step should be performed. The file should be viewed with a text reader to ensure that the proper overall formatting has been preserved. Make sure that page breaks that the translator inserted occur in logical places and that the Braille commands inserted during editing have performed as you expected. If any errors have occurred, correct them in the word processor document and re-translate the document. This ensures that the Braille given to the student is of the highest possible quality. Now the file is ready to be sent to the Braille embosser to be printed out as a Braille document.
Components of a Scanning System
While there are many more worthwhile configurations that would be effective in an OCR function, the products listed below are products with which CDR has a working knowledge and which have demonstrated the ability to produce quick and accurate results.
Microcomputers
IBM or Compatible 386-33Mhz with 8OMeg Hard Drive, 6Meg RAM, 5.25 and 3.5" floppies, DOS 5.0, and Windows 3.1 Macintosh SE30
Scanners HP Scanjet II (IBM) Apple Scanner (Mac) (note these scanners are not color scanners)
OCR Software
Omnipage Professional (Mac) Caere Corp. 100 Cooper Court Los Gatos, CA 95030 (408) 395-7000
Wordscan Plus (IBM) Calera Recognition Systems 2500 Augustine Drive Santa Calera, CA 95054 (408) 720-8300
Braille Translation Software Duxbury (Mac, IBM)
Part 2
Conversion of Math Symbols into Braille
(The paper version of this document includes a Math Symbol/Nemeth Code sheet, which is not available in ascii. Nemeth Code is much more extensive than the few symbols on this sheet, but these symbols are sufficient to Braille most lower division math textbooks.)
The following is a practical guide to producing Nemeth Code Braille with current technology. The discussion will focus on the use of Duxbury Braille translation software because that is the product currently used by the Center for Disability Resources at Arizona State University. This, however, does not imply that Duxbury is the only software capable of performing these operations. Whatever software you choose to use, the procedure followed will be very similar to the steps listed below.
The current trend in E-Text, Electronic Text production, is toward a standard generalized mark-up language (SGML). SGML will allow rapid translation from one format to another through the use of embedded, software-read commands or "tags." To change from one output format to another all that would be required would be to change the appropriate tags to produce the required format. At this time, however, SGML is not fully developed or available for general usage. Software standards for future SGML conversions are still being discussed. Until such time that SGML becomes available, the strategy described below will allow a facility to produce readable Nemeth Code Braille without the cost of a Braille transcription contract or the extended completion time for volunteer transcription guilds.
The first step is to realize that most of the symbols used in higher mathematics are not part of the traditional ASCII character set. Also the printed page typesetting of mathematical equations does not readily allow translation by a Scanner/OCR system into a symbol-by-symbol, line-by- line ASCII document. It is therefore not possible to scan and translate directly from a typeset mathematical equation to an ASCII equivalent. Instead, a two-step process must be done anytime there are mathematical equations or other text or symbols that cannot be directly converted to ASCII.
First, the text must be scanned and recognized by an OCR package to convert any literal text on the page to ASCII. Symbols or equations that cannot be directly converted will appear incorrectly or possibly not appear at all in the converted ASCII document. The next step is to edit the document with a word processing package and note where equations or symbols occur in the text. At the appropriate places, Braille translation software control codes must be inserted to allow for the Nemeth Code Braille characters to replace the non-ASCII symbols or equations. This is essentially the entire mathematics translation process. There are, however, several considerations that make the process more sophisticated than this simple description.
In order to produce readable mathematical/symbolic Braille, the computer operator must be aware of how the software package converts text to Braille and how it produces Nemeth code. The most common mode of Braille conversion is to Grade II. Grade II Braille uses contractions and concatenations which greatly reduce the size of the finished document. These contractions are automatically done when you convert your ASCII text to Grade II Braille. If you enter a mathematical equation in Grade II, there is the possibility that the translation software will contract and concatenate the equation, making it unreadable or misleading. Alternatively, the translator may replace a mathematical symbol with the word equivalent. For example the following "1 + 2 = 3" may be translated as "1 plus 2 equals 3." In some cases this may be acceptable, but in others it may not. To prevent this, it is necessary to tell the Braille translation software when to drop out of Grade II and go to literal Braille, which is a character for character translation. It is in this mode that production of math and graphics is possible.
In Duxbury the command $cz is used to go into literal Braille. This command is inserted at the beginning of a section of math notation to instruct the translator to used the exact characters that follow it and not to try to insert contractions. The codes inserted in literal Braille are Nemeth Code symbols and will be the same codes used to translate the equation regardless of the Braille translation software. At the end of the math notation the Duxbury command $tx is used to inform Duxbury that it can now go to Grade II conversions again.
At Arizona State University, engineering and math student workers and an honors organization volunteer program are used to enter the control codes in literal Braille to produce Nemeth Code. These students have an understanding of the equations, which makes it easier for them to decode the exact meaning of the equations and know how to change the equations without changing the meaning of the expression. While it is important that they have an understanding of mathematics, they do not need an extensive knowledge of Braille. A few formatting rules concerning spacing and a "Cheat Sheet" of math symbols and the corresponding Duxbury code required to produce the Nemeth code for that symbol is all that is needed to produce readable Nemeth Code translations. Initial training time to learn the "system" is approximately four hours. The student must only enter the appropriate control codes to translate the mathematical symbols.
The code for the equation described above would be:
$cz #1+2 .k #3$tx
Where $cz indicates the start of literal translation # indicates that the symbol following is numeric .k is the Nemeth code for = $tx indicates return to Grade II translation
Once the codes are inserted, the entire document can be converted to Braille. The areas that specify literal Braille are converted, as is, while the rest of the document is contracted and concatenated to Grade II Braille. At this juncture, to ensure that the translated text maintains its readability and integrity, the computer operator should look at the document in a text editor or a word processor to see exactly how the document format will appear after it is printed. The document will not be readable since the translation has contracted characters, but the overall format is discernible. If an equation is separated by a page break, additional editing must be done to preserve the integrity of the equation.
The document can then be printed on a Braille embosser. It is a good idea to have the finished copy evaluated for errors by someone with a knowledge of Braille and Nemeth code. This is considerably less expensive and usually more accurate than having a Braille transcription done outside the university.
ASU did a survey of sites across the country that would do a conversion of a statistics textbook and found that prices for translations were approximately four dollars per print. Volunteer transcription guilds have production times of between six months and two years. Our own students were producing four to six text pages of equations per hour. This represents over a 75 percent reduction in cost the of producing Braille translations of mathematics texts.
Part 3
Converting Graphical Information to Raised Line
Drawings
Many texts contain information that is expressed graphically. Sometimes this graphical information is either too difficult to describe or is simply the best, most useful way to express the ideas contained in the graphic. In either case, converting the graphic to a tactile, raised line drawing allows the visually impaired student to have access to the information.
The conversion of graphical information to a raised line format is also a relatively easy task. To do this conversion, some additional software is required. First, a "paint" package, such as PC PaintBrush, is required to generate and/or edit a graphical drawing. Also, a "capture" software is necessary to convert an image into an embossable ASCII format. The CDR uses VersaPoint Graphics from TeleSensory to perform this function.
The process is very straightforward. First, the graphical image is reproduced, either by directly scanning it into memory or by drawing it in the paint package. After this has been done it is converted to an ASCII format and is ready to be embossed.
While this sounds very, very easy, there are, however, several factors, both physiological and technical that complicate the process. The difference in cognitive processing abilities of visual versus tactile inputs is extremely large. Much more information and detail can be processed and integrated visually than tactually. It is simply not possible to perceive as much detail from a raised line drawing as from a visual image. To further complicate the problem, visual impairment, total or partial, can result from a variety of causes. Some of these causes affect not only vision but tactile responses as well. Diabetes, for example, can result in both blindness and a numbness in the extremities that limits the diabetic's ability to distinguish between closely spaced Braille dots.
This leads to the technical complications of producing raised line drawings. Braille graphics have, at best, a very limited resolution. This is due to the very nature of Braille embossing. A standard 80-column by 25-line Braille page has approximately a 100 x 100 "pixel" resolution, where each dot is considered a pixel. This is about equivalent to CGA drawing resolution. The low resolution value makes it difficult to put much detail into a drawing. Any fine detail will blend together and be lost when the image is embossed. For this reason, it is usually easier to draw the picture than to scan it since the scanner will reproduce all details.
Another advantage of drawing the graphical image instead of scanning it, is that the picture can be drawn at the 100 x 100 pixel scale required by the capture software. If an image is scanned, it must be reduced to fit this area. This runs the details in the drawing together and makes the embossed image unintelligible. These problems become worse for a student who also has a tactile impairment.
When drawing a graphical image remember that although the drawings must be greatly reduced in detail and simplified, they must still portray the information to a visually impaired student that the original picture gave the sighted student. To do this, you may need to make changes in the way that graphical details are expressed. For example, in text a pie chart uses color or shading to differential between the different slices of the pie. To represent this in Braille, you have two options:
1) represent each color or shade as a different texture
2) clearly mark the boundaries between each section and label each section
Option one seems to be the obvious choice, but it is not always the best choice. Using texture works well only if the image is large and there are few texture changes. It is difficult to produce many truly distinguishable textures due to the low resolution of Braille embossing and difficulty in interpreting and integrating tactile input. If the sections are small, it also becomes difficult to tell where one texture ends and another begins. For this reason, it is often better to keep the drawings much simpler and use descriptive labeling to present details to the reader. This brings up the final factor that complicates the conversion process -- Braille labeling of the drawings. The labeling and captioning of drawings must be done in the paint package at the time a graphic is drawn. This means that each Braille character must be drawn as it is to appear on the page with each dot in the character represented by a dark pixel in the drawing. Currently, there is not a graphics font available to enable direct keyboard entry of these characters. The CDR and others are working to develop a Braille font, but until a font becomes available you can label your drawings in a couple of ways. (Duxbury has a font for use in Windows, but at the time of this article the CDR has not been able to evaluate the font or determine if it is able to be used in a paint program) First, you can create a Braille character one pixel at a time. Each pixel must by turned "on" (black) or "off" (white) in the correct sequence to create the Braille labels. Care must be taken to properly align and space each character to ensure readability. This can be a slow process, especially if there is much text labeling in the drawing. Alternatively, the labeling process can be accelerated by creating a template of the characters that can be copied and then cut and pasted into the document as needed. While neither of these labeling methods is the best or most elegant solution, they will serve the purpose until a Braille font is produced.
After the drawing has been properly drawn and labeled, it must be "captured" to an ASCII file. In VersaPoint Graphics this is done by:
1) pressing the Alt and Right-Shift screen to display the capture box
2) moving the capture box over the drawing using the arrow keys
3) pressing "C" to capture the image to a disk file When this has been done, the file can be inserted into a Braille text file and embossed.
Richard Jones (5-1234) ICRRJ@ASUVM.INRE.ASU.EDU Disabled Student Resources Arizona State University
Copyright by Richard Jones, October, 1992. _____________________________________________________
EASI Contacts:
EASI E-mail Address: EASI@EDUCOM (Bitnet) EASI@EDUCOM.EDU (Internet)
EASI Address: Project EASI c/o EDUCOM/EUIT 1112 16th Street, NW, #600 Washington, DC 20036
Dr. Norman Coombs, Chair Professor of History College of Liberal Arts Rochester Institute of Technology One Lomb Memorial Drive P.O. Box 9887 Rochester, NY 14623-0887 Phone: (716) 475-2462 FAX: (716) 475-7120
NRCGSH@RITVAX.BITNET NRCGSH@RITVAX.ISC.EDU (Internet)
Carmela Castorina, EASI Editor Assistant to the Chair
CSMICLC@MVS.OAC.UCLA.EDU Phone/FAX: (310) 640-3193