When I \includegraphics certain PDF files (for example this SVG converted with Inkscape), the output produced by LuaLaTeX or PDFLaTeX will be such that when the page containing the picture is printed with CUPS, the whole page will be rasterized which looks like the bottom example in the picture below (I have the CUPS option to "force rasterization" which produces the same bad printout with any page so CUPS or my configuration of it is surely partly to blame). The first line is the same page without that PDF included. Other PDFs work just fine, as do all raster images (which is kind of paradoxical).
These are scans of the result of course, so please excuse the bad quality. You should still be able to see the wavy look of the "l"s and other slanted vertical lines.
Here for a comparison the rasterized output as a PDF:
I experimented a bit with different PDF viewers and printing to PDF instead of wasting paper. Here is what okular produced:
And this is acroread at the same zoom level:
If you watch closely, acroread might just have a slight edge 😉
Even when forcing acroread to "print as image" as I suppose the "force rasterization" option is named here, the result looks much better:
I don't know if it looks like the insane 2400 dpi it's supposed to be but still (these pictures are printed at about the text size of \small) .
Best Answer
This is most probably caused by transparency effects. Transparency effects are a relatively new feature for PDF (≥ 1.4) and many printers do not yet support it "out of the box" (basically, this requires a PostScript Level 3 RIP with additional PDF 1.4 extensions). So the printing system (printer driver) has to "flatten" transparency effects by rasterizing objects into ordinary CMYK objects before sending them to the printer.
Rasterizing is usually done page-wise: The complete page is rasterized into a bitmap and then send to the printer. This also effects the other content of the page, resulting in the observed "coarse appearance" of the text.
Especially, but not only, on Linux, many printer drivers do not do a particularly good job here. This is the reason that the results are often better when printing from Adobe Reader, which (optionally) perform the flattening before sending the page to the printer driver.
Workaround
The way out would be to flatten transparency effects in PDF graphics before embedding them into the document, so that the printer driver has no reason to rasterize a whole page. Adobe provides a white paper with some background info and how to achieve this with their products. My approach would be to use ghostscript to convert the respective images to PDF 1.3, which does not support transparency effects, hence, enforces their rasterization:
Unfortunately, ghostscript also just rasterizes the complete page (image), so the fonts inside the image will still get the "coarse appearance" and their text is no longer selectable in the resulting PDF. However, the main text of the document will now keep its high printing quality.
The situation becomes a bit different, if the transparency or shading effects on a page are not caused by an included graphics, but generated with
pdflatexdirectly – for instance, by using TikZ. The solution in the TiKZ case would be to employ its externalization feature to automatically perform the above transformation during compilation. There has been a dedicated question for this problem here on tex.se.