How to abort Postscript infinite loop jobs in LaserJet pri..

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

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?

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

Antti Louko wrote:
> 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?


Stop doing that.

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

jbuch <jbuch@CUTHERErevealed.net> writes:

> Stop doing that.

The point is that anyone who can send jobs to the printer can do
that.

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

Antti Louko wrote:
> Hello,
>
> [infinite loops in PS-files are evil]
>
> Any suggestions?

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

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

Oliver Bendix wrote:
> 1.) Set an alias for the lpr command for all users
> $> alias lpr="my_lpr"
Sorry, I mean
$> alias lpr="new_lpr !*"

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

Oliver Bendix <oliver@chaos.gwdg.de> writes:

> Antti Louko wrote:
> > Hello,
> > [infinite loops in PS-files are evil]

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

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.

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

Antti Louko wrote:
>
> I am still looking a way to abort jobs in LJ.

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

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

Antti Louko <alo@iki.fi.invalid> writes:

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

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.

 

[Guest]

Archived from groups: comp.lang.postscript,comp.periphs.printers (More info?)

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