Have you applied the updates relevant to your system?

Not sure what you mean by updates here.  I use red-carpet daily to update
everything on the RedHat 7.2 and Gnome channels so all files should be
up-to-date to RedHat and Ximian releases.

If there is a package or such like that I should have, i.e. my configuration is
not totally correct, then there would be a problem but as everything works (in
some sense) I am assuming the closure over all packages is correct.

I mean official Red Hat updates.  Well, let's start from here: what version of
the following packages do you have?:

printconf
printconf-gui
Omni
Omni-foomatic
foomatic
ghostscript

Package version numbers as requested:

[root@elon root]# rpm -qa | egrep "(printconf|Omni|foomatic|ghostscript)"
Omni-0.5.0-4
ghostscript-fonts-5.50-3
printconf-gui-0.3.52-1
printconf-0.3.52-1
ghostscript-6.51-16
Omni-foomatic-0.5.0-4
foomatic-1.1-0.20011018.7
[root@elon root]# 

Is it right to do this dialogue via bugzilla or should we be emailing direct?

Email gets lots; Bugzilla persists.

Okay, you haven't got the latest printconf, printconf-gui or foomatic packages.
 Please update them via up2date or FTP, at your preference.  The advisory is
RHBA-2001:174.

Let me know if that changes the situation.

Joined RHN, registered my machine (giving RH all the details of my installation
it seems!) and ran up2date.  Did not upgrade kernel (but probably should do) did
upgrade printconf* and foomatic:

[root@elon root]# rpm -qa | egrep "(printconf|Omni|foomatic|ghostscript)"
Omni-0.5.0-4
ghostscript-fonts-5.50-3
foomatic-1.1-0.20011218.3
printconf-gui-0.3.61-3
ghostscript-6.51-16
Omni-foomatic-0.5.0-4
printconf-0.3.61-3
[root@elon root]# 

Am wondering why red-carpet did not say these were not already up to date, am
totally confused whether to use up2date,red-carpet or both.

Behaviour of printconf-gui is still the same:  a4 test page flashes comms lights
but does not print, JPEG flashes comms lights and gives 40 EIO 2 Transmission
error on HP LJ 4000 N.

So unfortunately, it does not appear to be a problem with versions of
printconf-* and foomatic.

Well, it might still be a bug in one of those packages.

What configurations has this printer worked in before?

The printer works fine from Solaris and from Windows98.  NB This is an HP
LaserJet 4000N so has JetDirect -- the printer is connected to my Ethernet and
has it's own IP address.  Each hosts interacts directly with the printer.

Until last week, Linux (LPRng) quite happily printed LaTeX generated PostScript
with lpr and printed mail messages out of Evolution so I thought that the
printer worked fine -- except using Mozilla/Galeon.  This whole problem only
arose because Mozilla/Galeon (I use Galeon but this just uses Mozilla
components) will not print Web pages where Netscape will.  I first thought it
was a Mozilla Postscript driver problem but this is clearly not the case as by
printing to file in Galeon and then printing from Solaris, using its lpr, pages
printed fine -- using lpr to print the same file on Linux fails so the problem
is associated with the LPRng print spooler.  So it seemed that there is
something in the Mozilla generated Postscript that causes problems in the LPRng
print spooler which Netscape generated code of the same Web pages do not have.

I then investigated reconfiguring the LPRng spooler with printconf-gui and
discovered that its test pages appeared to have the same problem as Galeon. I
now realize that I changed the printer driver from the Generic Postscript one to
the HP LJ 4000 one to see if that changed anything.  Clearly it did, it stopped
all printing from Linux.  I had been fooled into thinking printconf-gui was
having problems when in fact it was an artefact of changing the printer driver.
 Sorry for this faulty error report. (But there is still a problem...)

