Bug 694279

The PCL produced is correct, with -dTumble the driver produces the command (ESC & l) 2 S and 1 S when it is off, the expected result.

Doe the user have PCL output from the native driver which selects Tumble and works?  If so attach it to the bug.

The CUPS error_log attached to the Ubuntu bug report contains the following Ghostscript command lines (search for "renderer command"):

Job 111: gs -dFirstPage=1  -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -dNOINTERPOLATE -sDEVICE=ljet4d -dDuplex -dMediaPosition=0 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r600x600 -sOutputFile=- -f   /var/spool/cups/tmp/foomatic-E6dq3t

Job 112: gs -dFirstPage=1  -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -dNOINTERPOLATE -sDEVICE=ljet4d -dDuplex -dTumble -dMediaPosition=0 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r600x600 -sOutputFile=- -f   /var/spool/cups/tmp/foomatic-a4gEnk

Job 113: gs -dFirstPage=1  -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -dNOINTERPOLATE -sDEVICE=ljet4d -dDuplex -dTumble -dMediaPosition=0 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r600x600 -sOutputFile=- -f   /var/spool/cups/tmp/foomatic-Eb3AuL

Job 114: gs -dFirstPage=1  -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -dNOINTERPOLATE -sDEVICE=ljet4d -dDuplex -dTumble -dMediaPosition=0 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r600x600 -sOutputFile=- -f   /var/spool/cups/tmp/foomatic-KFdOXu

Job 115: gs -dFirstPage=1  -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -dNOINTERPOLATE -sDEVICE=ljet4 -dMediaPosition=0 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r600x600 -sOutputFile=- -f   /var/spool/cups/tmp/foomatic-r2we33

Job 116: gs -dFirstPage=1  -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -dNOINTERPOLATE -sDEVICE=ljet4d -dDuplex -dMediaPosition=0 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r600x600 -sOutputFile=- -f   /var/spool/cups/tmp/foomatic-n45KYl

Job 111: ljet4d Duplex
Job 112: ljet4d Duplex Tumble
Job 113: ljet4d Duplex Tumble
Job 114: ljet4d Duplex Tumble
Job 115: ljet4
Job 116: ljet4d Duplex

The user tells that all ljet4d jobs come out duplex long-edge, all ljet4 jobs one-sided.

The command line shows that the -dTumble option gets actually supplied.

The GS output contains the proper pcl commands to select Tumble as confirmed in comment #1; there must be a problem with the printer interpreting the PCL tumble command.  I don't see what else we can do with this problem without sample printer codes that select tumble successfully.  Maybe there is a proprietary or device dependent escape sequence on the printer.

Another problem the user reports is that if he uses ljet4d and unselects duplex by options that the printer still prints duplex.

(In reply to comment #4)
> Another problem the user reports is that if he uses ljet4d and unselects
> duplex by options that the printer still prints duplex.

Right ljet4d always duplexes, if she changes the option to not duplex then the ljet4 device must be selected somehow.  Is there are a problem with doing that?

Generally, I can make Foomatic selecting ljet4 when the user unselects duplex and ljet4d when he selects duplex, but problem is if GS gets fed with PostScript files containing Duplex and Tumble settings. Then the standard control via the Duplex and Tumble parameters in needed to get correct results.

(In reply to comment #6)
> Generally, I can make Foomatic selecting ljet4 when the user unselects
> duplex and ljet4d when he selects duplex, but problem is if GS gets fed with
> PostScript files containing Duplex and Tumble settings. Then the standard
> control via the Duplex and Tumble parameters in needed to get correct
> results.


Okay so we'll look into changing ljet4d to only duplex if the options are sent.  

I'm hesitant to have one device ljet4 that supports duplexing - I have to think there is a reason ljet4d exists, and a possible explanation is sending PCL duplex commands to some non duplexing printer results in an error.  I wish we had better history about why ljet4d was created in the first place.

The poster of the Ubuntu bug tells that the HPLIP PCL 5e driver (in his special case HPIJS via Foomatic/hpoijs-pcl5e) solves all his problems with Brother printers): short-edge duplex, duplex control via PostScript (-dDuplex, -dTumble) and a margin problem which he reported in another Ubuntu bug.

So we should perhaps look into the output of the HPLIP driver to make ljet4/ljet4d more universally working.

(In reply to comment #8)
> The poster of the Ubuntu bug tells that the HPLIP PCL 5e driver (in his
> special case HPIJS via Foomatic/hpoijs-pcl5e) solves all his problems with
> Brother printers): short-edge duplex, duplex control via PostScript
> (-dDuplex, -dTumble) and a margin problem which he reported in another
> Ubuntu bug.
> 
> So we should perhaps look into the output of the HPLIP driver to make
> ljet4/ljet4d more universally working.

I think I re-opened a bug report a while ago where some options in PCL were being reset wrongly between postscript and the driver - basically it should only go in one direction, but it was allowing the driver's default to override the incoming options, or some such.

Anyway, as Henry said the easiest way to go forward, if you have *one* driver which does the correct thing, is to capture the output and analyse what it does.

Assuming you have a.pcl from one driver, and b.pcl from another driver, you can build the pcl interpreter ("pcl6" but does both pcl 5 & 6) from  ghostpdl in debug mode (run "./autogen.sh && ./configure && make pcl-debug" then look for "main/debugobj/pcl6" as the final outcome binary). Run this:

  pcl6 -ZI a.pcl

would gives you a textual dump of what it contains, between the actual content.
It should be human-readable enough for you to see some difference.

(The -Z* options only work in debug builds - hence even if ubuntu ships ghostpdl's pcl6, that binary would be of no use to this task).

We don't seem to have received any additional information here so I'm closing the bug.