Foomatic/ljet4d has duplex printing always ON, short-edge duplex not available at all

Bug #1184665 reported by Fiorenzo De Santis
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GS-GPL
Invalid
High
foomatic-db (Ubuntu)
Incomplete
High
Unassigned
ghostscript (Ubuntu)
Incomplete
High
Unassigned

Bug Description

I have a Brother HL-2270DW laser printer and I'm using Generic PCL drivers since the official drivers by Brother suffer from issues in managing print margins.

Foomatic/ljet4d and Foomatic/ljet4 have good printing quality and they handle the print margins correctly but Foomatic/ljet4d has duplex printing always ON regardless of the option "Double sided-printing", on the contrary Foomatic/ljet4 has the duplex always OFF.

Using CUPS web interface to set duplex doesn't help.

At the moment I'm using both drivers, one for duplex printing and the other for plain printing.

Following directions in Debugging Printing Problems, I've enabled "Save debugging information for troubleshooting" but I have not captured any print jobs because in this case it would be useless.

I have just printed a text file with duplex=OFF (Foomatic/ljet4d) but the printer performed a duplex print.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: cups 1.6.2-1ubuntu7
ProcVersionSignature: Ubuntu 3.8.0-22.33-generic 3.8.11
Uname: Linux 3.8.0-22-generic x86_64
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
Date: Mon May 27 18:34:57 2013
InstallationDate: Installed on 2013-03-16 (72 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130315)
Lpstat:
 device for BRFAX: lpd://BRW002258EF8326/BINARY_P1
 device for HL2270DW: lpd://BRW00225892D671/BINARY_P1
 device for MFCJ6510DW: lpd://BRW002258EF8326/BINARY_P1
 device for PCL_HL-2X: lpd://BRW00225892D671/BINARY_P1
 device for PCL_HL-2X__Duplex: lpd://BRW00225892D671/BINARY_P1
MachineType: ASUSTeK Computer Inc. U36SD
MarkForUpload: True
Papersize: a4
PpdFiles:
 HL2270DW: Brother HL2270DW for CUPS
 PCL_HL-2X__Duplex: Generic PCL 6/PCL XL Printer Foomatic/ljet4d
 PCL_HL-2X: Generic PCL 6/PCL XL Printer Foomatic/ljet4
 MFCJ6510DW: Brother MFC-J6510DW CUPS
 BRFAX: Brother BRMFCFAX for CUPS
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-22-generic root=UUID=ec9aa77a-fa22-4668-b846-38058c29cf00 ro quiet splash vt.handoff=7
SourcePackage: cups
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/12/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: U36SD.205
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: U36SD
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrU36SD.205:bd07/12/2011:svnASUSTeKComputerInc.:pnU36SD:pvr1.0:rvnASUSTeKComputerInc.:rnU36SD:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: U36SD
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :
Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

Footmatic/ljet4d PPD

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

Footmatic/ljet4 PPD

summary: - Footmatic/ljet4d has duplex printing always ON
+ Foomatic/ljet4d has duplex printing always ON
description: updated
Revision history for this message
Till Kamppeter (till-kamppeter) wrote : Re: Foomatic/ljet4d has duplex printing always ON

The problem of ljet4 alwyas giving one-sided printing and ljet4d always giving duplex printing can be easily solved in Foomatic, but the problem should also get fixed in Ghostscript so that standard PostScript methods for using duplex get working.

Can you try the ljet4d driver and there select the long-edge and short-edge versions of duplex printing. Does this at least correctly work?

affects: cups (Ubuntu) → foomatic-db (Ubuntu)
Changed in foomatic-db (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Changed in ghostscript (Ubuntu):
status: New → Incomplete
importance: Undecided → High
Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

long-edge works, short-edge doesn't work, it appears that the driver always uses long-edge!

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

Original bug report at Ubuntu:

https://bugs.launchpad.net/bugs/1184665

The PCL-5 support in GS (ljet4/ljet4d, perhaps also ljet3/ljet3d) has a problem. One cannot switch one-sided/duplex-long-edge/duplex-short-edge via the standard -dDuplex and -dTumble options, duplex can only be switched by selecting ljet4 or ljet4d, short-edge is not available at.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Florenzo, the Ghostscript developers told me that your printer also supports PCL-XL, so try to set it up with Foomatic/pxlmono (use the Generic PCL-6/XL printer if your model does not have the Foomatic/pxlmono choice). This should enable control for duplex printing.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Reported problem upstream as http://bugs.ghostscript.com/show_bug.cgi?id=694279 and discussed it on IRC channel #ghostscript on Freenode.

summary: - Foomatic/ljet4d has duplex printing always ON
+ Foomatic/ljet4d has duplex printing always ON, short-edge duplex not
+ available at all
Revision history for this message
In , Henry-stiles (henry-stiles) wrote :

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.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Henry-stiles (henry-stiles) wrote :

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.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Can you somehow generate PCL 5e which makes the printer printing duplex short-edge, for example from the Windows driver )printing into a file)? If so, please attach this PCL output. The printer seems not to respect the standard PCL-5e command for duplex short-edge.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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

Revision history for this message
In , Henry-stiles (henry-stiles) wrote :

(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?

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Henry-stiles (henry-stiles) wrote :

(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.

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

foomatic/pxlmono is affected by a major issue, it doesn't print all the thin horizontal lines

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

this is what foomatic/pxlmono is supposed to print

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

this is the foomatic/pxlmono captured printout

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Fiorenzo, your attached "printout" file comes out correctly on my HP Color LaserJet CM3530. It seems that Brother is not implementing PCL correctly.

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

does it appear like this one? can you see all the horizontal lines?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Yes, exactly like this.

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

yes this printer might have PCL issues, however I've just installed "UNIV-PCL-0110", the PCL drivers supplied by Brother, on Windows Seven and I can confirm that short-edge duplex printing works like magic in Windows

so at the moment I can print with ljet4 (simplex) and with ljet4d for duplex long-edge, if I need short-edge duplex I have to use the Brother driver but by printing from a .ps file to avoid incorrect margins as I've reported in

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1184663

and what about that bug? I think it should be fixable, does it depend on poppler? is it related to the following old bug?

https://bugs.launchpad.net/poppler/+bug/293832

Revision history for this message
Fiorenzo De Santis (fiod3s) wrote :

finally I succeeded in short-edge duplex printing even with ubuntu, I used foomatic/hpijs-pcl5e but the good news isn't over because this driver/ppd handles printing margins correctly and it isn't scared by thin horizontal lines

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
In , Htl10 (htl10) wrote :

(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).

Revision history for this message
In , Ken Sharp (ken-sharp) wrote :

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

Changed in gs-gpl:
importance: Unknown → High
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.