How to abort Postscript infinite loop jobs in LaserJet printers

  • Thread starter Thread starter Antti Louko
  • Start date Start date
A

Antti Louko

Hello,

Although this is mainly HP Laserjet issue, this is also a Postscript
issue as infinite loops are easiest to do in PS.

If I send the following PS job to a LaserJet printer (LJ2420DN over
JetDirect card or embedded interface):

%!
/n 0 def { n (................) cvs == flush /n n 1 add def } loop

or this one

%!
{ } loop

which doesn't output anything back,

I have found no way to abort the job either using TCP connection, PJL,
Web interface SNMP. Even STOP button in the front panel doesn't seem
to do anything.

PS related rambling:

Laserjet PS doesn't seem to have /JobTimeout paramater which could be
used to work around naive infinite loops where job doesn't change the
JobTimeout on purpose.

ctl-D, ctl-C or <ESC>%-12345X don't abort the job either, not over the
original channel or a new TCP connection.

Any suggestions?
 
Antti said:
Hello,

Although this is mainly HP Laserjet issue, this is also a Postscript
issue as infinite loops are easiest to do in PS.

If I send the following PS job to a LaserJet printer (LJ2420DN over
JetDirect card or embedded interface):

%!
/n 0 def { n (................) cvs == flush /n n 1 add def } loop

or this one

%!
{ } loop

which doesn't output anything back,

I have found no way to abort the job either using TCP connection, PJL,
Web interface SNMP. Even STOP button in the front panel doesn't seem
to do anything.

PS related rambling:

Laserjet PS doesn't seem to have /JobTimeout paramater which could be
used to work around naive infinite loops where job doesn't change the
JobTimeout on purpose.

ctl-D, ctl-C or <ESC>%-12345X don't abort the job either, not over the
original channel or a new TCP connection.

Any suggestions?
Click to expand...


Stop doing that.
 
Antti said:
Hello,

[infinite loops in PS-files are evil]

Any suggestions?
Click to expand...

Hi Antti Louko,

if you are working under LINUX/UNIX then maybe this can help you:

1.) Set an alias for the lpr command for all users
$> alias lpr="my_lpr"

2.) Put this small program 'new_lpr' in an accessible binary directory:


--------------------------------------8<--------------------------------
#!/bin/sh
# $Id: new_lpr $
# to avoid sending corrupt PS-files to the printer

# look it up for yourself, where your commands are
alias PS2PS="/usr/bin/ps2ps"
alias LPR="/usr/bin/lpr"
alias RM="/bin/rm -f"

# insert starting options here (default printer etc.)
OPTIONS=""

while true
do
case "$1" in
-*) OPTIONS="$OPTIONS $1" ;;
*) break ;;
esac
shift
done

if [ $# -ne 1 ]; then
echo "Usage: `basename $0` [-PPrinter] [...] output.ps" 1>&2
exit 1
fi

PS2PS $1 /tmp/$1_temp
LPR $OPTIONS /tmp/$1_temp
RM /tmp/$1_temp
-------------------------------------->8--------------------------------

If anyone is trying to print with the 'lpr'-command, then 'ps2ps' create
a new ps-file (default is PSLanguageLevel 2) from the original ps-file.
In the case, where the original ps-file contain an infinite loop or
other bad things, there is no new ps-file. And of course, there is no
print-job too.

No bad print-jobs, no more problems!

Hope that helps,
Greetings,
Oliver
 
Oliver Bendix said:
Antti said:
Hello,
[infinite loops in PS-files are evil]
Click to expand...
Click to expand...
If anyone is trying to print with the 'lpr'-command, then 'ps2ps' create
a new ps-file (default is PSLanguageLevel 2) from the original ps-file.
In the case, where the original ps-file contain an infinite loop or
other bad things, there is no new ps-file. And of course, there is no
print-job too.
Click to expand...

That is one way to handle the issue but it seems quite silly to run
same job twice just to check the evilness.

I am still looking a way to abort jobs in LJ.
 
Antti said:
I am still looking a way to abort jobs in LJ.
Click to expand...

The only way I have found is the power switch. When I sometimes send
"bad" jobs (that are fine according to GhostScript) to my HP printer,
the display shows an error code that means the controller is bad. When
that happens I have to cycle the power to fix it...

Best regards,

Mikkel C. Simonsen
 
Antti Louko said:
ctl-D, ctl-C or <ESC>%-12345X don't abort the job either, not over the
original channel or a new TCP connection.
Click to expand...

I experimented a little more. It seems that pressing "Cancel" button
in the physical panel or in the web interface really does nothing
_until next page is being printed_. At that moment, an interrupt
error is executed in PS environment.

It would make sense to cause interrupt immediately when cancel is
executed.

I try to put this through HP support process, but I am not too
optimistic with that accomplishing anything. If there is an HP
printer person reading this, we may move this to mail correspondance
and try to do something.
 
Antti,

establishing 'Cancel a Print Job' seems to be black art for
Minolta QMS (printer button, then travelling through the menue),
Win98 and WinXP.

A time-out for a loop is hardly a solution. The loop has to be
limited for N cycles by the programmer.
The time consumption is not predictable, but a reasonable cycle
limit N is.

Best regards --Gernot Hoffmann
 
Back
Top