Hello, Jason White, le Thu 29 May 2008 20:49:50 +1000, a écrit : > On Thu, May 29, 2008 at 11:17:51AM +0100, Samuel Thibault wrote: > > Kenny Hitt, le Thu 29 May 2008 05:06:21 -0500, a écrit : > > > Normally, the difference with Braille printers is the format of the file. > > > > Just like any other printer. > > Correct. > > > > > The text will need to be converted to brf first. > > > > Just like .pdf usually need to be converted to .ps first. > > It's a highly natural-language-dependent process, involving context-dependent > rules
Ok, then my example was bad, think about printers that need a rasterized bitmap instead of a .ps. Then the conversion that happens involves context-dependent rules, like the wanted dpi, B&W, grey or colors, etc. I don't see how the particularities of braille couldn't fit within what CUPS can express: printer filters can already add their own options, which are sometimes numerous. > as well as conversion of the input file format to appropriate page > layout and formatting instructions for braille. Think of it as analogous to > converting a TeX or XML file to PS or PDF, with a BRF file as equivalent to a > PS or PDF file. I would still be happy to be able to use lp foo.tex instead of having to run TeX myself. > > > This user uses turbobraille to translate the file before printing. > > > nfbtrans will also work to translate to and from brf file format. > > > > Then why not including them to cups? > > For the same reasons that Troff, TeX/LaTeX, etc., are not included. I'm not surprised about TeX/LaTeX because people usually prefer to check what it looks like before printing. I'm surprised about troff. I remember printing some troff files quite directly, and I see no reason why not including it. > However, if Cups is given a text file, or an XML file, etc., destined for a > braille device, it would be useful if the filter could run the user's chosen > braille software during processing, even though that software would be a > separate package from Cups. That's precisely what is being suggested here :) Note also that CUPS doesn't do the PDF->PS conversion itself, it just calls gs... > If Cups is presented with a BRF file (i.e., already prepared for braille > output), it should just send it unmodified to the braille device. Options for > selecting which pages to print would be useful, however. That fits the CUPS model. > Other braille devices would need special drivers, as they don't accept BRF > files directly but operate in a kind of graphic mode in which the dots have to > be specified individually, together with the spacing and other details - a > kind of rasterized format. And then it makes even more sense to put that into a CUPS filter (which would still use an external program to do the txt->brf translation). > Although the North American ASCII-braille correspondence is commonly > implemented in braille devices, different schemes are used in Europe, and > it may be necessary for the driver to be able to convert between them. Just a CUPS option. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
