[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Braille printers drivers



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


Reply to: