On Fri, Aug 16, 2019 at 11:23:48PM +0100, Brian wrote: > On Fri 16 Aug 2019 at 22:39:09 +0300, Reco wrote: > > > On Fri, Aug 16, 2019 at 07:14:58PM +0100, Brian wrote: > > > On Fri 16 Aug 2019 at 09:51:15 +0300, Reco wrote: > > > > > > > On Thu, Aug 15, 2019 at 08:47:34PM +0100, Brian wrote: > > > > > > > > > Nowadays that system often relies on printer/print queue Bonjour > > > > > broadcasts. > > > > > > > > And that is called "jumping to conclusions". > > > > Printing itself haven't changed a bit for last 15 years - a print server > > > > takes user's PS or PDF, mangles it to fit printer's representation (be > > > > it PCL or something else), and feeds it to the printer. By utilizing > > > > unicasts of course. > > > > > > I was going to let this go because it takes us beyond the server > > > situation we are discussing and is a reasonable, succinct description > > > of classic printing (which will become unsupported by CUPS in a few > > > years time). > > > > > > However, modern printers will accept and print jobs (e.g. PDF and JPEG) > > > without the mangling. These AirPrint-enabled, IPP printers completely > > > do away with having to use non-free software or plugins also. What is > > > there to dislike about that? > > > > Nothing. But it also means that one only needs something like ipptool > > ([1]) on client-side, leaving CUPS (and a whole notion of a "print > > server") out of the equation completely. > > ipptool depends on libcups2.
Which does not make it require CUPS on the other side - [2]. And note - a conventional RFC1918 IP is used there. No "discovery" involved. > > > > A user can discover a print server via mDNS multicasts (*not* > > > > broadcasts). Or a user can be told a location of such print server. > > > > > > So - I give my VIP, Android-using customer a piece of paper with a URI > > > to type into his phone rather than telling him which printer to use to > > > print out the multimillion Euro contract he has just signed? > > > Very last century. > > > > Multicasts are limited to a single L2 network segment by their very > > definition. > > DNS-SD/Bonjour not scaling on typical multi-segment networks is a > recognised issue by CUPS upstream. An interesting example of corporate doublespeak, but it does not change what I wrote - you need multicasts working - you put both sender and receiver in a single network segment. And that's bad for security, and is so last century. > > Besides, "multimillion Euro contract" can involve some pretty secretary > > lady who's happy to print said contract. Just saying. > > I have no idea whether a secretary likes to be typecast, but is being > pretty, male and amenable a prerequisite to obtaining the post? > > Anyway, the secretary has knocked off and I am left to instruct my VIP > how to use his Android phone to type the printer location without a > mistype: > > dnssd://ENVY4500._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2 You overcomplicate things without the need. ipp://<ur_printer> is all you need. Reco [2] https://stackoverflow.com/questions/19232082/printing-using-ipp-without-drivers-ipp-client
