From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-21 i686) Description of problem: I've got a Redhat 7.2 installation on a typical Intel box with all the latest updates. In particular, I've got the following RPMs installed: LPRng-3.7.4-28 Omni-0.5.0-4 Omni-foomatic-0.5.0-4 printconf-0.3.52-1 printconf-gui-0.3.52-1 I used the printconf-gui to select the HP4550 Postscript driver. I can print with lpr -- but I can't control the printer using any lpr options. For example, according to the foomatic documentation, I should be able to do something like this: lpr -Php4550 -Zduplex -Zinlower myfile.ps But while the file prints, it does _not_ print in duplex and prints from the standard input bin. For my users, this is not acceptable; they have to be able to control the printer from the command line. I've tried various alternative options; e.g., lpr -Php4550 -ZDuplex=On myfile.ps I've also tried things like -ZDuplex, -JDuplex, -Z"Duplex On", and many other variants. The command lpr -Zdocs -Php4550 /etc/inittab just prints the file without displaying any options. The relevant lines from /etc/printcap (as set by printconf-gui) are: hp4550:\ :ml=0:\ :mx=0:\ :sd=/var/spool/lpd/hp4550:\ :af=/var/spool/lpd/hp4550/hp4550.acct:\ :sh:\ :rm=hp4550.someplace.somedomain.here:\ :rp=lp:\ :lpd_bounce=true:\ :if=/usr/share/printconf/util/mf_wrapper: I've twiddled with mf_wrapper to see what's going on. I've been able to establish that the "-Z" options are being put into the /var/spool/lpd/hp4550/cf* file. "mf_wrapper" issues a "/usr/bin/magicfilter-t" command, and the "-Z" options are part of the command. But when I look at the output of magicfilter-t, I can that the postscript commands that it creates do not change no matter which -Z option is passed to it. Any ideas? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Use printconf-gui to setup a Postscript driver for an HP printer (I've tried HP4550 and HP4100) 2. lpr -Php4550 -Zduplex myfile.ps (or some variant) 3. Actual Results: The file prints, but with none of print options that were selected. Expected Results: The print options should take effect. Additional info:
I finally (after about three more days of pain and effort) found a solution to this problem on my own. The problem is that the version of magicfilter-t in the printconf RPM is not compatible with lpdomatic in the foomatic RPM. As near as I can figure (I'm neither an expert in printconf, foomatic, nor python), the printing sequence in the updated Redhat 7.2 distribution runs as follows: 1) lpd reads /etc/printcap and sends options to /usr/share/printconf/util/mf_wrapper; 2) mf_wrapper reads some m4 macros and constructs a /usr/bin/magicfilter-t command with those options; 3) magicfilter-t, examining the filters passed to it, invokes /usr/share/printconf/util/mf_postscript_wrapper; 4) mf_postscript_wrapper invokes /usr/sbin/lpdomatic. "magicfilter-t" read options from its command line -- but does not pass those arguments to mf_postcript_wrapper (which is written as though it expect them). Instead, it sets some environment variables, $ZOPT for example. However, lpdomatic does not access those environment variables; it expects the options to come in on its command line. The following patches are a brute-force solution to the problem. They force the file /var/spool/lpd/<queue>/mf.cfg to pass the options from mf_wrapper to mf_postscript_wrapper. As for me, I'm switching to CUPS. It's flakey, unreliable, and hard to configure -- but it's all of one piece, and it knows how to interpret a standard PPD file. The following patches are meant to be applied in /usr/share/printconf. After they're applied, it's necessary to run printtool (or printconf-gui), click on the "Driver Options" tab of the relvant print queue, then click the "Apply" button. After that, the -Z options will work. > diff -ru util/mf_wrapper.original util/mf_wrapper --- util/mf_wrapper.original Mon Feb 4 11:48:34 2002 +++ util/mf_wrapper Mon Feb 4 13:52:47 2002 @@ -8,7 +8,16 @@ MF_RULE_DIR='/usr/share/printconf/mf_rules' MF_RULES=$MF_RULE_DIR/mf[[:digit:]][[:digit:]]-* TMP_FILE=`mktemp /tmp/printconf.XXXXXX` || exit 1 -cat ./mf.cfg $MF_RULES | m4 > $TMP_FILE + +# Create an m4 rule to pass the options to lpdomatic +# via magicfilter. +OPT_FILE=`mktemp /tmp/printopt.XXXXXX` || exit 1 +echo -n "define(LPRNGOPTS, " > $OPT_FILE +echo -n ""'`'"" >> $OPT_FILE +echo -n "$*" >> $OPT_FILE +echo "')dnl" >> $OPT_FILE + +cat $OPT_FILE ./mf.cfg $MF_RULES | m4 > $TMP_FILE # Find the effective language set to use. @@ -45,12 +54,15 @@ # Run magic filter -/usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING $* < /dev/stdin +/usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING < /dev/stdin RETVAL=$? if [ -f $TMP_FILE ]; then rm -f $TMP_FILE; fi +if [ -f $OPT_FILE ]; then + rm -f $OPT_FILE; +fi if [[ $RETVAL -eq 0 ]]; then TERMINATION=`grep '^[[:space:]]*#[[:space:]]*TERMINATION=' ./mf.cfg | sed 's/^[[:space:]]*#[[:space:]]*TERMINATION=//;'` > diff -ru util/printconf_backend.py.original util/printconf_backend.py --- util/printconf_backend.py.original Mon Feb 4 13:27:37 2002 +++ util/printconf_backend.py Mon Feb 4 13:27:11 2002 @@ -260,6 +260,9 @@ make_mfomatic_perl_str = r""" $postscript_wrapper = '/usr/share/printconf/util/mf_postscript_wrapper'; +# This complex string, when appended to the postscript_wrapper, +# passes the contents of the LPRNGOPTS variable to lpdomatic. +$lprng_opts = "'``LPRNGOPTS''`"; undef $/; umask 0077; @@ -376,7 +379,7 @@ $text_filter = 'text "" \r\n\14 '; } - $ps_filter = "filter $postscript_wrapper $rerender_ps --mfomatic $gs_driver-$printer_id.foo"; + $ps_filter = "filter $postscript_wrapper $lprng_opts $rerender_ps --mfomatic $gs_driver-$printer_id.foo"; # Yes, this is stupid. But we don't have reliable information anywhere on #dnl # if a given printer supports pcl and pjl, so what ya gonna do? #dnl $pcl_filter = 'cat';
Thanks for the patch! I think that this part: OPT_FILE=`mktemp /tmp/printopt.XXXXXX` || exit 1 echo -n "define(LPRNGOPTS, " > $OPT_FILE echo -n ""'`'"" >> $OPT_FILE echo -n "$*" >> $OPT_FILE echo "')dnl" >> $OPT_FILE would be better written as: OPT_FILE=`mktemp /tmp/printopt.XXXXXX` || exit 1 echo 'define(LPRNGOPTS, `'$*"')dnl" > $OPT_FILE
If the $* macro gets interpreted within single quotes, then that's fine. I was in constant pain trying to get the backtick within the string, and I finally gave up.
Okay (it does). Also, there was a modification needed in the $mf_type eq 'POSTSCRIPT' case too. I've applied this in the CVS tree. Thanks for getting this working!
Fix built as printconf-0.3.68-1.
*** Bug 56834 has been marked as a duplicate of this bug. ***
Hmm, this is causing problems. lpdomatic's call to getopts doesn't understand what's going on and complains. The lpdomatic command-line ends up like this: /usr/sbin/lpdomatic: called with arguments: '--lprng','-Aroot@localhost+330','-CA','-D2002-03-06-12:32:12.224','-Ff','-Hlocalhost.localdomain','-J/usr/share/printconf/tests/testpage-a4.ps','-N/usr/share/printconf/tests/testpage-a4.ps','-Ptest','-Qtest','-a/var/spool/lpd/test/test.acct','-b18255','-d/var/spool/lpd/test','-edfA330localhost.localdomain','-f/usr/share/printconf/tests/testpage-a4.ps','-hlocalhost.localdomain','-j330','-kcfA330localhost.localdomain','-l66','-nroot','-sstatus','-t2002-03-06-12:32:12.000','-w80','-x0','-y0','/var/spool/lpd/test/test.acct','bj200-58720.foo' but lpdomatic's getopts call is expecting this format: getopts("cw:l:i:n:j:h:z:o:Z:J:"); It's just the '-Z...' and '-J...' bits that we want, so I plan to just extract those in the mf_postscript_wrapper like this: case $ARG in "--rerender-ps" ) RERENDER_PS="1" ;; "--mfomatic" ) MFOMATIC='1';; -Z* | -J* ) args="$args $ARG" ;; -* ) ;; * ) args="$args $ARG" ;;
Fix applied in 0.3.72-1.