🚀 go-pugleaf

                            THE BLIND NEWS DIGEST

                                 Issue # 1033

                          Thursday, April 28, 1994

Today's Topics:


                                ******


                     Braille output of math anc science


                                ******


To subscribe to the Blind News Digest mailing list or have your
thoughts in the next issue, please send electronic mail to
Bill McGarry at any of the following addresses:


UUCP:       uunet!bunker!wtm
INTERNET:   wtm@bunker.afd.olivetti.com
BITNET:     blindnws@ndsuvm1.bitnet
Fidonet:    The Handicap News BBS (141/420)   1-203-926-6168
            (300 - 14,400 baud, 24 hours)
NVN:        ABILITY
Compuserve: 73170,1064

                              Bill McGarry (Moderator)
                              (203) 926-6187



------



Subject: Braille output of math anc science
From: NRCGSH@RITVAX.ISC.RIT.EDU (Prof Norm Coombs)

Below is a document written for EASI by Richard Jones.  It is a partial answer
to the rpoblem of providing braille access to science and math in colleges.

Norman Coombs nrcgsh@rit.edu




 Converting Text to Braille

 By:  Richard Jones and Scott Flechsig


      This 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)


 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.

 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




------






                                ******

                 End of Issue # 1033 of the Blind News Digest

                                ******