itp does not catch interrupt signal and trigger PS-level /interrupt error. about xpost

[GoogleCodeExporter]

This ability is needed for computation-heavy interactive programs like my 
Mandelbrot Explorer: 
https://groups.google.com/d/topic/comp.lang.postscript/CZGwAun5Juo/discussion . 
If the resolution is set too high, the drawing will be painfully slow, but 
cancelling (in ghostscript) exits the entire interpreter, losing the active 
program parameters.

interrupt signals -> /interrupt errors is the right thing to do, according to 
the PLRM.

Original comment by luser.droog on 30 Oct 2013 at 9:36

[GoogleCodeExporter]

A later version of the same program: 
http://code.google.com/p/xpost/downloads/detail?name=mandel2.ps .

Original comment by luser.droog on 30 Oct 2013 at 9:39

[GoogleCodeExporter]

This is a usability requirement for dealing with runaway programs. Infinite 
loops and such. If not an interrupt signal per-se (depending upon application 
requirements), There should be some mechanism for stopping a long-running 
execution from the outside, gracefully. And this should manifest from the 
postscript-level as an /interrupt error, sandwiched between the execution of 
two normal objects, as described in the PLRM.

Original comment by luser.droog on 2 Dec 2013 at 11:49

[luser-dr00g]

This one should probably be considered low priority. Ghostscript doesn't do this. When I filed a bug report with them, it was closed as "Confirmed. Won't Fix." So GS doesn't even do it, and has no plans to do it. And I suppose we've all gotten by well enough in the meantime without missing this feature very much.

OTOH it is something that GS doesn't do! So it's potentially a feature we have that GS doesn't, once implemented that is.