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. > > 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. Putting your printers (or print servers) within a guest network (WiFi for Android customers) - that's a last century indeed. Besides, "multimillion Euro contract" can involve some pretty secretary lady who's happy to print said contract. Just saying. Reco [1] https://github.com/istopwg/ippsample
