On Mon, 26 Nov 2001, John J. Boyer wrote: > I like Dave's suggestion of putting the number first in the rules. This > number actually indicates a pattern-matching method. So the algorithm would > be more than a simple pattern replacement. I know French. Where could I find > their Braille code, preferably on the Web? Don't know. I learned compressed French braille a couple years ago. Although I still can read it more or less with surrounding context, I fear I wouldn't be able to write it anymore. There are the pretty generic rules which are sensible, but you must also account for the hundreds of ad hoc rules. > I think that a direct dot pattern representation would not be as clear as > using the ASCII characters that are used to represent Braille dot patterns > in the particular language. Don't the text-translation tables already take > care of translating to whatever characters a particular display needs to > represent a particular dot pattern. Well... not necessarily. At least not in French, especially when it comes to computer braille. French braille is quite well defined for paper literature, but computer braille is a much random matter, especially for non alphabetical characters. A simple dot "." may translate to different dot pattern depending on your taste. I even got my own braille table to use with BRLTTY as I couldn't stand the other available tables which seemed not natural to me. Therefore it would be much simpler, at least for the French braille compression, to just tell BRLTTY: replace each "ation" sufix in a word by dots 3-4, "ent" sufixes by dot 1-2-6, and so on, since that's actually how it is defined for paper document and not fiddle with the current braille table for the non translated case. Still I may wish to read compressed English text without having to change my own braille table for something I couldn't understand just because the braille compressor was defined with a particular braille table in mind. Nicolas