Web Posted on: March 16, 1998
Translating Academic Information into Braille
Terri Hedgpeth
Program Coordinator For Blind/Visually Impaired Students and Alternative Print program
Disability Resources For Students
Arizona State University
I. Introduction:
The following sections are designed to provide the reader with an overview of the process for converting college level text into alternative print. This article is based on procedures and techniques developed by Disability Resources for Students at Arizona State University for the production of mandated alternative print accommodations. Specific software and hardware brands are listed in the article. The listing of vendors, does not, however, imply an endorsement of one vendor over another. DRS/ASU uses certain brands, versions or models and has developed a system around these choices which are most effective in meeting our needs in alternative print production. This article assumes that the reader is computer literate and has or can learn the basic command structure of the software and hardware used by DRS/ASU.
The following section will only discuss the conversion of printed text materials into grade II Braille. The next section will discuss the process used to convert graphic information into tactile drawings using the computer. And the final section in this series will discuss the process of converting mathematic and scientific notation into Nemeth Code Braille.
Converting Text to Braille
In the past, the conversion of printed text to Braille was a slow, painstaking process. Trained transcribers, using a Braille Writer, manually translated each character or group of characters into the appropriate braille format. Using this method, the transcription of textbooks could take literally hundreds of hours and cost an exorbitant amount.
It is the goal of DRS/ASU to decrease the amount of time and expense associated with the production of Braille.. Using a personal computer and other technology to convert printed text into Braille is, in principle, a relatively simple process. The process requires the following equipment: a personal computer, either a Macintosh or an IBM compatible; an optical scanner; Optical Character Recognition software (OCR); Braille translation software; and a Braille embosser.
The selection of the equipment to convert printed text into Braille is very important. It should be selected with the task of scanning and translating as the primary objective. If an IBM or compatible is chosen, the computer's processor should be, a minimum of a 486-66 Mhz for IBM compatible, or a PowerMac 7100 for Macintosh, with 16 Megabytes RAM and a hard-drive with at least one gigabyte of storage space. Access to a Braille embosser and a scanner is required. The necessary software includes OCR software, a word processing package, and Braille translation software. At DRS, we are currently using the following software packages in our Alternative Print Production lab: WordPerfect 6.0 for DOS, both Omny Page Pro and TextBridge for OCR, and Duxbury Braille Translator. (Prices and addresses for the various software companies and devices mentioned in this paper are available from the manufacturer.
There are a number of OCR packages and scanners available on the market today. The scanners vary in price and type. I.e., there are flat bed, hand held, slide, and drum scanners; and they come in black & white or color. Accordingly, they range in price from $50.00 to over $30,000.
Be careful in the selection of a scanner, it is crucial to the text conversion process. Do not make the assumption that only a black and white scanner is necessary to scan printed material. More and more, publishers are utilizing color as a method of highlighting important concepts. Thus a black & white scanner doesn't pick up colored and highlighted characters as readily as a color scanner does. Therefore, these characters will likely be missed during the scanning process. A color scanner will increase accuracy in scanning a variety of such text formats. A flat bed scanner is preferable to other types. Hhand held scanners require many scanning "passes" to produce an integrated document. It requires manually controlling the angle and the speed of a hand held device, which is difficult, time consuming and inconsistant at best.
The scanner should have a cut sheet feeder which also enhances accuracy and speed of the scanning process. The use of a cut sheet feeder will require that bound texts are unbound. Many print or copy centers can cut/remove the binding from texts for a minimal cost.
When selecting the OCR software you will use, the type of materials to be scanned must be considered. You may choose to purchase a package such as OmniPro for scanning text, and something like Adobi-PhotoShop for scanning graphic images. It is possible to convert scanned images 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 with Braille graphics.
Process for converting text:
The process for text conversion is relatively simple. The operator enters the OCR software, sets the parameters that correspond to the type and quality of text being scanned. Some of these parameters include whether the material is news print, solid type, font style, varied font styles and/or sizes, text only, text with graphics, multiple columns, and the level of contrast between the foreground and the background. The operator can choose to scan only portions of the page by defining "scan windows". Many current OCR software packages have an automatic setup option which will attempt to do these activities. Only with thorough experience can the operator know when to manually setup a page and when to let the computer do it.
One of the considerations that must be answered is if documents are likely to be single or multiple sheets. If the majority of the scanning will be multiple sheets, the software should collate pages as it scans. Scanning multi-page documents will require considerable RAM memory. The number of pages that can be scanned at one time is directly related to the size of the computer's RAM memory.
After the scanning parameters are established, scan the first page of the document then use the OCR feature of the software to convert the page to ASCII text. Examine this test page and check for accuracy. If the scanning parameters relating the type, brightness and contrast were not set properly, the document will contain many scanning and OCR errors. Change the settings and try again until scanning settings are optimized for effectiveness.
OCR software must be used to convert the scanned image to ASCII text after it is scanned. The operator may now edit the material for accuracy. It is possible to do this editing in the OCR software or in a word processing software package. Editing in a word processing software is preferable since such software contain spell check and a dictionary component for adding words which are not common to all subjects, thus, this will maximizing the editing process. To use a file in a word processing package, it must first be saved in the OCR software in a format suitable for access by the word processor. Most OCR packages have built in formatting for popular word processing packages.
The latest version of Duxbury will convert a WordPerfect or MS Word file directly into Braille, and for a straight text file it does a very nice job of conversion. However, it is easy to underestimate the requirement for editing a text file when products like MegaDots and Duxbury have an automatic conversion feature for word processing documents.--While These software packages do an acceptable job of converting text only, They are not designed to convert complex math and scientific text. Regardless of which translation software is chosen, the text must still be edited for errors before it is ready to be sent to the Braille embosser. For there are a number of errors that scanning software commonly make, as mention earlier.
In a post secondary institution, the goal of converting textbooks is not just to produce Braille or ASCII files. Rather, the goal is to produce a computer based representation of the printed text. It is extremely important to convey to those that control the accommodation budget that the conversion process for post secondary text is highly complex versus automatic. Nor is this process inexpensive. It requires a dedicated budget and trained individuals.
Anyone can scan a simple text document, save it as an ASCII file and run it through a Braille conversion program. That is not the goal of this article. To convert a math, science or other post secondary textbook into an alternative format requires a basic comprehension of the concepts presented in the text and the ability to maintain their original intent.
Some examples of Information that is lost or corrupted and requires a great deal of editing after the scanning is done, includes: The table of contents, footnotes, bold or highlighted words, headings for chapters and sections, text inserts, text page numbers, graphs, captions and descriptions of pictures, columns of information, scientific or math symbols. This information is just as essential to the learning experience of students with disabilities as it is for any other student. It is this type of information, in addition to the text, that is mandated for students with disabilities.
The first step in editing is to compare the scanned document with the original or hard copy text for accuracy. This must be done since OCR software, 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. One of the primary goals of this type of software is to produce a text file that resembles the print copy. While the document may appear as an accurate representation of the original, there will be important differences in the OCR document file. These differences will affect the format of the Braille document and must be checked at this stage in the translation process. Some obvious errors in formatting are easily edited, others are more difficult to identify. For example hard returns (HRt) are often automatically inserted at the end of a line. OCR packages generally insert (hrt)s every 65 characters, the length of a print text line. The problem with this is that a Braille line of text is only 40 characters long.While these hard returns are not seen in the word processing document, and infact are often not problematic for a print versionof said document. Thus, for the reasons given above, they will be very apparent in the Braille document. Hard returns are one of the most powerful or destructive formatting commands in a Braille document. Thus, unwanted formatting commands will force the Braille reader to guess the correct meaning and format of the text unless the these problems are corrected. This distinction may appear to be trivial, but documents that are haphazard in presentation will not meet the academic institution's responsibilities for mandated accomodations under section 504 of the Rehabilitation Act or the Americans with Disabilities Act.
The obvious way to check for these errors is to use the command in the word processing software to show the formatting commands or control-characters and then to go through the document deleteing these errors. Another method is to increase the margins an inch and visually check for breaks in the formatting.
Another advantage of word processing software in the editing process is the use of the macro function to expedite the formatting of the document for Braille. A macro is a method of programming the word processor to perform a complex set of functions automatically. For example, it is possible to have the word processor search for unwanted Hard Returns, centering commands, special fonts and format changes and to delete them as it finds them.
The word processing document will also need Braille translation commands to preserve the documents format in order to maintain the original meaning or intent. For a straight text document, most of these commands are automatically inserted by the Braille translation software.
Appendix A has a list of some of the macros used at DRS, tO make the editing process much easier. Some of these macros are nothing more than a quick way to enter multiple keystrokes. Other macros are very involved and perform multiple editing functions. Please keep in mind that spaces and hard returns are very powerful tools in Braille and that great care must be EXERCISED TO control when and how they appear in a document.
After a document has been SUBJECTED TO SUCH VIGOROUS checkING and editING, 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 DRS uses to save ASCII text files is "Control F5, 3 Save As, 1 Generic." In WordPerfect 6.0 DOS, save as "ASCII Stripped". DRS does not use Windows based applications for editing purposes.
The document is now ready to be converted to Braille format by the translation software. After the document is converted it should be reviewed to see how it will appear when it is printed. Duxbury has a "Browse" command that will allow the editor to see the file as it will appear in Braille. The Braille file should be reviewed to ensure that the proper overall formatting has been preserved. Make sure that page breaks inserted by both the editor and the translatION SOFTWARE occur in the appropriate places and that any other Braille commands inserted during editing have performed THE DESIRED FUNCTIONS. It is also a chance to check for Hard Returns which break lines at unwanted locations. If any errors have occurred, correct them in the word processor document and re-translate the document. This insures that the Braille given to the student is of the highest possible quality.
The file is now ready to be sent to the Braille embosser to be printed out as a Braille document. DRS prints out Braille on Braille paper with a perforated margin. It is an easy process to use a plastic comb binder to organize the embossed material.
A final step is crucial to the success of academic accommodations. A review of the Braille document by an individual with a knowledge of Braille. DRS hires university students, who use Braille, to perform this review. Several crucial functions are fulfilled by this review. It provides important feedback on the content, format and presentation of the Braille. It also permits the blind community on campus the opportunity to TAKE AN ACTIVE PART in their accommodations. And it gives an individual with a disability a chance to GAIN VALUABLE work EXPERIENCE and EARN A LITTLE MONEY. Finally, no matter how meticulous the student staff is in the conversion of text, bad habits will creep into the production of Braille. It is essential that the work be reviewed by individuals who were not involved in the production of the Braille and are critical of its quality.
Components of a scanning system
While there are many more worthwhile configurations which would be effective in an OCR function, the products listed below are products with which DRS has a working knowledge and which have demonstrated the ability to produce quick and accurate results.
Microcomputer
IBM or Compatible Pentium with at least 1 mIG Hard Drive, 16MG RAM (minimum), 3.5 floppy, DOS 6.2, and Windows 3.1
Macintosh Power Mac 7100, at least 1 MIG Hard Drive, 16 MG RAM (minimum), System 7.5
Scanners
HP Scanjet IIIc or better (IBM), cut sheet feeder, Apple Color Scanner (Mac)
Business is very involved in OCR hardware. If more than ten thousand dollars is budgeted for a scanner, THERE ARE scanners AVAILABLE THAT CAN scan and convert a duplex page (print on both sides) in less that four seconds.
OCR Software
OmniPage Professional (Mac and IBM) Caere Corp.
100 Cooper Court
Los Gatos, CA 95030
(800) 535-7226
TextBridge Professional version
9 Centennial drive
Peabody, MA 01960
(508) 977-2000
Braille Translation Software
Duxbury Systems Inc.(MAC,IBM)
435 King St. P.O.Box 1504
Littleton, MA 01460
508-486-9766
MegaDots
Raised Dot Computing
408 South Baldwin
Madison, WI 53703
(608) 257-9595
Braille embossers
Telesensory Systems Inc.
455 N. Bernardo Ave.
Mountain View, CA 94039-7455 415-960-0920
II. Converting Graphical Information to Raised Line Drawings
Most textbooks contain information that is expressed graphically. Sometimes this graphical information is either too difficult to describe or a graph is simply the most useful method of expressing the relationship of ideas. In either case, converting the graphic to a tactile, raised line drawing provides direct access to the information for a visually impaired student.
The conversion of graphical information into a raised line format To do this conversion, some additional software is required. First, a "paint" package, such as PC PaintBrush for DOS, is required to generate and/or edit a graphical drawing. A "capture" software is also required to convert an image into an embossable ASCII format. DRS uses VersaPoint Graphics from TeleSensory to perform this function.
The process for creating Braille graphics follows:
produced, either by directly scanning it into memory or by drawing it in the paint package.
Add all the necessary Braille labels.
Convert image to an ASCII image ready to be sent to a Braille embossed.
While this sounds very easy, there are several factors, both physiological and technical that complicate the process. The difference in the perceptual density of visual versus tactile inputs is extremely large. 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. I.e. visual graphics or depictions of information utilize color, gradiations of light to dark, icons, etc, to present concepts. To further complicate the problem, visual impairments, total or partial, result from a variety of disabilities. Some of these disabilities affect not only vision but tactile sensitivity as well. Diabetes, for example, can result in both blindness and a numbness in the extremities that limits an individual's ability to distinguish between closely spaced braille dots. These physiological parameters create technical complications in the production of raised line drawings. braille graphics have, at best, a very limited resolution. This is due to the very nature of braille embossing. A standard 40-braille cell by 25-line braille page has approximately a 100 x 100 "pixel" resolution, where each braille dot is considered a pixel. This 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 create the picture rather than to scan it, since the scanner will reproduce all details.
When drawing a graphical image for braille reproduction, the image will be greatly reduced in detail, but it must still convey the same information to a visually impaired reader that the original graphic gave the sighted reader. Often the presentation of some of the graphical information must be altered in the Braille document so that all of the information in the original document can be expressed. For example, a pie chart may use color or shading to differentiate between the different sections. There are two options possible to distinguish aspects of a chart or image:
- 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 textural changes required. 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 smaller than a braille cell, it is difficult to tell where one texture ends and another begins. For this reason, it is often preferable to keep the drawings much simpler and use descriptive labeling to present details to the reader.
Creating a Graphic
DRS has used this procedure on computer programming flow charts and three dimensional bar charts as well as a wide variety of charts and symbols. The following procedure will discuss methods of creating a Braille graphic and printing it as a single sheet or to insert the graphic into the "flow" of the text. In other words, to incorporate the graphic into the document in the same place as it appears in the standard text. The second procedure also will permit graphics and text on the same Braille page.
The software applications used by DRS are not the only applications capable of creating a Braille graphic. DRS has used this procedure for several years and has found it to be stable.
- Programs used at DRS
- Duxbury Braille translation program
- VersaPoint VPGraph image program for DOS
- WordPerfect (using and saving as DOS)
- PC Paintbrush (DOS based)
Program Setup Notes
Please verify that the program COPYX in the Duxbury Braille translator is, at least, version 2.23 or later.
Be sure that Duxbury is setup for a specific Braille embosser. If Duxbury is not configured for your Braille embosser, it may be able to print braille, but not graphics.
DRS uses PC PaintBrush for DOS to create the graphics that are to be Brailled. This is intentional. While there are many software programs with exciting techniques for enhancing images, there should be no "enhancements" made on a graphic image that is to be converted to Braille. The graphic image must be translated as a Braille dot for dot representation of the computer image. Any corruption or "adjustment" in the image created on the screen will corrupt the Braille representation that is finally printed.
The graphic must be produced in a maximum resolution of 100 X 100 pixels. Count out these pixels. The 100/100 pixel page is roughly the number of braille dots that can be produced on a 11 x 11 ½ inch Braille page. It is possible to create a graphic at a higher resolution and then reduce it to the required size, but this process will usually be ineffective, because some graphic detail will be lost in the compression process and it is helpful to see exactly how the graphic will appear on the Braille page. It is possible to create a picture file (.PCX) that is nothing more than a frame or box that contains the required number of pixels. An individual simply opens this graphic and creates the braille graphic inside this "box" or "template". The template defines the working area for a Braille page. When drawing a graphic image or chart, use the finest line available in PC PaintBrush, one pixel or one "dot" wide.
Experience is necessary to make the decisions necessary to create a "usable" graphic. While the working area is a very small portion of the screen, it still represents a full page of Braille paper. It is possible to have more than one graphic on the same horizontal line and be understandable to a Braille reader. It also may be necessary to create a graphic as large as a Braille page in order to transit pertinent information.
Labeling Graphic Information
The final factor that complicates the conversion process is labeling the graphic. The labeling and captioning of graphics can be done to the graphic while in PC PaintBrush. Currently, there is no graphic font available. (Duxbury has a font for use in Windows. The font becomes erratic when more than seven or eight characters are used in a printed Braille document). Until a font becomes available, there are several methods of labeling a graphic. First, it is possible to create a braille character one pixel at a time. This means that each braille character must be drawn as it is to appear on the page with each dot in the Braille character represented by a dark pixel in the drawing. The working area for a Braille page is so small, the "Zoom In" command in PC PaintBrush is useful to enlarge the template are to the full screen. Using the "Zoom In" command, will display each pixel as a box or cell on the screen. 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 is a slow process, especially if there are several labels in the drawing. The labelling process can be accelerated by creating a template of the Braille characters that can be copied and pasted into the document as needed. While neither of these labeling methods is an elegant solution, they will produce labels.
There are two basic procedures for labeling graphics; placing only a referent for each source of information in the graphic and describing the referent in a passage above the graphic or labeling information in the graphic. A combination of these methods is usually necessary. The most direct procedure is to enter labels for the graphic as part of the graphic. This is time consuming and often confusing because of the two dimensional structure of an image. The second procedure is more common. A referent, such as A or B, is entered into the graphic image for pertinent a graphical information. The referent is correlated with a description that precedes the graphic. This allows the reader to read about the contents of the graphic before they are exposed to the symbols.
After the graphic is created, it must be converted and saved in an ASCII file format. This is done by utilizing the VersaPoint VPGraph program. The VPGraph program must be pre-loaded before PC Paintbrush is started. To start the graphic capture process press alt-right shift while in PC Paintbrush. This command will shift the computer to the VPGraph control set, and display a grey box on the screen. This box is the capture box. Anything inside the box will be captured and saved as an ASCII file when the "c" key is pressed. To capture the graphic, move the capture box around the graphic by using the arrow keys. If the capture box is not the proper size, use the "w" key to widen the box, the "n" key to narrow the box, the "t" key to make the box taller and the "s" key to shorten the box. When the capture box is in the proper position it should fit within the template box, but around the graphic. (The VPGraph program will capture anything displayed within the capture box, including the template box if the capture box overlaps the template box.) Once the capture box is in position, press "c" to capture the graphic to a file.
The VPGraph program saves the graphic to a file named DOTS000n.VIM, where "n" is a unique number for each new file captured. If there is difficulty in determining which .VIM file was just created check the modification date for the newest file. The ".VIM" files will be saved within the directory that the PC PaintBrush program is running, usually C:\PBRUSH. It may be helpful to "Rename" the ASCII file. It is important to maintain the .VIM file name extension because Duxbury translator program will require this in the coming steps.
Attaching a Graphic to a Text File
The graphic can be appended to the document by referencing the graphic within the text and manually inserting it after it has been Brailled, or the graphic can be inserted into the text flow.
Appending the graphic is simple as creating the graphic and then printing it. It is not necessary to translate a graphic captured by VPGraph with Duxbury or any other Braille translation program. The file that VPGraph produces uses ASCII characters to represent the graphic by choosing the character that, when printed on a Braille printer, will best reproduce the graphic pixels shown on the screen. If this file is run through a translation program, the graphic will be formatted into Braille cells, thereby separating the graphic and making the image appear "choppy". To print the file simply type the DOS command "PRINT" path and file name.
Inserting the graphic within the Braille text flow is somewhat more complicated. The text file must be translated into Braille and the graphic image must be ignored by Duxbury. Duxbury provides a command to turn the translation off and insert a graphic file within the text at the point where the command is issued. It is important for both the text file and the graphic file in the same directory or on the same disk. The Duxbury translated text file with a suffix of ".BRF" does not physically include the graphic, but only a reference to the graphic file.
Start by saving the graphic file as described above and create the text file with the proper word processing commands and Duxbury text formatting commands. Issue the Duxbury command $PIL A:\DOTS0001, where the "A:\DOTS0001" is the name and directory of the graphic file, at the position where the graphic is to be inserted in the text file. Notice that the filename does not contain the .VIM file extension. Duxbury knows what the proper extension should be and will check for it as it converts the text document to Braille. Note: this is using an older version of Duxbury from 1992. It is important to turn off all text formatting commands before the $PIL command and then turn them back on if there is any text following the graphic.
The "L" in "$PIL is a format command for left justification. The commands "$PIC" and "$PIR" are center and right justification commands for printed graphics. The center of the template box will be the center of the Braille page, because the template represents a full Braille page.
Use the Duxbury command, "Braille A:\ text name.txt" to convert the text file and create the ".BRF" file which is ready to print on the Braille embosser.
A Braille quality control reader is the essential in judging the effectiveness of any Braille information. This is particularly essential when graphical information is converted to Braille.
III. Conversion of Math Symbols into Braille
(If you a viewing this article on a computer, please be aware that a printed copy of the article will include a Math Symbol/Nemeth Code sheet. It should also be mentioned that 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 Disability Resources for Students at Arizona State University. This, however, is not meant to imply that Duxbury is the only software capable of performing these operations. Whatever software you chose 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 standardized general markup language (SGML). The use of 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 procedure is very simple. The implementation of the procedure is complex from the perspective of hiring, training and administration. This is a computer based system, but it is still a manual system. The advantage of this system is that it is not necessary for the computer transcriber to be Braille transcriber. It is only necessary that student transcribers have a through knowledge of math, be independent workers and be paid enough to keep them as employees. Student workers should be trained, evaluated and retrained on a continuing basis. It is also necessary to have the Braille produced by this program evaluated by students or transcribers who are knowledgeable in Nemeth Code Braille. This procedure will meet the Braille math requirements of post secondary institutions, but it will only work as long as it is evaluated at every stage for accuracy.
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__ranslation 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 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 during the conversion of ASCII text to Grade II Braille. If a mathematical equation is entered in Grade II Braille, 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 a 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 codes, Appendix B, that are 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 16 hours. The student must have a knowledge of the math equations printed in the original document. The student need only enter the appropriate control codes and Nemeth Braille symbols to translate mathematical equations.
The code for the equation stated above, 1 + 2 = 3,
would be: $cz #1+2 .k #3$tx
Where:
$cz indicates the start of literal translation
# indicates the symbol following is numeric
(The # is used after a space or a negative sign.)
.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. To insure 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 discernable. 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. This procedure is considerably less expensive and usually more accurate than having a Braille transcription of higher mathematics done outside the university.
Appendix A
(The commands listed in this Appendix are for Duxbury Braille Translation software.)
The following Macros are designed to insert Duxbury formatting commands into a text file. This is not meant to imply that Duxbury is the only software package capable of converting text to Braille effectively.
****************************************
Inserts Braille page numbers
DISPLAY(Off!)
Type("$leaf- ")
******************************************
Transcribers Note
DISPLAY(Off!)
Type("$ind5 $cz ,'$tx $cz ,'$tx ")
GETSTRING(Note; "Enter the note here:")
PosWordPrevious PosWordPrevious Type (Note)
PosWordNext PosWordNext
Type("$ind1 ")
HardReturn
******************************************
Heading Centered
DISPLAY(Off!)
PosScreenLeft
Type("$hds ")
PosLineEnd
HardReturn
Type("$hde ")
******************************************
//Remove Hard Returns
SAVESTATE PERSISTALL
AutoCodePlacement(OFF!) WP51CursorMovement(ON!) VARERRCHK(OFF!)
PosDocTop
ASSIGN(Res; "n")
LABEL(Search)
SearchString("") SearchNext(Regular!)
ASSIGN(
//*** Conversion warning ***
//*** Name modified to avoid conflict with command name
Next_;
//*** Conversion warning ***
//*** Use ?RightCode for codes; ?RightChar for text
?RightChar)
ASSIGN(Set; CTON(
//*** Conversion warning ***
//*** Name modified to avoid conflict with command name
Next_) DIV 256)
ASSIGN(Num; CTON(
//*** Conversion warning ***
//*** Name modified to avoid conflict with command name
Next_) %256)
PosCharNext
ASSIGN(Next3;
//*** Conversion warning ***
//*** Use ?RightCode for codes; ?RightChar for text
?RightChar)
ASSIGN(Set3; CTON(Next3) DIV 256)
ASSIGN(Num3; CTON(Next3) %256)
PosCharPrevious
PosWordPrevious
ASSIGN(Next2;
//*** Conversion warning ***
//*** Use ?RightCode for codes; ?RightChar for text
?RightChar)
ASSIGN(Set2; CTON(Next2) DIV 256)
ASSIGN(Num2; CTON(Next2) %256)
PosWordNext
IF(Num=32)
IF(Num3=32)
PosLineEnd PosCharNext PosLineUp BlockOn(CharMode!) PosCharNext
PosWordNext
CHAR(Res2; "Delete? Y)es N)o M)inus:") ASSIGN(Res2; NTOC(Res2) )
SWITCH(Res2)
CASEOF "y": CALL(DELETE)
CASEOF "Y": CALL(DELETE)
CASEOF "M": CALL(MINUS)
CASEOF "m": CALL(MINUS)
CASEOF "q": CALL(ENDING)
CASEOF "Q": CALL(ENDING)
CASEOF "n": CALL(NO)
CASEOF "N": CALL(NO)
ENDSWITCH
ENDIF
ENDIF
IF(Num2<>35)
IF(Num>96)
IF(Set=0)
SWITCH(Res)
CASEOF "a": GO(BRANCH)
ENDSWITCH
Type("[-> ") BlockOn(CharMode!) PosCharPrevious PosCharPrevious
PosCharPrevious PosCharPrevious PosCharPrevious
CHAR(Res; "Replace [Return] with [Spc]? Y)es, N)o, A)ll Q)uit:") ASSIGN(Res;
NTOC(Res) )
BlockOff DeleteCharNext DeleteCharNext DeleteCharNext DeleteCharNext
LABEL(BRANCH)
SWITCH(Res)
CASEOF "y": CALL(YES)
CASEOF "Y": CALL(YES)
CASEOF "a": CALL(YES)
CASEOF "A": CALL(YES)
CASEOF "q": CALL(ENDING
//*** Conversion problem ***
//*** Label already referenced with different keystrokes
//
)
CASEOF "Q": CALL(ENDING
//*** Conversion problem ***
//*** Label already referenced with different keystrokes
//
)
ENDSWITCH
ENDIF
ENDIF
ENDIF
GO(Search)
LABEL(YES)
DeleteCharPrevious Type(" ")
RETURN
LABEL(ENDING
//*** Conversion problem ***
//*** Ambiguous keystrokes leading to label
)
PosScreenUp
QUIT
LABEL(DELETE)
BlockOff PosLineEnd PosCharNext PosLineUp DeleteWord DeleteCharPrevious
Type(" ")
RETURN
LABEL(MINUS)
PosCharPrevious
CALL(DELETE)
RETURN
//*** Conversion problem ***
//*** Control transfer with pending token
//{Block}{Right}{Word Right}{Left}
LABEL(NO)
BlockOff
RETURN
*************************************************
Search for extra spaces and change to 1 space
SAVESTATE PERSISTALL
AutoCodePlacement(OFF!) WP51CursorMovement(ON!) VARERRCHK(OFF!)
DISPLAY(OFF!) ReplaceConfirm(No!) SearchString(" ") ReplaceString(" ")
ReplaceForward(Regular!)
PosDocTop ReplaceConfirm(No!) SearchString(" ") ReplaceString(" ")
ReplaceForward(Regular!) PosDocTop
Braille Formatting & Duxbury Dollar Codes
Dollar Codes in Duxbury control all the formatting in the Braille translation. We generally type them in the word-processor, so that the translator converts automatically when it sees a command. The number of dollar codes we use is very limited and hence the format of the output is not very well-defined. To present our translation in an accurate and professional way the following format changes are recommended.
1. Main Headings & Chapter Titles.
All main headings and chapter titles should be centered and should have a blank line after the heading. Centering the text is done by including the text between $hds[space] and $hde[space]. This command will automatically put a line after the heading. The most recommended places for usage are in the beginning of the chapter and major section of the book etc.
example:
$hds[space]Mathematics 117[HRt]
Chapter 1$hde[Space]
The concept of headings is quite complicated. There are no set rules to use the various heading levels in Braille. It is left to the judgment of the Transcriber to decide on it. The minor headings are indented 5 spaces. This is the most used heading style inside a document. All the minor headings inside a chapter should be formatted using this style.
example:
[HRt]
[4 spaces]Section 1.1[HRt]
Most of the other headings can be formatted by leaving a blank space before it and leaving the heading left aligned without any spaces.
2. Body Text:
The main body of the document is formatted using the body text style. Body text starts in cell 3, so we need two spaces in front of each new paragraph in the section. This style is being used already in our transcribing format. The two space indentation holds true for paragraphs starting with numbers also. If it is a list, they need to left-aligned, hence no spaces before them. But to signify the difference between the list and the main body of the text, necessary blank lines should be inserted.
3. Transcriber's Notes:
The Transcriber's Note should start at cell 7, and if it runs into second line it should be from cell 5. This is done by using the $ind command. The correct usage is shown in the example. There is no Tnote, Tn or any other prefix for the notes. It should start with [comma][apostrophe] and should end with [comma][apostrophe]. After the Transcriber's note is complete you need to reset the indentation by using $ind0[space] in the beginning of the next paragraph/format/text.
example:
$ind5[space][space][space]$cz[space],$tx[space]This table is formatted for Braille. The columns are ..... $cz[space],$tx[space][HRt]
$ind0[space]Section 2.2[HRt] etc..
The inserting of $cz[space][comma][apostrophe]$tx[space] will be edited as ALT-O macro in the WordPerfect for easy inclusion.
4. Indentation:
The command we learned in the previous section $ind[space] has many more uses than just in Transcriber's notes. We can use it in formatting multiple choice questions in exams, actual indented print material etc.
example:
1. What is the city that is known as the Emerald City?
$ind2[space]a. Seattle
b. Salt Lake City
c. Phoenix
d. Las Vegas
$ind0[space]2. What is the capital of Iraq? etc....
5. Page Numbering (Print & Braille):
We use text-book style to convert all the material into Braille. The standards set for translation require the print page indicator, print page number and Braille page number. The current translation give print page indication by using ALT-P macro, and the Braille page is automatically generated by the translator. But we need to include the print page number which will come at the top right corner of each Braille page. If the document is small and the print page numbering is not significant, we can ignore print page numbering, but for the text books it is necessary to include the print-page number. Duxbury does this numbering by following the dollar codes that will tell it where each print page starts. The command is $leaf-[space]45. This will not only create the line across the page with the page number at the end of the line (ALT-P equivalent), it will put the print-page number also. Use of the command has the necessity that you follow the print page indication very accurately. If you forget to indicate the next print page all the Braille pages will be numbered with the previous print page, like a.45, b.45, c.45, etc until it sees the next $leaf- X command. The other advantage of using this command is that you don't have to worry about the print page indicator breaks, or print page indicator running into two pages. The Duxbury translator will not put the print page indicator if it happens to be the beginning of a new Braille page.
example:
$leaf-[space]45[HRt]
6. Page Breaks:
The information when translated into Braille shouldn't confuse the user. The page breaks should be used to signify the difference in sections and documents. For example, in an exam the instructions for the exam and the actual exam questions should start on separate pages. You cannot continue the exam questions right after the instructions. You don't have to worry about how many blank lines you should insert to go to a new page. As soon as you done with one section, if you want to force a new page you can type the command $pg[space]. This will stop the current page and start the following text on a new page beginning.
7. Tables:
Tables are one of the most difficult aspects of translation. The judgment of the Transcriber is very essential to convey the meaning across in the most accurate way to the Braille user. The table should be separated from the other text by lines. The lines in Braille can be generated by using a line of x's, g's, 7's or l's. The difference between these lines is just the dots that are generated by each letter. Usually the beginning of a box is denoted by a line of 7's and the end of the box is generated by a line of g's. We will edit the macros in the WordPerfect to give these lines by using ALT-G for line of g's, and ALT-T for line of 7's. Line of l's is like a thick line in the print, and can be used if needed to signify the difference in the tables.
8. Other miscellaneous notes:
There are many other common mistakes that have to be corrected by the Transcriber before using the Translation. The backslash / can be left as it is, if it is in the middle of a word, like he/she or then/now. But it cannot be left alone if it is all by itself, like - - - / -. When it is all by itself, we should convert it as $cz[space]_/ $tx[space]. This is true for any other symbols, like -, = etc. If they are in the middle of the text, we don't have to worry about it.
example:
"This is a compliment to him/her"
"This is supposed $cz _/$tx not supposed to be like this"
Other minor things that shouldn't be ignored are including a text indicator before a roman numeral etc. These things we have to incorporate by referring to the Nemeth code book more often.
Conclusion:
Though these changes seem little difficult to adjust to in the beginning, these are the basic formatting standards set by BANA (Blind Association of North America), and we will try to meet the basic requirements by adopting to these new formatting procedures.
Appendix B NEMETH DATABASE
This Nemeth database has the conversions for most commonly used mathematics symbols. All these conversions should be used inside the CZ editing mode in the WordPerfect, to be translated exactly. Please make sure you close the exact translation mode by including $tx[sp] after the Nemeth Code. Use the blank sheet to write down the symbols you come across that are not in this database, and we will update it every month.
This database is arranged in alphabetical order. For example to find code for Μ you can either check mu, or Greek Alphabet.
Note: Each column is separated by two hyphens.
Category Symbol Nemeth code Explanation/Example
Alpha .a Greek a. Upper case use .,a
Ampersand & _& Ampersand
Angle $[ Angle ABC is represented as $[,a,b,c
Angstrom Units A @,a Units of measurements shown in ink-
print capital A with a hollow dot above it.
Arrow bi-directional $[o Split bi-directional arrow. Used in
chemical equations
Arrow left 33o Arrow head ending on the left side.
Can be used in Chemical equations, limits, etc.
Arrow right [33 Arrow head pointing to the right
Arrow vertical <33o Arrow standing vertical
Arrow vertical %33o Arrow pointing downwards
Asterisk * @# Asterisk inside Nemeth editing,
outside leave it as it is.
At sign @ @a Ex: @20 @a#20
Backslash \ _*
Baseline indicator " Used after subscript or superscript
only when there is no space after the subscript/superscript. Unnecessary
baseline indicators must be avoided as much as
possible.
Beta .b Greek letter b, Capital Beta.,b
Bold face X _;,x If the ink-print character is very
distinct, then bold face indicator should be used. The ; in the conversion is the alphabet
indicator, need to be used for text symbols.
Braces {} .(.) {4} = .(#4.)
Braces enlarged {} .,(.,) When there are multiple braces,
should be used to signify the difference.
Bracket [] @(@) [4] = @(#4@)
Capitalization CHN ,c,h,n Need to include capitalization sign
before each letter
Capitalization, letter A ,a When only one letter needs
capitalization
Capitalization, word THEN ,,then When the whole words need
capitalization. **Do not use whole words in Nemeth unless you know grade 1 translation
for them.
Cent sign @c
Check mark @>
Chi .& Greek letter, lower case.
Uppercase.,&
Circle O $c
Colon : _3 For ex 3:30 is #3_3#30. Distinguish
it from ratio sign
Complex fraction 1/(2/3) ?1/(,?2,/3,#)# Start, middle and end of a complex
fraction carry a comma before them.
Contains _.1 Logical symbol. Used in sets etc.
Cross product x @* 1x10 =#1@*10 (Avoid spaces when
using @*
Cube root of 3 <3> This is just representation of cube
root, for the rest root symbols, refer Square root.
Dash - -- x-y should be x--y in Nemeth
Decimal point . . Decimal point can be entered as it is.
Differentiate between period and
decimal
Degree ^.* 90 is #90^.*
Delta .d Greek letter d, lower case. Upper
case delta is .,d
Diagonal line / _/ Diagonal line only. Don't use it to
represent division
Ditto mark " ,' Looks like double quote
Divided by ÷ ./ Arithmetic division
Dollar sign $ @s Ex: $3.50 $cz[sp]@s#3.50$tx[sp]
Ellipsis ... `"
Epsilon .e Greek letter e, lower case. Upper
case.,e
Equals sign = .k Leave spaces before and after code.
No spacing when used with a grouping symbol like parenthesis, braces ex=(2) is
[sp].k(#2)
Equivalence @<,<
Exclamation mark ! _6 Differentiate exclamation and
factorials
Exponent x2 x^2 See also superscript.
Feet ` ` Single quote.
For every @&
For some @=
Fractions 1/5 ?1/5# No number signs or sign indicators
inside the fraction. Do not use contractions for words inside fractions, need to enter
Grade 1 translations.
Functions sin, cos sin, cos Need a space after the function
name.
Gamma .g Greek letter g, lowercase. Upper case
.,g
German letter _ All german letters have this indicator
before them.
indicator
Gradient .$
Greater than sign > .1 Combination of equal and greater
than signs have base line indicator between them. Ex. >= .1".k
Greater than equal to .1:
Greater than sign nested >> .1@.1
with greater than sign
Greek letter indicator . All Greek letters are preceded by.
Horizontal bar - :
Horizontal double = _7 Chemical bonds representation
Horizontal single - _3 Chemistry symbol
Horizontal triple _=] Chemistry symbol
Inches " '' Double single quotes
Infinity ,=
Integral !
Integral with super !@$c
imposed circle
Definite integrals !;0^1 We need spaces after the limits, and
there should be a space before the derivative like dx or dv or whatever the integral is
about. x dx is !x dx.
Integral, double !!
Integral, triple !!!
Intersection sign .% Logical symbol
Iota .I Greek letter I, lower case. Uppercase
is .,I
Kappa .k Greek letter k, lowercase. Uppercase
is .,k
Lambda .l Greek letter l, lowercase,. Uppercase
is .,l
Less than or equal to "k:
Less than sign < "k
Letter sign ; Need to use single letters, so that
they are not confused with contractions. For example single letters like g as in grams, m
as in meters all should have letter indicators. Single letters left in text will be translated
by Duxbury, but inside Nemeth code, we should include letter indicator. Example: A = 1
is $cz;,a.k#1$tx
Lower limit limit %lim
Matrices 1 2 @,(#1 #2@,) Alignment is very important.
1...1 @,(#1 #1@,) Need to check the alignment after
translating.
3 5 @,(#3 #5@,)
Minus or plus -+ -+
Minutes ' '
Mu Μ .m Greek letter m, lowercase. Uppercase .,m
Multiplication sign . * For cross sign like x use @*. See
cross sign code.
Not equal to /.k
Nu .n Greek letter, lowercase. Upper case
.,n
Numbers # Use this sign, where it seems
numbers will be confused with letters. Avoid using it too much.
Omega .w Greek letter w, lower case.
Uppercase .,w
Overbar xyz "xyz:] For x bar just x: will work
Parallel $1 For example a b is $cz ;a$1b$tx
Partial derivative @d
Percent Sing % @0 Convert percent to Nemeth
everywhere
Period . _4 Period inside Nemeth braille. Don't
leave periods inside Nemeth unless they are decimal symbols.
Perpendicular to $p
Phi .f Greek letter f, lower case. Upper case
.,f. .@F also the same
Pi .p Greek letter p, lower case. Upper
case .,p
Plus or minus ± +-
Point . . Decimal point, entered as it is
Pounds #(lbs) .#
Prime ' ' Prime used to represent minutes, feet
etc.
Psi .y Greek letter, lower case. Uppercase
.,y
Punctuation _ To avoid ambiguity between
punctuation in grade 2 and Nemeth, there should be a symbol indicator before any
symbol when coming out of Nemeth. Ex. $Cz_$tx[sp]
Question mark ? _8
Ratio sign : "1 Ratio sign only, Don't use it for
colon.
Ratio sign, double :: "2
Rho .r Greek letter r, lower case. Upper case
.,r
Seconds " '' Two single quotes to represent
minutes, not double quote.
Semi colon ; _2
Sigma .s Greek letter s, lowercase. Upper case
.,s.
Since @/ Inverted, therefore symbol.
Slash / _/
Square roots >xx] Ex. Square root of 16 is >#16]
Star * $s Not a multiplication symbol
Subscripts ; Baseline indicator " is not needed
when there is a space after script. For ex. 2cr is #2;cr[sp] also subscript indicator is not
when the subscript is entirely a number. For example H2O but not ,h;2",0
Subscript with subscript ;; The second level subscript should be
represented by two semicolons.
Summation ".,s%n.k1>50 Just sigma is .s. For the
summation range need to use % sign and then
as shown in the code.
Superscripts ^ Baseline indicator " is not needed
when there is a space after the superscript. For example x2[sp] is x^2[sp] and x2 + y2 is
x^2"+y^2
Tau .t Greek letter t, lowercase. Upper case
is .,t
There exist @=
Therefore ,*
Theta .? Greek letter, lower case. Upper case
.,?
Times x @* When you need times instead of
multiplication symbol use @*. Don't use spaces.
Union sign .+
Uppercase , For chemical formula use uppercase
symbol before each letter. For example HCN is ,h,c,n but not ,,hcn.
Uppercase lock ,, To show the whole word is
uppercase.
Upsilon .u Greek letter u, lowercase. Uppercase
.,u
Vertical bar | \
Two vertical bars | | \"\ There is a space between two vertical
bars.
Vertical bar, double || \\ No space between vertical bars
Vertical double bond || \\
Vertical triple bond ||| \\\
Xi .x Greek letter x, lower case. Upper
case.,x
Zeta .z Greek letter z, lower case. Upper
case .,z
March 10, 1998
Windows 95 and Braille Graphics
The following description of a Braille graphics conversion process utilizing Windows and DOS is still in the developmental stage. The process does work, but it may not be the most effective use of Windows. The following description is a suggested place to begin with a successful conversion process and then to adjust or change the process to build a better system.
The use of DOS and Windows is an attempt to combine graphics and Braille into one document. The use of divergent software from two operating systems in one document is unavoidable because Braille fonts are only available [.TTF format] in a Windows based environment and VPGraph [capture software for Braille graphics] is only available as a DOS based application.
VersaPoint by Telesensory systems is the capture package that the Braille project at DRS/ASU uses. It is excellent at framing an area of a graphic page that will fit on a Braille page and then capturing it and converting it to a set of ASCII characters. The ASCII characters are used to represent dots that make a Braille picture The picture below displays how regular ASCII characters are placed to create a Braille Raised line drawing
L 3 L 3 L 9 L 9 L 9 L9 CCCCCCCCCCCCCCCCCC
DRS/ASU has been working towards the best combination of DOS and Windows environments. A DOS capture program must be used to create a braille graphics file. Windows provides great advantages in working with graphics and Braille fonts. The use of Windows and the automatic Braille fonts reduces the training time for new staff in Braille graphics production. When this is done the cost of a Braille graphic is reduced considerably. The reason for looking at a new process is that DOS based applications are quickly disappearing and Windows is now the dominant operating system. We have not found a comprehensive program which satisfies both our Braille graphics production and embossing needs in Windows. Hence we must still use DOS [VersaPoint Graphics] to capture the graphic image and send it to the Braille embosser.
DRS/ASU experimented with Windows 3.1, 3.11 and Windows 95 showed promise. The Braille fonts are available in Duxbury translation software as Braille.TTF.
LOADING BRAILLE FONTS:
The process of loading a Braille font into the font set for all applications in Windows 95 is relatively simple. Click on the utility icon. Click on Fonts. Click on the Add button and direct the application to look at the floppy disk drive. You have, of course, already placed the Duxbury disk with BRAILLE.TTF in the disk drive. Windows 95 should see the font on the disk and you just press ADD after you highlight it. You should now be able to look in the Font directory of any application on the Windows 95 desktop and find the Braille font among the choices.
The Braille font must be selected in MS Word, the font size selected at 04. The fonts are placed in the pull-down menu under FORMAT. In fonts, after selecting #4 size, go to character spacing in the same window. Change the selection to condensed, with 0.8 spacing. These parameters match the standard spacing commonly used in Braille.
DRS is still experimenting with WordPerfect 6.1. While WordPerfect has always been the primary software for Braille conversions, Windows conversions offer unique challenges that require lengthy experimentation.
FIGURE DIMENSIONS:
The size of a Braille page is only approximately 117 pixels wide and 130 pixels deep. That size on a SVGA screen is approximately 2.5 inches wide and 4 inches long. A very small area. The actual size of a braille page must be kept in mind as you create a Braille graphic. This size will supports the use of a the Braille font on 04. Braille can not be enlarged and expanded if it is to be part of a printed document. The readability of Braille text depends on the strict observance of spacing between the Braille cells and the Braille dots within a cell. Windows uses different spacing rules for different characters. The control of spacing is called Kerning. Kerning give the appearance of a text "flow" in a Windows based application. Kerning is very dangerous for Braille. In Windows, "What you see" is not "what you get,." when you go to DOS to print the file on a Braille embosser.
The best compromise is to use a word processor's graphics package to create a basic structure for the graph. (The X/Y axis or overall design of the graph is the definition of "basic structure.") Once the basic structure is created, enter the Braille font labels for the graph. Use the basic structure to assist in placing the Braille characters. (If the graphic is just a line drawing, it can be created with the word processor.)
It is now time to leave the Windows environment and move to DOS to finish- the process. The move to DOS presents several problems. The first step is to move the graphic image and place it in a Dos based application. You can try saving the image as a Bit Mapped Image BMP or a PCX file. What does work is to use a capture program to capture the file from the screen and save it in a PCX format. This seems to allow for the saving of a clean file without the kerning of characters.
WINCOPY:
Wincopy is a software package, freely downloadable from the web site http://www.shareware.com. We use Wincopy to capture the picture drawn in Windows as a PCX format so that it can be opened in DOS to be recaptured using VP Graph. This step is unavoidable because we need to print out through the embosser. Wincopy is an excellent Windows capture package that provides excellent cropping and multiple file resolution and file saving capabilities
PC PAINTBRUSH FOR DOS:
PC Paintbrush is the software used at DRS/ASU in our Braille production lab. It was an excellent package that does everything necessary to create a Braille graph. Unfortunately, it is no longer sold or supported by the beaming Company, the company that now owns the original vendor, SoftKey. Please do not confuse the Windows based PC Paintbrush with PC Paintbrush for DOS. Until someone finds an answer for the failure of Braille capture programs to work in Windows, a DOS based application must be used to display the Windows file so that it can be captured for a Braille embosser
NEOPAINT:
NEOPAINT is a graphic editor and display package that can be downloaded from http://www.shareware.com. NEOPAINT has most of the graphic tools of PC Paintbrush for DOS and some additional graphic tools. NEOPAINT is also a DOS based program similar to PC paintbrush for DOS. Our preliminary experimentation shows NEOPAINT to be a possible and suitable replacement for PC Paintbrush for DOS. NEOPAINT does have one major problem. It requires considerable conventional memory to operate To use NEOPAINT, a minimum autoexecbat.bat must be written in the DOS window togive NEOPAINT 520k in conventional memory. Windows 95 does have the ability to create a customized autoexecbat.bat for specific applications. VPgraph, the Telesensory graphic capture package, must also be installed in the DOS window.
With VPGraph and NEOPAINT installed in the DOS Window, image captured in a Windows based word processor can be transferred to DOS. Here are the steps:
Install any of the Braille fonts. ASU uses one from the Telesensory
Open a word processor and go to the font menu and select the installed Braille font. Type in the font size as 04.
Create a basic graphic in Word or WordPerfect and draw the graphic basic structure. Type in the Braille labels.
Open Wincopy on the desktop, switch to the word processor and capture the image. Save the file in a CGA, two color, 400/600 file.
The file should be saved in the directory where NEOPAINT and VPgraph are located.
Go to DOS. Open NEOPAINT. Load the file captured by Wincopy.
Use graphical tools to add the fine elements in the graph Move the different elements to create a well organized graph.
Save the file as bit mapped.
Quit NEOPAINT and open VPgraph.
Reopen NEOPAINT and bring up VP graph with Alt, Theft shift
Move the VPgraph window over the image. Resize the Vpgraph window to capture only what is to be placed on the Braille page.
Capture the Neopaint image inside the Vpgraph window with the "c" command.
When you capture tile image with Vpgraph, a DOT000x.VIM file will be created in the directory.
The *.VIM file can be sent to the Braille printer with a print command or, when using Duxbury, added to the text flow of a Braille document.
Be sure to check the Braille readability of the printed Braille to ensure accuracy Depending on many variables in Windows 95, the setup of the word processor, and the setup of Neopaint, "tweaking" of the various setups may be necessary.