Prefer IPP color mode default over ColorModel

[oubayashi]

Summary

Prefer print-color-mode-default over the legacy PPD ColorModel
option when both are present in a printer modification request.

Some clients continue to send ColorModel=Gray after switching the
printer default back to color. CUPS currently translates this stale
value to print-color-mode=monochrome, which can prevent the requested
color default from taking effect.

Only use ColorModel as a compatibility fallback when
print-color-mode-default is absent.

Behavior

Before:

• print-color-mode-default=color with ColorModel=Gray could select
  monochrome.

After:

• print-color-mode-default takes precedence when present.
• ColorModel continues to work for legacy clients that do not provide
  print-color-mode-default.

[zdohnal]

Hi @oubayashi ,

thank you for the PR!

Unfortunately this would break color/gray printing via legacy keyword, because nowadays we have print-color-mode as a default attribute in cupsd, but I understand now print-color-mode default is ignored completely.
Ideally we will need a way how to either enforce the server default for an attribute, or honor the settings sent with requests.

I made an attempt to create some solution at https://github.com/zdohnal/cups/commits/server-defaults/ (at the moment it would set relax/strict settings for the whole daemon, but later got idea it could be more useful settings if it would be per-attribute).

[oubayashi]

Thanks for the explanation.

I agree that the actual problem is how CUPS distinguishes between a default value that can be overridden by the request and a server-enforced value. A per-attribute policy sounds like a better and more general solution.
I’ll close this PR since the current approach is not correct. Thanks for reviewing it and for pointing me to your server-defaults work!