Bare staple value not handled in finishings-supported

[yetamrra]

I have encountered a driverless printer that includes staple in the finishings-supported attribute, but doesn't have any of the other staple-XXX values. The PPD generated by cupsd doesn't contain any of the *StapleLocation or *cupsIPPFinishings keywords that normally get generated for other printers.

Taking a look at the section starting at cups/ppd-cache.c:4517, it seems like this is supposed to work by mapping through the SingleAuto keyword. But the two checks on lines 4553 and 4600 only match values that start with staple-, so the bare staple value never gets handled. Locally patching in a check for strcmp("staple") makes things behave the way I would expect and also looks similar to the checks done for other finishings later in the same file, but I'm not sure if I might be missing something here.

Is the bare staple value supposed to work when the other staple-XXX values aren't present? I couldn't find anything in the IPP Finishings doc saying it shouldn't, but finishings has been covered in enough different places that I don't have confidence I read everything relevant. If it is supposed to work, do you want me to send a quick PR to add the missing value to the checks?

The same issue might apply to a bare bind value based on the similar pattern in the same checks.

I've attached an ippserver config captured from this printer in case you want to look through the whole set of attributes.
HL-L6415DW.conf.txt

[michaelrsweet]

Confirmed, will also make sure the base "punch" and "fold" values are covered as well.

[yetamrra]

Just wanted to double-check on this. Would it be helpful for me to send a PR?

[zdohnal]

@yetamrra PRs are always welcome!

[yetamrra]

Sure thing. I sent #1094 with a proposed fix.

[yetamrra]

Sorry, I forgot to post a follow-up here. We've cherry picked the fix into the 2.4 branch on ChromeOS and confirmed that it works as expected with the original printer.