Debugging css issues related to print can be a bit of a PITA. Adding print options for dynamic content in a full stack page is not technically that hard. But getting it looking right can be a bit fussy. If you don't care about what things look like once printed, it's easy. But if you do care, it actually needs a bit of consideration.

I've done a few custom things with an application that generates labels for a label printer using just css and javascript. This is not that hard. But it does involve dealing with a lot of weirdness related to native print dialogs, vs. browser specific print dialogs (and their print previews), feature interaction with native printer settings and their scaling options, browsers adding footers to the printed document, and just general weirdness related to layout issues, page sizes, margins, etc.

My general feeling dealing with this is that CSS for print just gets a lot less scrutiny than regular CSS by browser developers.

One of the hacks you can do is generate a dom tree just for print. Replace the root of your dom tree with that, trigger the print, and then put the old dom tree back (with your full stack application and all the rest). Seems very hacky to have to do it like that. But it kind of works and is simple enough to do. And the benefit is that it stops the rest of your application (which probably does not take print into account at all) out of the equation and will stop that from interfering with your print layout. Conceptually, makes you wonder why you can't just hand a separate document tree + CSS to the print api call. This is a lot simpler than having one unified dom tree and one flattened unified CSS file. Separation of concerns is a good thing.