> I'd like to pass detailed technical information on to the engineers but I > don't think I'm qualified to give them enough info. Please post to the > list so others can contribute. I'll summarize and send to the HP folks.
I am not totally familiar with the causes of the problem, but I do have a copy a message that was sent to the LPRng mailing list by Raymond Reskusich back in October 2002 that describes it reasonably well. I've attached it to this message in case Raymond isn't still reading this list. I didn't include his patch though - you can get that from his original message if you want it. Without knowing exactly how PJL is supposed to work or what guarantees it makes about job ordering, I can see from Raymond's description that HP could claim that the fault is with LPRng's standard algorithm for detecting the end of the job. Ie: they could claim that their print engine is quite entitled to notice that the dummy job that LPRng sends is empty and so reply that it's finished straight away without waiting for the real job to finish. Still, if you can get them to admit there is a fault that they should fix, that would be great! Duncan
--- Begin Message ---for <[EMAIL PROTECTED]>; Thu, 17 Oct 2002 12:28:44 +1300 (NZDT) Received: (from [EMAIL PROTECTED]) by lprng.com (8.11.6/8.11.6) id g9GMtbE74776; Wed, 16 Oct 2002 15:55:37 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from kesey.ews.uiuc.edu (kesey.ews.uiuc.edu [130.126.161.163]) by lprng.com (8.11.6/8.11.6) with ESMTP id g9GMtbx74771 for <[EMAIL PROTECTED]>; Wed, 16 Oct 2002 15:55:37 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from kesey.ews.uiuc.edu (localhost.localdomain [127.0.0.1]) by kesey.ews.uiuc.edu (8.12.5/8.12.5) with ESMTP id g9GMunUR017271 for <[EMAIL PROTECTED]>; Wed, 16 Oct 2002 17:56:49 -0500 Received: (from [EMAIL PROTECTED]) by kesey.ews.uiuc.edu (8.12.5/8.12.5/Submit) id g9GMumdB017269 for [EMAIL PROTECTED]; Wed, 16 Oct 2002 17:56:48 -0500 Date: Wed, 16 Oct 2002 17:56:48 -0500 From: "Raymond M. Reskusich" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: LPRng: patch to fix waitend and pagecount problems for hp4100 and hp4550n printers Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 User-Agent: Mutt/1.4i Sender: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) Content-Length: 7700 Let me say up front, I am new to the mailing list. I'm also not an expert on PJL, so some of my comments will probably be naive or just plain wrong. I have written a patch based on an earlier one by Fernando Blanco Marcilla to fix the waitend/pagecount problems frequently mentioned on this list for the hp4100 printer. I found the same problems occuring on the hp4550n printer, for which I needed a fix quickly. If it turns out to be useful, I'd be glad to see it merged into the main source, as I think many people are having this problem. In the attached patch, I added a new configuration flag "pjl_waitend_byjobname" that will allow the fix to be activated on a per-model or per-printer basis. It is a unified diff to ifhp-3.5.10. To apply it, run the following from the top level of the distribution: 'patch -p1 < ifhp.patch' Give it a try and let me know what you think. I've included some details so that the printing experts on this list can tell me if I'm making sense, but anything from here on is unneccessary if you just want to use the patch. The way the waitend=3Dpjl ssystem seems to work on many printers seems to follow a timeline something like this:=20 1. ifhp submits the user's job: @PJL JOB NAME =3D "reskusic (STDIN):thehut" ... 2. ifhp submits an empty job with a name like "16-24-44.737 PID 24583" @PJL JOB NAME =3D "16-24-44.737 PID 24583" 3. ifhp waits for the "16-24-44.737 PID 24583" to complete 4. the printer sends back infomation about the end of the jobs END^M NAME=3D"reskusic (STDIN):thehut"^M PAGES=3D1^M =2E.. END^M NAME=3D"16-24-44.737 PID 24583"^M PAGES=3D0^M 5. ifhp checks the final pagecounter and does accounting. This works because the printer finishes "reskusic (STDIN):thehut" before starting on the empty job "16-24-44.737 PID 24583". What happens in the old code when used on the hp4550n(or probably 4100) is more like this: 1. ifhp submits the user's job: @PJL JOB NAME =3D "reskusic (STDIN):thehut" ... 2. ifhp submits an empty job with a name like "16-24-44.737 PID 24583" @PJL JOB NAME =3D "16-24-44.737 PID 24583" 3. ifhp waits for the "16-24-44.737 PID 24583" to complete 4. the printer, seeing "16-24-44.737 PID 24583" is empty, reports that it is done without waiting END^M NAME=3D"16-24-44.737 PID 24583"^M PAGES=3D0^M 5. ifhp checks the pagecounter, gets erroneous data, and does bad accounting 6. "reskusic (STDIN):thehut" finishes, and the printer reports back END^M NAME=3D"reskusic (STDIN):thehut"^M PAGES=3D1^M Which is the reason for the bad page counts and the early exits. The way the patch works is more like this: 1. ifhp submits the user's job: @PJL JOB NAME =3D "reskusic (STDIN):thehut" ... 2. ifhp waits for the "reskusic (STDIN):thehut" to complete 3. "reskusic (STDIN):thehut" finishes, and the printer reports back END^M NAME=3D"reskusic (STDIN):thehut"^M PAGES=3D1^M 4. ifhp checks the final pagecounter and does accounting. I feel a little uneasy about removing the empty job, but in the context of this printer I can't see any reason for it. Any opinions? Raymond M. Reskusich [Raymond's patch omitted - it should be available from LPRng archives]
--- End Message ---
