[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Foomatic-ability for LPR
On Thu, Jan 31, 2008 at 05:16:58PM +0000, Johnny C. Lam wrote:
> On Mon, Jan 28, 2008 at 07:11:42PM -0500, Greg Troxel wrote:
> > [foomatic wants "-j <string>" or "-Z <string>"]
> > I don't follow 100% what you meant about OpenBSD's lpr, but if the only
> > use of -Z as an argument to a filter is by LPRng and is used in the
> > foomatic way, then that indeed sounds like the way to go.
> I would prefer if we just passed -Jjobname to the filter. I see that
> OpenBSD made this exact change to their lpd(8) expressly for the
> purpose of using foomatic-rip.
FreeBSD added -Z for compatibility with LPRng spoolers but with slight
different semantics than LPRng lpr. It doesn't appear that FreeBSD
will pass any -Z options nor the "jobname" hack to the print filter.
Also note that GNUlpr and CUPS lpr both use -o for the purpose of
passing "other" options.
Abusing -J ala OpenBSD just seems messy/wrong.
I am not convinced that adding a new -j option is right either.
Seems like there is a proliferation of different lpr options for
doing the same thing. Plus this method still abuses lpd's J card.
> > I agree that environment variables are messy.
> > Are you proposing to add a new option to printcap to specify the value
> > of -Z, so that lpd adds -Z foo to the output filter if the printcap
> > entry has oz=foo? Does this encode the ppd file? Or do you mean
> > something else?
> > foomatic claims to autodetect the spooling system. Is possibly tricking
> > it into thinking BSD lpr is LPRng safe?
> Foomatic-rip autodetects the spooling system based on examining the
> environment variables and the options passed to it. BSD lpd and LPRng
> are treated differently enough within the foomatic-rip script that I
> don't think making our lpd look like LPRng is wise.
> If we want to do "just enough" to allow NetBSD's lpd to use foomatic-rip,
> then adjusting lpd(8) to pass -Jjobname to the filter is enough.
But, if I'm understanding things correctly, foomatic-rip will still
break print accounting. This really seems suboptimal.
You can't really do accounting when using foomatic-rip with LPD or
GNUlpr; the af= accounting filename is used for something else.
With LPRng this problem does not occur.
> If we want to really allow specifying arbitrary options to the filters
> in the way that LPRng allows, then we should just do it our own way
> and then teach foomatic-rip about this new "nblpd" variant.
This seems like a more sane approach.
Main Index |
Thread Index |