>AirPrint doesn’t require a driver because it says that part is always the same, you just send a pdf to the printer and it turns it into a bitmap and puts it on paper.
That's not quite how it works. AirPrint supports PDF, JPEG and a raster format (URF). The raster format is the only one that is required on the printer. Most of the cheap devices don't have the resources to render a PDF on the printer.
>And they can do that just fine outside of the normal printing infrastructure.
Not right now they can't, there are a lot of these sorts of applications that are relying on the existing system.
Even selecting a paper size in Word ends up with a query to the driver of the printer.
I fail to see how that makes any difference. It supports a limited number of ways to send a page description to the printer, which is why it doesn’t need a driver.
And as for these enterprise supported receipt printing solutions? Well guess what, they’ll need to find a new way to send their custom commands to a receipt printer. Or perhaps they’ll use some deprecated legacy service that is not available on home editions of Windows and is off or not even installed by default.
By the way, AirPrint knows the paper size just as well as any solution. It’s just standardized so it doesn’t require untrusted code to run in privileged places. And if Word uses some Windows 3 api to ask a driver for the paper size, that driver can be a generic Microsoft driver and if that isn’t enough, that’s what shims are for.
That's not quite how it works. AirPrint supports PDF, JPEG and a raster format (URF). The raster format is the only one that is required on the printer. Most of the cheap devices don't have the resources to render a PDF on the printer.
>And they can do that just fine outside of the normal printing infrastructure.
Not right now they can't, there are a lot of these sorts of applications that are relying on the existing system.
Even selecting a paper size in Word ends up with a query to the driver of the printer.