I have just tried a few more extensive tests. It appears that using the HP LJ
4000 Postscript printer driver configured for JetDirect means that Postscript
files cause the 40 EIO 2 Transmission failure and text files just download and
do nothing on what is clearly an HP LJ 4000 Postscript printer :-(.  

I have just changed back (using printconf-gui) from the HP LJ 4000 Postscript
printer driver to the generic Postscript printer driver and LaTeX Postscript now
prints again.  Indeed printconf-gui test now print as well.

I just checked a Web page using Galeon and it still fails with 40 EIO 2
Transmission error even though other tools and lpr can print to the printer fine.

So there are two errors.  Why does the Generic Postscript printer driver work
and the HP LJ 4000 Postscript printer driver fail when the printer is an HP LJ
4000?  Also Mozilla/Galeon still fails to print Web pages through LPRng (pages
that can be shown to print fine through other spoolers.  I guess these are LPRng
problems and not printconf-gui problems -- except that possible printconf-gui is
not setting up the files correctly for LPRng prior to restarting the lpd server?

Not sure how to proceed with this.

(PS  Just to proove printconf-gui can successfully print JPEGs, I can report
that the image claims it is a "TesImage" not a "Test Image" :-)

I think they are both foomatic problems.  The difference between 'Postscript
Printer' and 'HP Laserjet 4000/Postscript' is that the latter is run through
'lpdomatic' with a parameter like 'Postscript-100576.foo' (which will be the
name of a file in the spool directory), whereas the former is sent through
lpdomatic with no such parameter given.

This file specifies the ways in which the Postscript should be mangled: for
example, to change paper tray, to select page size, set resolution etc.

Try changing the options of the HP Laserjet 4000/Postscript driver and see if
there is one particular option that is causing trouble.

(I'll concentrate on this problem first, and ignore the 'Transmission error' one
for now; perhaps they are the same thing.)

I am having a similar problem on Red Hat Linux 7.3.
I used printconf-gui to configure two queues for a LaserJet 8100 with a Jet
Direct card - the first queue configured for Jet Direct, and the second queue
configured for remote lpd.  When I try to print a postscript file saved from
Mozilla through the Jet Direct queue, part of the file prints, then I receive a
'40 EIO 1 Bad Transmission' error on the printer display.  When I print the file
using the second  queue, it prints successfully.

I hava a similar problem. 
My printer is an inkjet Lexmark 1100.
It is detected by the printconf. In the /dev/lp0
And everything seems to be ok. But when i try to print a test page, there is no
printing. 
The job appear in the queue, and apparently works fine, but the printer doesn't
do anything.

The driver is there. Works with foomatic.

What could be the problem?

Thanks in advance.

rubenisai: This bug report is about the JetDirect transport 
mechanism I think.  Since you mention /dev/lp0 I'm assuming that yours is a 
locally-connected printer, and so I think it's a different issue.  Could you 
please open a separate bug report for that, and add a bit more detail?  
Thanks.

When I moved from RedHat 7.2 to RedHat 7.3 on my machines recently, I moved from
LPRng to CUPS as my printer spooling system.  I have not yet had the "40 EIO 2
Bad transmission" at all from Mozilla now that I am using CUPS.  It seems
therefore that the evidence indicates that it is a Mozilla / LPRng interaction
problem.  I have now removed LPRng from my systems.  Sorry if this sounds a
little defeatist but I needed a solution to the problem of printing pages in
Galeon and now have it (I hope !)

I've been informed of the possible root cause of the JetDirect problem, and 
your experience appears to back that up. 
 
It appears that Mozilla uses "Helvetica_Oblique" instead of the correct name, 
"Helvetica-Oblique" (dash not underscore).  This leads to the printer sending 
back an error message during transfer of the job.  However, the jetdirectprint 
script is not prepared for this, and so the transfer fails. 
 
Knowing that CUPS handles this correctly is a useful datapoint.

Hey, quick response, thats cool!

I did a quick 'find -type f | strings | grep elv' on all the files in the
/usr/lib/mozilla-1.0.1 but didn't find anything untoward.  I guess the string
may be constructed in some way.

I am surprised that the Mozilla QA people would let something like this through,
the valid PostScript names are very well defined.  It suprises me more, of
course, that the CUPS people would deal with such an unique error.  Perhaps the
problem is in the component that turns HTML into PostScript, is this done in
Mozilla or in a Gnome component?

The incorrect font name would be harmless if the jetdirectprint script only 
handled data in the reverse direction.  It doesn't, and so the job goes awry. 
 
(CUPS has its own handler for jetdirect transport, and that handles this 
correctly it seems.)

I ran into a print job that failed every single time and I was able to dig
deep to find the cause.  I think I've nailed it.

- The HP Jetdirect printer sometimes sends back status or error information
  to the host via the TCP connection.  For example when mozilla specifies the
  wrong font name the printer sends back "Helvetica_Oblique not found, using
  Courier."  But jetdirectprint doesn't read anything from the TCP connection,
  it just writes all the print data then closes the connection.
- In the kernel (tcp_close() in tcp.c), when a TCP connection is closed and
  there's unread receive data, Linux sends a TCP RST to indicate that the
  receive data was lost, instead of sending the TCP FIN it would normally send
  to indicate that Linux wants to gracefully shut down the connection.  That's
  the right thing to do according to the various RFCs.
- If all the print data happened to get safely to the printer before the RST
  then the job prints okay; if not then there's an error.  So the problem can
  be intermittent or job dependent.

The fix is in jetdirectprint to use shutdown() to gracefully close the sending
side of the connection while keeping the receiving side open for status data,
then read any status data the printer sends until the printer closes the
receive side, then do the close().

Here's a patch for jetdirectprint in printconf-0.3.77-1.  The status data is
just printed to jetdirectprint's STDOUT; hopefully that will go into a log
somewhere.  With this patch, a job that failed for me every time now prints
successfully every time.

--- jetdirectprint.orig	Mon Apr 15 16:15:15 2002
+++ jetdirectprint	Wed Nov 27 02:08:40 2002
@@ -60,8 +60,12 @@
   print $socket $_;
 }
 
-close($socket);
+shutdown($socket, SHUT_WR);
+while (<$socket>) {
+  print $_;
+}
 
+close($socket);

Created attachment 86666 [details]
Patch for jetdirectprint to use shutdown() before close()

STDOUT of the filter script is sent to /dev/null, but STDERR is sent (indirectly)
to /var/spool/lpd/$printer/status.pr, so printing to STDERR would be better.

The attached patch (wrote this before I discovered this bug) does this and uses
select to read messages from the printer as soon as they are sent instead of at
the end of the session (probably doesn't make a difference).

BTW, can we increase the severity to high? I've got reports from users that
Mozilla is not the only program which causes problems.

Created attachment 89214 [details]
Patch to Copy messages from printer to stderr

We no longer use jetdirectprint, and the CUPS socket backend handles this
correctly I think.