We don't have a DPI setting, since this is not supported in the printing architecture. The images are printed in its original resolution.

Skia folks may be able to advise if there's support for this from their side (or plans to add it).

This support is in Skia today (see SkDocument.h), so API could be supported on our side if Chrome was in position to enable...

Based hcm@ comment tagging with printing and cc'ing Lei for further traige of the bug.

Any luck on this?

Nay. Too many bugs and I lost track of this one. Assigning to myself for too many + 1 bugs. :)

Probably feasible, but requires quite a bit of plumbing to get from a user specificed value in the Headless protocol all the way down into the guts of the printing system.

Wow this would be really useful. Text shadows really don't look good without it.

Agreed - hugely useful to me removing usage of an older unsupported phantomjs version

Any idea how I could fake (force) this in the mean time? I tried recompiling Chromium with #define SK_ScalarDefaultRasterDPI 300.0f in include/code/SkDocument.h, but it didn't have any effect. Next, I will try to use #define SK_PDF_MASK_QUALITY 100 in src/pdf/SkPdfDocument.cpp, but I'll have to wait a few hours to see if it changed anything (man, Chromium takes so much time to compile ;).

It turns out it's not enough because of this:

static bool not_supported_for_layers(const SkPaint& layerPaint) {
    // PDF does not support image filters, so render them on CPU.
    // Note that this rendering is done at "screen" resolution (100dpi), not
    // printer resolution.
    // TODO: It may be possible to express some filters natively using PDF
    // to improve quality and file size (https://bug.skia.org/3043)

    // TODO: should we return true if there is a colorfilter?
    return layerPaint.getImageFilter() != nullptr;
}

Investigating how I could force higher DPI in SKBitmapDevice...

Related: https://bugs.chromium.org/p/chromium/issues/detail?id=838497

First, let me clarify that I've been producing large (upwards of 1,000 page) PDFs, in volume, for more than 10 years and I'm actively contributing to a number of projects (and building my own) to help others do the same :)

That said, I've been watching Chrome print support grow up since the earliest days, but I've had to use FireFox when printing from browser until just recently, because Chrome was nowhere near ready (and still a ways off compared to Firefox, WKHtmlToPDF, Prince and such), but is making great progress. This DPI issue is one of the other show-stoppers for me and the idea that it's at screen DPI or 100 dpi makes no sense. A 978 page PDF I just generated from Chrome using Print/Save-As-PDF is 40MB while the same one (with downsampling to 150DPI) from WKHTMLTOPDF is < 10MB.

Might they be storing images once, then reusing them (as should be the case per my CSS) to keep the PDF size down? Images look like 100DPI in terms of quality (as others have said), but where is the file size coming from if not the images?

Rendered DPI control is critical to PDF and anyone claiming it's not relevant is somehow missing the graphical half of the media/print world, which is well addressed by other pdf generators.