Bare staple value not handled in finishings-supported #1073
Comments
|
Confirmed, will also make sure the base "punch" and "fold" values are covered as well. |
|
Just wanted to double-check on this. Would it be helpful for me to send a PR? |
|
@yetamrra PRs are always welcome! |
yetamrra
added a commit
to yetamrra/cups
that referenced
this issue
Nov 1, 2024
In the generated PPD, IPP finishings "bind" is supposed to map to "StapleLocation: BindAuto". Similarly, "staple" is supposed to map to "StapleLocation: SingleAuto". The code already handles this, except the lookup is blocked by a check that only accepts "staple-*" and "bind-*" prefixed versions. Fix this by adding the bare versions to the existing checks. Fixes issue OpenPrinting#1073.
|
Sure thing. I sent #1094 with a proposed fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have encountered a driverless printer that includes
staplein thefinishings-supportedattribute, but doesn't have any of the otherstaple-XXXvalues. The PPD generated by cupsd doesn't contain any of the*StapleLocationor*cupsIPPFinishingskeywords 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
SingleAutokeyword. But the two checks on lines 4553 and 4600 only match values that start withstaple-, so the barestaplevalue never gets handled. Locally patching in a check forstrcmp("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
staplevalue supposed to work when the otherstaple-XXXvalues 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
bindvalue 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
The text was updated successfully, but these errors were encountered: