Ticket #509 (closed defect: fixed)

Opened 14 years ago

Last modified 14 years ago

printing-config wrappers don't always use LPROPT

Reported by: broder Owned by: jdreed
Priority: blocker Milestone:
Component: printing Keywords:
Cc: Fixed in version:
Upstream bug:

Description

I'm reopening this bug, since geofft commandeered it from me originally.

Regardless of what our long-term plan for printing-config is or isn't, it is really unacceptable that, not only is there no way to set user-global print settings, but the documented way to do so only sometimes works, and the reasons for it sometimes working are completely opaque.

If the arguments passed to lpr can be interpreted purely as CUPS arguments (such as if you just do lpr -Pfoo), then the arguments in LPROPT aren't inserted into the processed command-line arguments. LPROPT arguments should always be added to the command-line, regardless of what printing technology the request ultimately gets back-ended to.

See also  RT:1098339,  RT:1141197, and undoubtedly others.

Change History

comment:1 Changed 14 years ago by broder

To clarify, inserting LPROPT should happen before we convert LPRng arguments to CUPS arguments.

comment:2 Changed 14 years ago by jdreed

  • Owner set to jdreed
  • Status changed from new to accepted

Fixed in r24374

jdreed@infinite-loop:~/src/printing-config$ unset LPROPT
jdreed@infinite-loop:~/src/printing-config$ lpr -P ajax
would exec /usr/bin/cups-lpr -Pajax -mzephyr%jdreed
jdreed@infinite-loop:~/src/printing-config$ export LPROPT=-Zduplex
jdreed@infinite-loop:~/src/printing-config$ lpr -P ajax
Using cups-lpr -osides=two-sided-long-edge -Pajax
would exec /usr/bin/cups-lpr -osides=two-sided-long-edge -Pajax

comment:3 Changed 14 years ago by jdreed

  • Status changed from accepted to proposed

comment:4 Changed 14 years ago by broder

  • Status changed from proposed to closed
  • Resolution set to fixed

This was moved to production a bit ago.

Note: See TracTickets for help on using tickets.