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) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 13-Nov-06 Time: 09:10:50 ------------------------------ XFMail ------------------------------ _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
