On Wednesday 18 December 2002 00:19, you wrote:
> snip<
> Well... the Linux print subsystem typically works this way: You feed
> your job to the lpr daemon. The /etc/printcap file is what regulates
> lpr, and in that file there is an entry that dictates the "filter"
> software that lpr uses. Two of the biggies are magicfilter and apsfilter
> (my personal choice). The filter program tries to figure out what kind
> of file this is, and do some conversions on it to make it suitable for
> your printer. For example, most printers expect you to have a CR/LF
> combination at the end of each line for straight text files. But
> Linux/Unix use only a LF at the end of a line. So the filter program has
> to replace the LF with a CR/LF combination. If your file is anything
> beyond straight text, it may be converted to Postscript, the lingua
> franca of Linux printing. Ghostscript is the usual tool that then takes
> that file and sends it to your actual lpr daemon. But if your printer is
> not natively Postcript compatible, ghostscript will have to translate it
> into a form your printer understands.
>
> Kind of like having to hand crank a Model-T. It works, but it's a pain.
>
> I don't know that I'd call lpr "deprecated", but lprng and cups are
> supposed to be superior for a variety of reasons. Given the description
> above, you can see why Linux printing might be slow. I doubt lprng is
> any faster; it's not that major a rewrite, from the viewpoint of
> filtering. CUPS, I don't know.
LPR Is deprecated - no distributions install by default anymore, rather they
advocate LPRng or CUPS. I have no evidence that LPR is still being
developed. Both LPRng and CUPS are under active development.
LPRng Is a Major rewrite, just take a look at the package size. It uses its
own libraries which are different than LPR. CUPS uses its own filters.
>
<snip>
Smitty
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:31:10 EDT