On Thu, May 29, 2008 at 12:08:03PM +0100, Samuel Thibault wrote: > That's precisely what is being suggested here :) > Note also that CUPS doesn't do the PDF->PS conversion itself, it just > calls gs... Or pdftops from xpdf-utils.
The proposal is moving in the right direction. The user would need to be able to specify, in configuration options, what braille software to use, and which file formats it can accept as input. The user may want to check the output with a braille display first, but that case is already covered by the proposed handling of BRF files. There is also the scenario in which the user has written a BRF file on a braille device and wants it reverse translated, formatted and printed. In this situation, the output device is a printer, and the input is a BRF file. Do we need a proposal for that as well? Finally, there's the problem that BRF files would be hard to distinguish automatically from other types of ASCII input in a way that is reliable. Perhaps the following test can be taken as sufficient: Find the first non-whitespace text at the start of the file, then read the file until the next form feed is encountered. If the page length and the longest line length are within the dimensions of the output braille device, then it's a BRF file. BRF files also use entirely uppercase or entirely lowercase letters, which could serve as an additional check. Admittedly this is heuristic, but is it good enough? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
