[cups.bugs] [MOD] STR #4028: commandtops not robust against broken PostScript in PPD file

[Till Kamppeter]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

I want to add auto-configuring installable options, default tray, paper
size in default tray, ... in printer setup tools making use of the
"*?<option>" entries in PPDs and CUPS' commandtops printer maintenance
driver.

To trigger the auto-configuration on any PostScript printer with
manufacturer PPD (generic PPDs do not contain the "*?<option>" entries)
and a backend coming with CUPS (third-party backends like HPLIP's "hp" do
not support the back channel) one sends a command job like this:

echo -en '#CUPS-COMMAND\nAutoConfigure\n' | lp -d <printer>

The strange thing which I perceived is that the job takes several minutes
to complete for such a simple task.

I have investigated in error_log that most queries happen in less than a
second, and suddenly a query ("*?HPOption_PaperPolicy" in the attached
PPD) lets the job wait 90 seconds while the printer does not answer. I
investigated the PPD and this is the only query where the PostScript
commands are not framed by "save ... restore". I added this to the PPD
making this query working correctly.

Now I investigated further and saw that the printer errored out on
"*?InputSlot" in the same PPD file and told by a returned PS error message
that it will flush (=ignore) the rest of the job. This lead to all the rest
of the queries not being answered and so commandtops waiting for 90 seconds
per query until finishing the job and making the queue free for the next
job. I checked the PostScript for the "*?InputSlot" query by pasting it
into Ghostscript (simply started "gs" to get into interactive mode) and
there is a syntax error in the ifelse constructs.

So commandtops needs to get made robust against bad-quality PPD files. We
cannot correct the PPD files as there are too many and no one can test
them all as nn one has all these printers. And even if we succeed to talk
with all manufacturers, they will never fix all their already released
PPDs.

Things which need to be done are:

1. Reduce timeout from 90 seconds to 5 seconds
2. Do end_ps(ppd) after each query and begin_ps(ppd, user) before each new
query, and inbetween also the PJL-exit-server sequence to reset the printer
after a possible error-out. At least this should be done if a query did not
lead to a valid default setting for this option. This prevents from queries
being sent while the printer is flushing the rest of the job after a
PostScript error.
3. Wrap commands into "save ... restore" if they are not already wrapped
(can be HP-only problem).

With all this changed the maximum possible number of PPD options will get
auto-configured reliably, only skipping the ones with real PostScript
errors in the PPD and the job will complete in a reasonable time.

Link: http://www.cups.org/str.php?L4028
Version: 1.5.2
Attachment: http://www.cups.org/strfiles/4028/CLJ3530.ppd