RE: [Groff] Formatting braille

[Ted Harding]

On 12-Nov-06 Susan Jolly wrote:
> Hi,
> 
> I am interested in using groff for formatting braille
> documents and would appreciate feedback. Here are a few
> of the big picture issues.
> 
> The 63 braille cells are represented by a transliteration
> to ASCII characters. However, some of the assignments are
> arbitrary so that, for example, the ASCII post-punctuation
> marks stand for braille cells that can be used before or
> in the middle of a word.

This could be a very interesting poject for groff! However,
there are some things which are not clear to me (see other
comments below).

One is the question whether you want to incorporate the
rules for passing from ASCII text to Braille cells into
the groff setup for composing Braille. For example, the
composer of the document enters the text

  The cat sat on the mat

and the output is the correponding sequence of Braille cells,
without further intervention by the composer.

I'm not familiar with Braille, but I have looked at your
"dotlessbraille" web-page, without getting a clear picture
of the rules from it.

Discussion of the details of taking an ASCII text and
generating (using groff) the desired sequence of Braille
cells would require an exact and exhaustive statement of
the rules to be available. Once this was available, though,
I would expect that groff would be able to cope with it
perfectly.

Alternatively, were you perhaps contemplating a situation
where the conmposer of the document typed in an encoding
for the Braille sequence in the first instance (i.e. has
already created the Braille in his/her head)? This would
be very straightforward to implement, though consideration
would need to be given to "ease of use" from the composer's
point of view..

> Formatting braille is very similar to formatting print
> using a fixed-width font. All of the braille cells
> (including the space) are the same size and a page is
> characterized by the maximum number of braille cells that
> will fit on a line (typically 32-40) and the maximum number
> of lines on a page (typically 25).

Producing a printed (marks on paper) or displayed (e.g. on
screen) formatted Braile output would not in principle present
any problem to groff. Since there are only 63 patterns of dots,
the set of patterns can be defined within a short file that
would be read in before groff started its work on a document.

Such definitions would imply height and width dimensions which
would be taken account of when groff formatted the output
line-by-line, with the result that whatever the line length
or page length the result would fit.

However, it's not clear from your statement whether Braille
writers assign "line length" in terms of "cells per line"
in the first instance, regardless of physical dimension, or
in terms of physical line length (e.g. inches) and desired
size of Braille cell (leading to an implied maximum number
of cells per line). And similarly for lines per page.

The latter case is basically how groff normally works: taking
account of the widths of the characters to be printed, and
the current physical line length, it appends character after
character to the line until there is not enough physical
line space left to include the next non-splittable sequence
of characters (which then gets carried forward to the next line).
And similarly for pages.

However, it would not be difficult to arrange things so that
it was done the first way, in terms of maximum number of cells
per line: since the cells are fixed-width, it really comes
down to assigning line-length in units of cell-width.

> It would be very nice to have a device-independent format
> so the same braille file could be embossed with different
> page sizes and with the page numbers adjusted accordingly.

I'm not sure here what you mean by "device-independent".
And you've now used "embossed", which implies that what you
want is the "finger-tip readable" pattern of embossed dots
rather than printed/displayed (see above).

When you say "so the same braille file could be embossed
with different page sizes and with the page numbers adjusted
accordingly", this is not "device-independent" in the usual
groff sense, since the same groff input file can be used to
produce formatted output for different line-lengths and
page sizes by defining appropriate constants for groff before
groff reads its input file. So you could change the cell
dimensions, the line length, and the page length as you wished
and the same input file (which defines the text to be printed)
would work in all cases. This aspect has nothing to do with
whatever p[hysical device produces the output.

This would equally apply to embossed output (raised dots on
papaer) as to printed output (printed marks on paper).

However, the physical devices which emboss Braille are no
doubt somewhat different from the physical devices (printers
and screens) which print/display normal print-formatted output.

Again, I'm not familiar with these. As far as driving these
with groff is concerned, I would imagine that such a device
expects to receive a sequence of codes: some (63) which fix
what Braille cell is to be produced next; some which play
the role of "control codes" for such things as "move to the
start of the next line" or "eject page and start a new one",
or "end of job", or ...

Presumably, a "standard Braille printer" embosses lines
of Braille cells on a sheet of paper until it reaches the
bottom of the page, and then moves to the next sheet of
paper.

For all I know, there are Braille embossing devices which
can produce embossed Braille on a continuous narrow tape
(like a ticker-tape), in which case (from groff's point
of view) you're dealing with an unlimited line length and
a single "line per page".

Also, I have seen a Braille-capable computer keyboard, in
which as well as the normal set of keys (which can of course
be used by a blind person once they have learned to "touch
type" on it) there is also a linear panel at the bottom
edge out of which little rods can be raised under computer
control. thereby providing tactile feedback to the user in
Braille.

This (again from groff's point of view) would be seen as a
"page" with a single line of fixed total length.

None of these would be a problem to groff from the formatting
point of view, but there is apways the issue of what codes
such a device expects to receive in order to do its job.

What groff means by "device-independent" is somewhat
different. The formatting (in terms of characters per line
and lines per page) requires only information about the
dimensions of the characters and the dimensions of the page,
and groff's primary output (from the program 'troff' which
organises the formatting) is indeed in a device-independent
format, in that different physical devices (e.g. printers
from different manufacturers which have different "printer
control languages") will expect to receive different
codes in order to achieve exactly the same final result.
Therefore groff includes a repertoire of "post-processors"
to convert groff's primary output into the appropriate
printer control language, to drive the physical device
actually connected to the computer by converting groff's
device-independent output into the specific codes that
the particular printer expects..

So another groups of questions we would like to have more
information about is what kinds of device you want to use,
and what encodings they expect for the purpose of achieving
the result that the user wants.

However, I feel confident that the process of producing Braille
looks straightforward enough that it could be achieved readily
using groff, provided one has all the deatils needed to define
the methods.

Hoping this helps, as a first response!
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 13-Nov-06                                       Time: 09:10:50
------------------------------ XFMail ------------------------------