Fun fact about subpixel antialiasing: at some point, Firefox was printing the subpixels when printing PDFs displayed with PDF.js. That looked awful. I'm actually not sure whether that was fixed, as I haven't printed in years (also, I have disabled subpixel AA for a while because of my dual monitor not in the same direction setup)

Probably because pdf.js is implemented using so it's basically like printing screenshots of the PDF

They have been working on SVG backend for quite a while to get real vector printing, still not done.

I am not surprised, given the poor SVG support of Firefox (and browsers in general). Also there are gradient types that PDF supports but SVG doesn't. I am also not sure why they would need to go through SVG for printing.

SVG is the only way to get vector printing through a browser currently unless its just normal html/css which isn't enough to render a pdf.

Canvas is just a bitmap so when printing pdf.js renders to a certain dpi canvas which I believe is less than 300 dpi (150?) which even still uses huge memory and ends up with fuzzy text.

You don't want bitmaps going to printer for text and line art, you want vector so it can come out at 600+ dpi while using minimal memory.

> SVG is the only way to get vector printing through a browser currently

This is what seems weird. Why is that? Also it's not like most printer drivers don't need to convert it back to ps or pdf before printing.

SVG is turned into the appropriate PS/PDF vector drawing command by the browser print engine, canvas just gets sent as a bitmap in the printer language since that all that's left.

I believe pdf.js incorporated and modified https://github.com/gliffy/canvas2svg which implements the canvas api but instead creates an SVG dom.