Ah, the tell of someone who has never implemented printing.
Pagination across different paper sizes when content is dynamic/interactive and includes things like section headers that you need keep with text and images and tables that users expect to not split across pages with their custom choices of margins, page-numbers, page titles etc. So many other issues like ensuring monochrome prints are legible, implementing print previews etc.
Oh boy. Some might think implementing math from papers is hard but no, it's this sort of thing. You'll be fixing problems with it for the life-time of the product.
It seems like the driver should detect paper size, broadcast a compatible print area/capabilities to something above, and then stand by to make any dot it can in the allowed area.
Why would the hardware driver need to deal with pagination, layout, or print previews (beyond advertising capabilities accurately)?
I've always imagined that drivers are hard on the hardware side. It is really difficult to reliably place dots on a page with the requisite precision/reliability at the price-point to which we have all become accustomed.
Sure, that would make for a decent PoC. It's all the work that will come later as you discover the browser is NOT doing a good job that will be the problem.
It may be different now, but it was not long ago that browsers would without remorse just let the printed page cut even images in half if a page break happened to be there. It seemed as if all they did was create an image of a length long enough to fit the printable content and just fed that to the printer. No smart layout at all.
If things are different now, it certainly was not during the brief time Wave was around.
Browsers don't normally work with paper-like pages, they work with essentially infinitely scrollable areas. So a browser layout engine is not in any way, shape or form optimized for laying out HTML + CSS in a printer friendly way, especially if you start having 'weird' requirements like A4 vs Letter, smart layout of tables across pages so that they are still readable etc.
In fact, in general, a human being must actually lay these things out by hand for print if that is the desired medium.
Which is an excellent attitude for a short PoC, but unimaginable for a paid product.
In the end, the user doesn't care. They want the printed page to be usable. If the browser makes it usable, excellent! If it doesn't, than the product is bad and an alternative must be found.
Sure, Google, being in control of Chrome, could implement a browser-level page layout engine.
Unfortunately, there is obviously no way to make a good general purpose layout engine, so that will never fly. Any site that wants to offer printing as a paid feautre must implement their own printable version, no question.
Ah, the tell of someone who has never implemented printing.
Pagination across different paper sizes when content is dynamic/interactive and includes things like section headers that you need keep with text and images and tables that users expect to not split across pages with their custom choices of margins, page-numbers, page titles etc. So many other issues like ensuring monochrome prints are legible, implementing print previews etc.
Oh boy. Some might think implementing math from papers is hard but no, it's this sort of thing. You'll be fixing problems with it for the life-time of the product.