On Fri 24 Feb 2023 at 12:58:15 -0500, Greg Wooledge wrote: > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote: > > Try this next time you're on site: > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere > > This worked. I printed two copies of the single-page PDF from Chrome > without any further problems.
Good. As I have previous indicated, this works because the vendor has not used ipp/canon as the resource, which it is at liberty to do so. A previous off-target comment was > My burning hatred of printers and this printing system > remains unquenched. Your hatred is aimed at completely the wrong target. How is it expected to have CUPS discover a printer when mdns multicasting is turned off on the printer by an incompetent sysadmin? > I've gotta say, though, this option is a disaster: > > -E When specified before the -d, -p, or -x options, forces the use of > TLS encryption on the connection to the scheduler. Otherwise, enables > the destination and accepts jobs; this is the same as running the > cupsaccept(8) and cupsenable(8) programs on the destination. > > Whoever decided to overload that option in that way... yikes. I could tell you, but perthaps you might want to find out for yourself instead of griping. Reporting (or searching) an issue at https://github.com/OpenPrinting/cups/issues might be easier than tackling the staff of your Help Desk. -- Brian.
