Collate broken under Fedora 19/CUPS-1.6/hplip-3.13.7 possibly because hpps sends SET COPIES (fix included)

It looks like CUPS-1.6 tickles a latent bug in hplip's hpps. I'm seeing the problem when collating and printing to a HP LaserJet Pro 400 m401dw, but the problem might affect other printers that use the hpps filter.

Details:
When I upgraded from Fedora 17 (CUPS-1.5.4, hplip-3.13.4) to Fedora 19 (CUPS-1.6.3, hplip-3.13.7), collating stopped working when printing to my HP LaserJet Pro 400 m401dw. Documents still printed but they were not collated when I checked "Collate" in the print dialog. Also, collating continued to work when printing to an HP Officejet 4500 printer.

Based on debug CUPS logging I can see that CUPS is applying the pdftopdf, pdftops, and hpps filters. I was able to confirm that the PS sent to hpps was, in fact, collated even though what was coming out of the printer was not. Looking at hpps, I found that commenting out the following line fixed the problem:

os.write(output_fd, '@PJL SET COPIES="%s"\x0a' % copies)

Basically, it looks like hpps is trying to tell the printer to print multiple copies of a PS file that already contains multiple collated copies. Somehow this effectively undoes the collation. Interestingly, commenting out the same line under Fedora 17 is not necessary (though it does no apparent harm). I'm assuming the difference in behavior is attributable to whether the collation occurs in PS (in CUPS-1.5) versus PDF (in CUPS-1.6).

The CUPS filter documentation (http://www.cups.org/documentation.php/api-filter.html#COPIES) says, "The argv[4] argument specifies the number of copies to produce of the input file. In general, you should only generate copies if the filename argument is supplied. The only exception to this are filters that produce device-independent PostScript output, since the PostScript filter pstops is responsible for generating copies of PostScript files."

My understanding is that CUPS-1.6 uses PDF instead of PS as the intermediate format and thus uses pdftopdf instead of pstops to generate copies (and collate, etc). However, the documentation seems to imply that a filter shouldn't generate copies if it is going to be used in the same chain as another filter which is going to generate copies. Since changing hpps to not generate copies fixed the problem for me, I'm assuming that the bug is indeed in hpps and not CUPS.

This is my first deep dive into the world of CUPS and hplip so if I've misread the situation please forgive me and point me to a more appropriate place to report the bug.

Thanks!