From my perspective, as a long-time programmer,
seems chaotic, complicated, and inefficient, and poorly standardized.
This is understandable, given braille's history: like Topsy, it just grow'd.
Unified English Braille
is a laudable effort to produce a standardized version of braille,
but the result is staggeringly complex:
The Rules of Unified English Braille
is a 344-page document!
Fortunately, at this point in the project we're only using braille to encode metadata:
names of buildings and streets, index codes, titles, etc.
So, we can fall back on a simplified form of English Braille
6-bit patterns (i.e., cells) , little punctuation, no contractions, etc. Whew!
In 6-dot braille, each pattern consists of two vertical columns of three dot positions.
The positions are numbered down the left and right-hand columns: [1,2,3] and [4,5,6].
Patterns are specified by the (ordered) sequence of dots they contain.
For example, "a" is written as 1, "l" as 1-2-3, and "q" as 1-2-3-4-5.
In 8-dot braille, two more dot positions are added at the bottom of the pattern.
For backward compatibility, the added dots are numbered 7 and 8.
In Unicode, the Braille Patterns
block ranges from U+2800 through U+28FF.
The dot positions are mapped to bit positions in a single byte,
which is then interpreted as a hexadecimal value and offset by 0x2800.
So, "a" is U+2801 (1), "l" is U+2807 (1-2-3), and "q" is U+2873 (1-2-3-4-5).
See Braille Patterns: Identifying, naming and ordering
1 0x01 4 0x08
2 0x02 5 0x10
3 0x04 6 0x20
7 0x40 8 0x80
Size and Spacing of Braille Characters
quotes a de facto
(Specification 800, "Braille Books and Pamphlets") from the National Library
Service for the Blind and Physically Handicapped of the Library of Congress.
Boiled down quite a bit, this says:
- Dots should be 0.019" tall and have a base diameter of 0.057".
- Adjacent dots in a row or column should be 0.092" apart.
- Corresponding dots in adjacent patterns should be 0.245" apart.
- Corresponding dots in successive lines should be 0.4" apart.
As a side experiment (suggested by Braille, my collaborator and target user),
we can try varying the dot size and/or shape as a way
to add styling semantics (eg, code, emphasized, strong) to the text.
The traditional braille dot shape is a spherical cap
(i.e., a portion of a sphere cut off by a plane).
We need to experiment with various approximations of this shape,
to determine which one works best for 3D printing and use.
This may also be of value in the image region of the Utile.
However, it is going to be a challenge for laser engraving,
because the laser beam can only cut downwards.
It may be possible to "soften" the edges of features a bit,
using something akin to an agricultural terrace
(... a piece of sloped plane that has been cut into a series
of successively receding flat surfaces or platforms, which resemble steps ...).
Here is "Braille is not ASCII!", encoded as three sequences of 6-dot Braille glyphs.
In practice, the dots would be raised above the surface of the tile:
Cf b r a i l l e # "<Cf>braille"
. . + . + + + . . + + . + . + .
. . + . + + . . + . + . + . . +
. + . . + . . . . . + . + . . .
i s n o t # " is not "
. . . + . + . . + + + . . + . .
. . + . + . . . . + . + + + . .
. . . . + . . . + . + . + . . .
Cf Cf a s c i i ! # "<Cf><Cf>ascii!"
. . . . + . . + + + . + . + . .
. . . . . . + . . . + . + . + +
. + . + . . + . . . . . . + .
The leading "Cf" (Capital follows) glyph capitalizes the "B" in "Braille".
A pair of "Cf" glyphs capitalizes all of "ASCII".
This wiki page is maintained by Rich Morin
an independent consultant specializing in software design, development, and documentation.
Please feel free to email
comments, inquiries, suggestions, etc!