The standard output of a braille transcribing program is an electronic file based on a direct braille equivalent called Braille ASCII which has 64 different numerical codes for each of the 63 braille cells and the space plus additional codes for new lines, skipped lines, and new pages. The key to having sufficient information to create a DotlessBraille™ display is to generalize Braille ASCII to S-Braille ASCII or extended braille as explained below.
One way to understand the DotlessBraille approach is with the concept of semantic cells or s-cells. An s-cell is a character that has a unique meaning; the meaning doesn't depend on context as it ordinarily does for a braille cell. Each actual braille cell or dot pattern as it is used in a particular braille code typically corresponds to a set of several s-cells.
For example, the dot pattern 2-3-4 or letter "s" is sometimes used as the letter "s" in a word and sometimes as a mathematical symbol s. When used as a single-letter word contraction it means "so" and as an initial-letter word contraction, it means "some". It means the final-letter part-word contraction "less" (as in our logo) when it is preceded by the contraction indicator dots 4-6 and the final-letter part-word contraction "ness" when preceded by the contraction indicator dots 5-6. Each of these six different meanings is a separate semantic cell or s-cell.
If a transcription program generated its output in terms of numerical codes for s-cells instead of for the cells themsleves as with Braille ASCII, then we could use that "S-Braille ASCII" as the basis for a DotlessBraille™ display. It turns out that there is an easy way to get transcription programs to do this which is explained later; first, let's look at another example to clarify the concept of s-cells.
Figure One shows the Braille ASCII that is output by a literary braille transcription program as a transcription of the sentence, "He added some distance." (Tip! If you have the SimBraille© font on your computer, you can type this Braille ASCII in, change the font, and see which cells the Braille ASCII corresponds to. Note that if you have a computer-driven embosser, it has the correspondence between Braille ASCII and the dot patterns built into it.)
Print: He added some distance. Braille ASCII: ,HE A4$ "S 4T.E4 |
Not counting spaces, this transcription has 13 cells: eight of the cells are used once, one is used twice, and one three times. According to my Braille ASCII cheat sheet this is what the ten different cells mean:
, letter capitalizer
H h
E e
A a
4 . (period punctuation mark)
$ ed
" contraction indicator (dot 5)
s s
t t
. contraction indicator (dots 4-6).
As stated above, the combination of the dot 5 contraction indicator followed by the letter "s" is the initial-letter word contraction for "some".
The cell with Braille ASCII code E is used twice: the first time it means the letter "e" (in the word "He") and the second time—where it is preceded by the dots 4-6 contraction indicator—it means the final-letter part-word contraction, "ance" (in the word "distance").
The cell with code 4 has three different meanings in this transcription: the double-letter sign "dd" in "added", "dis" in "distance", and the period punctuation mark at the end of the sentence.
Now I'm going to change Figure One to show what the same transcription would look like in S-Braille ASCII. I've used lower case letters (except for the "H") and also different characters (or ASCII codes) for the two meanings of E and for the three meanings of 4. As you can see in Figure Two, I left the E that means "e" and changed the E that means "ance" to a cent sign. I also changed two of the 4's: the one that means "dd" is now a left curly brace and the one that means "dis" is a now right curly brace. The remaining 4 just means a period. I picked these new characters arbitrarily from what are called standard keyboard characters.
|
S-Braille ASCII.
Print: He added some distance.
Braille ASCII: ,HE A4$ "S 4T.E4
S-Braille ASCII: ,He a{$ "s }t.¢4
|
You might not think this is a big improvement; in fact, if you happen to know how to read Braille ASCII, you are momentarily worse off. (Getting back to Braille ASCII from S-Braille ASCII is, of course, a simple process because it doesn't require creating new information the way that generating the S-Braille ASCII in the first place did.)
Actually, S-Braille ASCII is a HUGE improvement as far as a computer-based display system like a web browser because, now that each s-cell has its own special code, there is enough information to display the transcribed sentence using a DotlessBraille™ display as described on the previous page. The display system doesn't have to know anything about braille contractions—all it has to know, for example, is that a left curly brace is a code that always, in every single case, means that the display should be of the unique character that has been defined for a "dd". For example, one choice would be pre-composed character—made up of two small "d's"—that has the same width as the ordinary characters.
Note—the treatment of markup characters is explained below.
It turns out there is a very simple way to generate S-Braille ASCII from standard transcription programs: just don't discard the semantic information in the first place!!! (Note that there is a general introduction to braille transcription on this page.)
During a computer-based forward transcription from print to braille, the computer application or program necessarily discovers the semantic information in the process of carrying out the transcription; however, it is normally discarded by the time the application has turned its output into Braille ASCII. Volunteer opportunity: saving this information would be a conceptually trivial extension to an existing transcription program.
[NOTE—I'm an experienced programmer and software-maintenance person so I do know that there is a big difference between a conceptually trivial change and the actual effort that such a change can take in practice—especially for a full-featured transcription programs like the Duxbury Braille Translator and MegaDots that may not have been designed to accomodate such a change.]
The National Federation of the Blind makes available an open-source public domain literary braille transcription program called NFBTRANS—written in the C programming language—which has its transcription rules embedded in a separate dictionary file. While not a full-featured program intended for large production purposes, NFBTRANS produces accurate literary braille and is good for personal use and small projects. Dotless Braille Tip! Download this program and run it on your PC. It is a mature program that doesn't take up much memory and is very easy to install and use. The next section describes some of the simple modifications that would have to be made to NFBTRANS in order for it to generate S-Braille ASCII rather than ordinary Braille ASCII as it does now.NFBTRANS is driven by a data dictionary called BRAILLE.TAB. Using a data dictionary is good code design because it is usually much easier to make changes to a data file than to a computer program. It also allows the same program to be used for different purposes—such as a less-contracted English braille or foreign languages—and for outsiders to gain an understanding of how it works.
The actual program applies the transcription rules and also takes care of page layout, formats, hyphenation, error checking, the insertion of markup indicators, different output options, some foreign languages, etc. The program has over 7000 computer instructions whereas the dictionary only contains about 1500 entries; this gives you some idea of the relative complexity of braille formats and other possibilities compared to the literary braille transcription rules. Of course, the program handles more situations than any one person would ordinarily use.
The dictionary contains three-part replacement rules in the form "type|match|replace" that are meant to be applied in sequence. (The sequence is determined by the order that the specifications for the several dozen different types of replacements appear at the beginning of the dictionary; the five rules we are going to consider happen to appear in numerical order by their type codes.) The first part of the rule, "type", defines the situations where a particular rule is applicable.
The rest of the rule means that the string "match" in the original print is to be replaced by the Braille ASCII code string "replace" in the transcription.
The first type of rule, type 1, is for those cases where one replacement is applicable in all situations such as a word or part-word that is always transcribed the same way under all circumstances. We are only going to look at one example each of type 2, type 3, type 4, type 7 and type 22 replacements.
A type 2 requires an exact (whole-word) match. This type is used for special cases where an entire word is in the dictionary. For example, the rule "2|DISC|DISC" means that the print word disc, as in compact disc, is always spelled the same in braille as in print, that is, the part-word contraction for dis is not used. (Note that the dictionary uses upper case because the default in Braille ASCII is to use upper case letter characters. The matching is done independently of case, however. This works since braille uses markup indicators to indicate whether a letter character is upper or lower case.)
A type 3 format rule is for replacements that are only done at the start of a word (or for a whole word). The rule "3|DIS|4" means that any occurrences of the string dis at the beginning of the word (or if it were a whole word)—and that haven't already been taken care of by the application of earlier rules—are to be replaced by the Braille ASCII code for the keyboard character 4 (You have to either memorize or look up on a Braille ASCII cheat sheet to learn that a 4 is dots 2-5-6; you can't tell from the Braille ASCII itself.)
A type 4 format rule is for replacements that are only done in the middle of a word. The rule "4|DD|4" means that any occurrences of the string "dd" in the middle of the word—and that haven't already been taken care of by earlier rules—are to be replaced by the Braille ASCII code for the keyboard character 4.
A type 7 format rule is for replacements that are only done other than at the start of a word. The rule "7|ANCE|.E" means that any occurrences of the string "ance" not at the start of the word—and that haven't already been taken care of by the application of earlier rules—are to be replaced by the Braille ASCII codes for the keyboard character string .E
Eventually we get to type 22 in the sequence; this type covers the situations where a period is a punctuation mark. The rule "22|.|4" specifies that period punctuation marks are to be replaced by the Braille ASCII code for the keyboard character 4.
Note that this is all an actual example; the replacement rules have been literally cut and pasted from the copy of BRAILLE.TAB that I downloaded. By now you shouldn't be surprised to learn that when I used a text editor to change the three rules for dis, dd, and ance to "3|DIS|}", "4|DD|{" and " 7|ANCE|.¢", respectively, and re-ran NFBTRAN, I got exactly the same S-Braille transcription that was shown previously in Figure Two.
What I have done here is to illustrate that generation of S-Braille ASCII from NFBTRANS is a possibility; I haven't proved that it is trivially easy and I haven't addressed any particulars related to Nemeth-based transcriptions of technical material. As an experienced software engineer, I am well aware that making all of the changes that would be necessary to complete this project would require careful planning, a more reliable method for changing the replacement rules than using a text editor, and, most likely, addressing other problems I haven't even thought of. On the other hand, if we had an automated way for creating a DotlessBraille™ display from S-Braille ASCII, we could use this display to find any errors in a new dictionary a lot more easily!
There is one more small detail that needs to be addressed for cases where S-Braille ASCII is to be used as the basis for proofreading. Once the S-Braille ASCII file is certified, it would be necessary to have a traceable and certified automatic procedure for collapsing the S-Braille ASCII back to Braille ASCII. This is conceptually very simple; there just needs to be a table that maps each s-cell or S-Braille ASCII code back to its original Braille ASCII code. A method for doing this is shown in the next section.
Since Braille ASCII is not a braille analog, an additional key or translation table is needed to convert an electronic file based on the Braille ASCII numerical code to actual braille cells. An embosser, for example, may have such a key built in. A similar statement is true for S-Braille ASCII; a static key is needed to interpret the numerical code to generate a DotlessBraille™ source containing the actual print characters and signs. Let's call the application that generates this source DBSM for DotlessBraille Source Maker.
We can see how this would work by considering the previous example for the letter "s" where some of its s-cells correspond to "so", "some", "less", and "ness". Each of these s-cells would be represented in S-Braille ASCII by a different numerical code rather than by the single ASCII code 83 which is the code for an uppercase ess. (Note that Braille ASCII files uses numbers internally but most computer operating systems are set up to automatically display these particular numbers as keyboard characters.)
Source for letters and two-letter signs. For example, S-Braille ASCII might assign code 83 to an ess used as an ordinary letter, code 830 to an ess used as "just a letter" (i. e. a mathematical symbol), code 831 to an ess used as the single-letter contraction for the word "so", code 832 to an ess used as the initial-letter word contraction "some", and codes 833 and 834 to the two final-letter contractions based on ess.
In order to have a source which could display these various meanings according to one of the DotlessBraille display options, DBSM would have to replace the numerical codes with some sort of markup indicators showing what the numerical codes correspond to in print. Although this last process could also be carried out by a transcription program, it would be simpler to have a single post-processor that could be used for all S-Braille ASCII files.
The markup strategy used below is similar to HTML. It uses the Braille ASCII character (codes) for the actual text so that the Braille ASCII can be simply regenerated by stripping out the markup tags including their angle bracket delimiters. Specifications for this process were previously described.
83 s
830 <letter char=s>s</letter>
831 <slc word=so>s</slc>
832 <ilwc word=some>s</ilwc>
833 <flc string=less>s</flc>
834 <flc string=ness>s</flc>
Fig. 3 Sample S-Braille ASCII codes and
corresponding DotlessBraille Source
for s-cells for the letter s.
Markup for two-letter signs would be similar. For example, The Braille ASCII for the two-letter sign, "sh", is ASCII code 37 which is the percent sign keyboard character. One of its s-cells is the two-letter word contraction for the word "shall".
37 <tls sign=sh>%</tls>
371 <tlc word=shall>%</tlc>
Fig. 4 Sample S-Braille ASCII codes and
corresponding DotlessBraille Source
for s-cells for the two-letter sign "sh".
Handling composition signs. The DBSM source generator would also need to handle Braille's own markup indicators like capitalization, italics, superscripts, and so forth. This would require DBSM to know the default scopes for these markup indicators as well as to recognize explicit termination indicators. This information could easily be incorporated into the source in a manner similar to the "SPAN" tags that used by the Cascading Style Sheets (CSS) which supply style information to HTML documents.
For example, the literary braille transcription of "BRAILLE" expressed in Braille ASCII is ",,brl" where the comma is the Braille ASCII character used for dot 6, which is the capitalization indicator. If this were to be expressed in the S-Braille ASCII code, there would be sufficient information to mark it up as shown in Figure 5.
<ind type=capslock numbrl="04-04"dots="6,6">,,</ind>
<span class="shift"><sfw word=braille>brl</sfw></span>
Fig. 5 Dotless Braille source for literary braille
transcription of "BRAILLE"
The S-Braille would identify the first dot 6 as the start of a "CapsLock" indicator symbol and the second dot 6 as the end of a "CapsLock" symbol. The letter "b" would be identified as the start of a short-form word symbol, the letter "r" as a middle letter of a short-form word, and the letter "l" as the final letter of a short-form word. DBSM would supply this additional information from its key or "cheat sheet": (1) the extent of the CapsLock indicator, (2) the NUMBRL codes and dot patterns for the indicators, (3) the actual word for which "brl" is the short form, and (4) the Braille ASCII codes corresponding to each of the S-Braille ASCII codes.
0404BRL
..BRAILLE
Fig. 6 TwoDotlessBraille™ displays of
the transcription of "BRAILLE"
The Dotless Braille source in Figure 5 contains enough information to display this capitalized short-form word in either of the ways previously discussed—as shown in Figure 6— as well as in other ways. (Note that your browser should display additional information on "MouseOver".)
In Figure 7 we show a DotlessBraille of the example from Figure 2. Note that the smaller letters have been generated here by simply using a smaller size font; this is not as attractive as the narrower font that was created in the paint program. As previously mentioned, there is a volunteer opportunity for a font designer to address this problem.
|
Extended Braille ASCII and DotlessBraille™. Inkprint: He added some distance. ,HE A4$ "S 4T.E4 ,He a{$ "s }t.¢4
.He added 02s distance.
|
Although we've gone into a lot of detail, the process for generating a DotlessBraille display is very straightforward. The steps are:
Tip! You were viewing a DotlessBraille™ MouseOver Display.
Home | Site Map | Previous Page | Logo
This page was last modified on March 07, 2002.
Contact us at: info@dotlessbraille.org