Right, but the problem here isn't really printers, it's rendering the
pages. The same pages Casey's having trouble printing won't look as
PDFs, either.
Well, not 1:1 because you're still dealing with a transference of medium, but it should still be pretty darn close- PDF is designed with archival (and thus reproducibility) in mind. The concept of a "page" in PDF is much closer in concept to a "page" of hardcopy than a "page" in a browser is.
Which brings us to the crux of the problem: webpages/html and browsers are designed for displaying content which is rendered:
1.) In an unknown-by-content-author, dynamically-resizable size
2.) In a continuous fashion (i.e. no page breaks).
Both of these don't translate to hard copy. Sure, there's more than one paper size, but there are common standards (ISO standards at that) and common frequency (e.g. if you design a PDF that fits constraints for A4 for US non-legal consumers, that's guaranteed to "fit" the paper copy properly for the majority of consumers).
Authors for purely digital-intent text don't have the luxury/inconvenience (it's both) of these constraints. There may be common *screen resolutions* and bit depth/fidelity but they're all over the place -- nowhere near a specific common frequency, VERY variably sized display *devices*, and windows are resizable.
And again, it's unnecessary to consider "page breaks" in HTML. Even modern RFCs (e.g. 9110) no longer include page breaks in their HTML formats. Compare:
Which means the print pre-processor needs to determine where to put these page breaks and how to flow the text, and a lot is changed during this process because it's a completely different mode of display (dynamic -> static).