Report originated from a Chromium developer (not me) and I confirmed behavior on ToT.

Thanks to https://chromium-review.googlesource.com/c/chromium/src/+/673723 this is reported as an error in 63+.  In earlier versions, this manifests as a perpetually hung print job.

So hpcups implicit dependencies were not something I was aware of.  Ugh.

Here's all values for 'hpPrinterLanguage' in the ppds we currently serve ( generated via  zgrep hpPrinterLanguage * | sed -e "s/^.*\"\(.*\)\".*$/\1/" | sort -u )

hbpl1
lidil
ljcolor
ljfastraster
ljjetready
ljmono
ljzjstream
ljzxstream
pcl3
pcl3gui
pcl3gui2
quickconnect

Correlating that with ppds that are annotated in the NickName as requiring a proprietary plugin, the hpPrinterLanguage variants that are almost certainly currently broken becomes:

hbpl1
ljjetready
ljmono
ljzjstream
ljzxstream

egrep "\(hbpl1|ljjetready|ljmono|ljzjstream|ljzxstream\)" * | wc -l

tells us this affects 186 currently served ppds.

I'll go ahead and pull them from serving for now, since missing support is better than broken support.

For at least *some* of these printers, hp also provides a postscript ppd, so we should get at least some of the coverage back with a little more work, it's not clear how much offhand though.

Addendum -- only 124 of those ppds are actually tagged as "proprietary" in the NickName.  Presumably hpPrinterLanguage is the better discriminator here.

Removed broken ppds from serving, leaving this bug open until we get postscript replacements loaded, but I can't tackle that immediately due to other oncall duties.

Hi Justin,
Do you have a list of PPDs removed? 
Thanks!

I've checked that the change was reverted, printers returned to list. 

Following up on this to provide more context, the original pull of drivers was too broad, and pulled ppds for several printers that were not, in fact, broken.  Regretfully, this broke some users.

The original pull was rolled back, and then we rolled forward a narrower pull that we believe correctly targets everything that is actually broken. 

We have some tools in flight to pull in more postscript drivers, which should help restore most of the rest of the coverage, but this is not in the repository yet.

I believe this was fixed by the Nov 21 import of HPLIP 3.17.10.