On Mon 14 Mar 2016 at 13:20:25 (+0000), Brian wrote: > On Sun 13 Mar 2016 at 22:48:07 -0500, David Wright wrote: > > > On Sun 13 Mar 2016 at 19:32:04 (+0000), Brian wrote: > > > > > > I've said specifically it has a PDF converter. It must have; the printer > > > does not understand PDF. > > > > Once again, I don't understand this statement because I don't > > understand your terminology... > > "PDF filter" would be a suitable substitute for "PDF converter". But not > "PDF interpreter".
OK. Debating what to call what happens between PDF and ink-on-paper is "less important" (I'm learning) than my trying to tie down whether that process takes place entirely in the printer, ie the box we bring back from the store. > > My question with pronouns removed: "So if a PDF arrives by AirPrint, > > how does the MFC-J5720DW printer interpret the PDF if the MFC-J5720DW > > printer doesn't have a PDF converter?" > > > > Your response AIUI with pronouns removed: "I've said specifically the > > MFC-J5720DW printer has a PDF converter. The MFC-J5720DW printer must > > have; the MFC-J5720DW printer does not understand PDF." > > > > Is that what you mean to say? If not, couuld you replace the > > appropriate nouns by different nouns. > > Yes. But maybe my understanding of what an onboard PS/PCL/PDF interpreter > does (stated in an earlier mail) is different from yours. OK. Debating... (ditto as above). > > None of your examples (the bits -> like -> this) have "AirPrint" > > mentioned in them. I'm trying to learn from you what AirPrint is and > > what it does. And yet your statements about it say things like > > "The AirPrint facility handles a PDF (it has to)." and "Substitute PS, > > PCL, QPDL etc for BUL to see how other manufacturers might deal with > > AirPrint." which tell me nothing specifically about AirPrint. > > We seem to be both agreed that a PDF arriving at an AirPrint-compatible > printer has to be dealt with in some way to ready it for printing. Let's > leave it there. It is interesting to speculate how a printer processes a > PDF sent from a driverless device but ultimately it is of no great > consequence because it is not under our control. It's of the greatest consequence if there's a way of getting a linux box to send PDF files to an AirPrint printer and have them print. It means you can walk into a store and just buy something, take it home and it works. A bit like when I worked in a university: the printers understood PDF files so I knew I could just send stuff to the queue and it would print it. Here's my old methodology for buying a printer: -Go to the store and look and printers. -Persuade wife to "check reviews" rather than buy straight away. -Go home and look at linuxprinting-type websites for linux compatibility. -Search forums for complaints/difficulties. -List some linux-compatible models. -Go back to store only to find that all these model numbers are out of date and unavailable, replaced by shiny new models. -Persuade wife that the shiniest model she wants is going to be a great doorstop (or else she's going to have to print all my wants from a stick). -Buy a printer. -Find a driver that kind-of works. -Work round the problems that the driver throws up. > > > The part played by what is in the Bonjour broadcasts is crucial to the > > > whole thing working. Apart from the questionable use of cp, IPP is used > > > for printing and is what is advertised in the broadcasts. > > > > OK. I can see that CUPS has some work to do to find the printer with > > whatever it uses (dnssd/avahi/bonjour/...). That part doesn't really > > interest me in this discussion. > > It really should. Without Bonjour broadcasting by the printer AirPrint > would not exist. I wrote "in this discussion". Drivers, not discovery. AFAICT I'm already using avahi to print now. I'm not, however, sending raw PDFs to the discovered printer. > > > The CUPS backend converts PDF to BUL. > > > > Why bother? The AirPrint technology built into the MFC-J5720DW printer > > can do that. Why can't CUPS send PDF down the wire to the printer, > > thereby avoiding all the driver-crap? You've just said "The AirPrint > > facility handles a PDF" (requoted above). Why not let it do so? > > Why not, indeed? The Bonjour broadcasts of the printer should be picked > up by avahi-daemon and the printer listed in the print dialogues of some > applications (e.g Iceweasel/Firefox). These applications produce PDFs as > a matter of course. They are sent directly to the printer and the > printer sorts them in some way. No filtering on the machine is > necessary so cupsd is not involved, whether or not it is on the system. > > This implementation of this idea was the objective being worked towards > in > > https://lists.debian.org/debian-user/2016/03/msg00401.html > > as a solution to Jarle Aase's issue. All we need is someone with an > AirPrint printer to test it. :). Yes. Has noone else on this list bought one? There's a huge list of models. Unfortunately my model is HP Officejet Pro 85xx and one needs 86xx for AirPrint inclusion. > But if the printer is not AirPrint-compatible we will need cupsd and the > backend filter. (That lead to the discussion of what happens on the > printer). > > > > But, as it happens, you do not > > > need cupsd to print to an AirPrint printer. > > > > OK. What's the minimum that you _do_ need? By minimum, I'm meaning > > things like drivers; the things that linux users get tripped up by; > > the things that make "perfectly functional" printers into doorstops. > > When cupsd isn't running no drivers are needed because the print job is > sent directly to the AirPrint-compatible printer. avahi-daemon is > required, of course. > > When sent to a non-compatible printer the minimum number of drivers > needed is determined by the printer make and model when it is set up as > a local or remote shared printer with CUPS. Cheers, David.
