Duplex printing does not work properly for HP printers

[Roger James]

I am reporting this as a new bug because I want to avoid adding further to the mish mash of half fixed bugs that is duplex printing on hp printers via cups.

I will warn readers that this will sound like a bit of a rant. But these issues have been outstanding for years

1. Take the hpcups.drv driver information from the upstream part of the current source package and run it throught the cups ppd compiler in test mode, anbd filter the output for failures.

roger@dragon:~/ppd-testing$ ppdc -t hpcups.drv.upstream | grep FAIL
roger@dragon:~/ppd-testing$

Result a nice clean file.

2. Take this file and run it through the script debian/local/make-duplex-page-sizes-default.sh that is run when this file is installed on a system. Then repeat the above test.

roger@dragon:~/ppd-testing$ ppdc -t hpcups.drv.munged | grep FAIL

--- Other FAILS removed

hp-photosmart_6510_series.ppd: FAIL
      **FAIL** Multiple occurrences of option PageRegion choice name Card4x6.
      **FAIL** Multiple occurrences of option PageRegion choice name Hagaki.
      **FAIL** Multiple occurrences of option PageRegion choice name Card5x8.
      **FAIL** Multiple occurrences of option PageRegion choice name Oufuku.
      **FAIL** Multiple occurrences of option PageRegion choice name Executive.
      **FAIL** Multiple occurrences of option PageRegion choice name A4.
      **FAIL** Multiple occurrences of option PageSize choice name Card4x6.
      **FAIL** Multiple occurrences of option PageSize choice name Hagaki.
      **FAIL** Multiple occurrences of option PageSize choice name Card5x8.
      **FAIL** Multiple occurrences of option PageSize choice name Oufuku.
      **FAIL** Multiple occurrences of option PageSize choice name Executive.
      **FAIL** Multiple occurrences of option PageSize choice name A4.

--Other FAILS removed

I have removed the many other printer types that fail for clarity. It is a feature of the cups ppdc compiler that if you do not specify the -t option it will blithely go on and produce the compiled ppds errors and all. I personally think that this is a bug and the compiler should refuse to produce erroneous ppds, but putting that to one side. Taking A4 as an exmaple the hp6510 ppd file now has two definitions for PageSize A4.

*PageSize A4/A4 210x297mm: "<</cupsInteger0 26/PageSize[595.44 841.68]/ImagingBBox null>>setpagedevice"
and
*PageSize A4/A4 AutoDuplex 210x297mm: "<</cupsInteger0 26/PageSize[595.44 832.68]/ImagingBBox null>>setpagedevice"

Same name but different page dimensions. Only the first one will ever be seen by the cups system.

3. This above often does not matter when printing from the command line. Because PageSize options are not often specified. However, taking as an example a gnome desktop application such as Evince printing a pdf using the gtk+ print options with duplex printing selected. In this case a PageSize option will be passed to Cups and it will look like this.

D [11/Apr/2016:17:59:54 +0100] [Job 288] argv[5]="InputSlot=Upper number-up=1 MediaType=Plain PageSize=Custom.A4 OutputMode=Normal ColorModel=KGray Duplex=DuplexNoTumble job-uuid=urn:uuid:4ef4d5ed-e47e-3817-4972-b4bfad8ef5d8 job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1460393994 time-at-processing=1460393994"

So the PageSize is "Custom.A4". The "Custom" bit gets stripped off so what is passed down for matching is "A4" which matches the first occurrence of A4. Depending on what other defaults are set in the pdd it might print something, but it will most likely be clipped. In the case of the 6510 it results in this.

D [11/Apr/2016:17:59:55 +0100] [Job 288] Unrecoverable error: rangecheck in setpagedevice

Of course the above line only appears in the error_log if you have debugging turned on. So the job just appears to stuck in the print queue for no reason at all. This is probably another bug.

The work around. This has been mentioned many times in various bug reports. You need page sizes, page regions, imageable areas, and paper dimensions with names ending in .Duplex in your ppd. Rename the duplicate which has the biggest bottom margin, hopefully this is the one with AutoDuplex in the descriptive text. It is probably best to make these entries default as well. You might make the corresponding changes in the drv file if you wish. That will save you having to reapply them every time the ppd file is regenerated.

I realise that I have broken just about every rule in the "bug laws". I offer no excuse:-)

Comments please.

Roger

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: printer-driver-hpcups 3.15.7-0ubuntu4
ProcVersionSignature: Ubuntu 4.2.0-35.40-generic 4.2.8-ckt5
Uname: Linux 4.2.0-35-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Apr 11 18:10:41 2016
InstallationDate: Installed on 2014-05-04 (707 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
Lpstat: device for HP-Photosmart-6510-series: dnssd://Photosmart%206510%20series%20%5BFDAD30%5D._pdl-datastream._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-441ea1fdad30
MachineType: System manufacturer System Product Name
Papersize: a4
PpdFiles: Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/HP-Photosmart-6510-series.ppd'] failed with exit code 2: grep: /etc/cups/ppd/HP-Photosmart-6510-series.ppd: Permission denied
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 LANGUAGE=en_GB:en
 XDG_RUNTIME_DIR=<set>
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.2.0-35-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
SourcePackage: hplip
UpgradeStatus: Upgraded to wily on 2015-10-24 (170 days ago)
dmi.bios.date: 05/19/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0403
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: P6T SE
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0403:bd05/19/2009:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP6TSE:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Roger James (rogerjames99)]

I have changed the original bug text slightly. After spending some time grepping the cups and gtk source to find what was adding the .Duplex suffix I realised it was probably coming from my own changes and I had copied the wrong bit of log into the bug. The problem is still that it is the second A4 occurrence that has the correct bounding box for duplex printing and of this is never found.

[Roger James (rogerjames99)]

So... after looking at that debian/local/make-duplex-page-sizes-default.sh again and remembering why I hate perl.

I decided that this bug should probably be changed to:

The make-duplex-page-sizes-default.sh generates causes bad ppd files to be generated for the following printers.

hp-officejet_6800.ppd: FAIL
hp-officejet_pro_6830.ppd: FAIL
hp-photosmart_5510d_series.ppd: FAIL
hp-officejet_pro_6230.ppd: FAIL
hp-photosmart_6510_series.ppd: FAIL
hp-envy_7640_series.ppd: FAIL
hp-officejet_5740_series.ppd: FAIL
hp-envy_5640_series.ppd: FAIL
hp-envy_5660_series.ppd: FAIL
hp-officejet_8040_series.ppd: FAIL
hp-officejet_6700.ppd: FAIL
hp-officejet_pro_3610.ppd: FAIL
hp-photosmart_7520_series.ppd: FAIL
hp-officejet_7610_series.ppd: FAIL
hp-officejet_7110_series.ppd: FAIL
hp-officejet_pro_8500_a909a.ppd: FAIL
hp-officejet_pro_8500_a909g.ppd: FAIL
hp-officejet_pro_8500_a910.ppd: FAIL
hp-photosmart_c309a_series.ppd: FAIL
hp-officejet_pro_3620.ppd: FAIL
hp-photosmart_7510_series.ppd: FAIL
hp-officejet_pro_8500_a909n.ppd: FAIL
hp-officejet_6000_e609n.ppd: FAIL
hp-deskjet_3540_series.ppd: FAIL
hp-photosmart_premium_c309g-m.ppd: FAIL
hp-photosmart_prem-web_c309n-s.ppd: FAIL
hp-officejet_6500_e709n.ppd: FAIL
hp-envy_4500_series.ppd: FAIL
hp-photosmart_prem_c310_series.ppd: FAIL
hp-officejet_6500_e710n-z.ppd: FAIL
hp-deskjet_4510_series.ppd: FAIL
hp-officejet_4630_series.ppd: FAIL
hp-officejet_pro_8000_a809.ppd: FAIL
hp-deskjet_4640_series.ppd: FAIL
hp-photosmart_estn_c510_series.ppd: FAIL
hp-photosmart_prem_c410_series.ppd: FAIL
hp-envy_5530_series.ppd: FAIL
hp-laserjet_professional_p1609dn.ppd: FAIL
hp-laserjet_professional_p1606dn.ppd: FAIL
hp-laserjet_professional_p1607dn.ppd: FAIL
hp-laserjet_professional_p1608dn.ppd: FAIL

[Till Kamppeter (till-kamppeter)]

Can you please test (with a live CD or USB stick) whether the problem persists in Xenial (Ubuntu 16.04 LTS)? Thanks.

[Roger James (rogerjames99)]

Hi Till,

Just tested with a Xenial live dvdrom. Yes the problem is still there.
Looks like the same list of printers.

Roger

On 12/04/16 17:48, Till Kamppeter wrote:
> Can you please test (with a live CD or USB stick) whether the problem
> persists in Xenial (Ubuntu 16.04 LTS)? Thanks.
>
>
> ** Changed in: hplip (Ubuntu)
> Status: New => Incomplete
>

[Roger James (rogerjames99)]

Just realised that I still have not got the wording right in the description regarding the workaround. I think a simpler workaround given the current layout of the hpcups.drv file is just to remove the first occurence of each the duplicated pagesize and PageSize and PageRegion lines in the ppd and make sure the second one is picked up by default. I will hold off modifying the description until others have verified this.

[Till Kamppeter (till-kamppeter)]

Can you tell me which version of printer-driver-hpcups is installed on the live system of Xenial?

[Roger James (rogerjames99)]

The version on Xenial is hplip-3.16.3+repack0

I have cut out the bits of the Xenial hpcup.drv file that generate the ppds for the 6510 and other Copperhead printers, and used them to run some tests.

These show that the make-duplex-page-sizes-default.sh (from Xenial) fails to rename the original A4 definitions to A4.SM for these printers.

I have attached before and after version of this cut down file and the script from the Xenial source for anyone to try this for themselves.

I even pulled out my O'Reilly Perl book, but I still could not any sense of the script!

Roger

[Till Kamppeter (till-kamppeter)]

In the Perl script there is the following code portion:

----------
finished=0
while [ $finished = 0 ]; do
    perl -e 'my $content = join("", <>); $content =~ s:(CustomMedia\s*\")([^\s\.\/]+)(\/([^\"]+?\s+|))(\S+\"([^\n]*\n){0,4}\s*CustomMedia\s*\")(\2)(.Duplex)(\/[^\"]*?\s*)(AutoDuplex ):\1\2.SM\3Small Margins \5\7\9:smgi; print $content' $f > $f.new 2>/dev/null
----------

The third line of this code portion is a perl call with a very long regular expression, containing "{0,4}" at some point. Can you replace this by "{0,100}?". Does this improve the result, leading to less failing PPDs? Or does it totally solve the problem? Or does it even cause new problems. If it does not solve the problem completely, try using a higher number than 100, but do not use numbers causing new problems. Try also to replace the "{0,4}" expression by "*?". Does this solve the problem without causing new failures?

Another question: How do you determine failures? All the time with "ppdc -t <file>.drv"? And to which file do you apply it? To the one installed into the system as "/usr/share/cups/drv/hpcups.drv"? Or to another file?

[Roger James (rogerjames99)]

 "{0,100}?". No change same failures.

 "*?" Lots more failures.

Not done any tests with bigger than 100, the request is too open ended!

Is it time to reassess this approach? I suggest we ensure that the DRV file is correct at package build time and push the required changes upstream. Running a script at install time to try to correct the file seems like asking for trouble to me. Is their any way to use UIConstraints to ensure that any printer that requires special duplex page sizes does not allow the option to be set without a duplex page size being selected. I we have to run a script then do it at package build time and error the build process if this results in an invalid DRV file.

My procedure for running these tests is as follows.

Starting with the source package installed.

1. Run configure to generate the DRV file from the templates.
2. Copy the generated file to my testing directory.
3. For each test I do.
4. Make another temporary copy of the file I copied from the source.
5. Run ppdc -t tempfile | grep " FAIL" > fails.orig to get a baseline.
6. Run the script or a modified version of the script.
7. Run ppdc -t tempfile | grep " FAIL" >fails.new

This should ensure that I am testing the in the states before and after the script had modified the file at install time.

The space in front of the FAIL in the grep is to filter out all the individual fails and leave the ones that just contain the printer model name. It should be removed to catch all fails.

Cheers,
Roger

[Roger James (rogerjames99)]

Well I found one problem in the script. But unfortunately it does not fix the problem.

the line

duplexsizes=`grep -v '^//' $f | grep CustomMedia | grep '\.Duplex' | cut -d " " -f 4 | cut -d "/" -f 1 | cut -d '"' -f 2 | perl -p -e "s/\.Duplex//" | sort | uniq`

does not match all of the CustomMedia .Duplex lines in the file. It misses the ones which do no begin with 3 spaces. Some of these have tabs, a mixture of tabs and spaces, or a different number of spaces.

As far as I can see this does not matter as any ones it misses are picked up elsewhere in the file.

I only picked this up using my cut down version of the drv file which was small enough not to have alternative findbale lines.

I will now retry a the tests I did with the cut down file to see if this has caused me to draw bad conclusions.

But I think this needs to fixed anyway for hygienes sake.

This appears to work.

duplexsizes=`grep -v '^//' $f | grep CustomMedia | grep '\.Duplex' | cut -d '"' -f 2 | cut -d '/' -f 1 | perl -p -e "s/\.Duplex//" | sort | uniq`

I don't know if this assumption that all the relevant lines start with 3 spaces affects any of the perl code lower down in the script.

I struggle to read perl !!!

[Till Kamppeter (till-kamppeter)]

I think, the 3 spaces are really not needed, so your line

duplexsizes=`grep -v '^//' $f | grep CustomMedia | grep '\.Duplex' | cut -d '"' -f 2 | cut -d '/' -f 1 | perl -p -e "s/\.Duplex//" | sort | uniq`

is the correcter one.

[Till Kamppeter (till-kamppeter)]

I have tested now and your duplexsizes=... line is the better one, as it catches two extra page sizes (CardA4 and CardLetter) and it does not contain a blank line as the original does.

All in all, it does not fix the original problem, the "Missing choice" and "Multiple occurrences" failures are still there.

[Roger James (rogerjames99)]

The attached script is a work in progress. The CustomMedia stuff is working but the UIConstraints is not.

I have tried to make it as simple and clear as posible but I have more work to do.

[Till Kamppeter (till-kamppeter)]

Thank you for the script.

Looks nice, but what about printers which do not support duplex printing? If the printer had an A4 page size it would be transferred into A4.SM and then there is no A4 entry left at all in the PPD.

[Roger James (rogerjames99)]

Ok. I understand the need for the {0,4} now!

Unfortunately in the 6510 ppd definition in the drv file the .Duplex defintion is 102 lines further down the file.

I will test with a value to compensate for that. But I still think that this is just sticking a bandage on a bandage.

I found a note somewhere on the apple site about setting PageSize and MediaSize constriants which looked interesting (you need to set both). I wonder if we could set up constraints such that selecting a *Duplex option needed a .Duplex paper size. At quick glance though this looks difficult if not impossible.

Roger

[Till Kamppeter (till-kamppeter)]

HP' s original intention was having these variants for each paper size (you get this with the pure upstream code without applying the script):

1. Standard size, like "A4" giving smallest possible non-fullbleed margins. These sizes are the default sizes
2. Duplex sizes, like "A4.Duplex" having larger upper and lower margin to allow for printing suplex with duplex units of HP's inkjet printers. It is required to choose one of these paper sizes to be able to print duplex.
3. Full-bleed sizes, like A4.FB allowing borderless printing. To overcome tolerances in the paper size and printing mechanics some overspray (printing larger than the actual paper) Is done, meaning small image info loss at the borders (but the same happens if photos are printed borderless in a lab).

This was leading to an awkwardness about using duplex, as users had to switch to a .Duplex paper size to be able to print duplex and the CUPS/PPD mechanism did not allow for doing this automatically. So users complained that duplex did not work and I came up with the script, which worked great for many years.

The script changes paper size naming in an automated way:

A4 -> A4.SM (small margins)
A4.Duplex -> A4 (and now this being the standard paper size)

Problem is how to do this automatically, so that there are no patches needed which need to be changed all the time when new printers get added. The script needs to rename the paper sizes and skip printers which do not support duplex and it has to also rename the UIConstraints for duplex, and all that ideally without fully interpreting the .drv file.

This got a challange when HP started having printer series with some non-duplex and duplex printers and making use of nested {} to list the non-duplex paper sizes once for all printers of the series and add the duplex sizes only for the duplex printers. This makes the correct renaming impossible for all the printers of the series.

Perhaps we need to remove the script to return to upstream reality with the original awkwardness (perhaps this could be the SRU for Xenial) and for a more sophisticated solution pre-build all PPDs, edit them with a script to rename the paper sizes, and then either compress the PPDs with pyppd for shipping or look whther CUPS has a tool to reverse-compile PPDs to a .drv file, to generate the new .drv file this way.

WDYT?

[Roger James (rogerjames99)]

On 18/04/16 04:41, Till Kamppeter wrote:
> Perhaps we need to remove the script to return to upstream reality with
> the original awkwardness (perhaps this could be the SRU for Xenial) and
> for a more sophisticated solution pre-build all PPDs, edit them with a
> script to rename the paper sizes, and then either compress the PPDs with
> pyppd for shipping or look whther CUPS has a tool to reverse-compile
> PPDs to a .drv file, to generate the new .drv file this way.
>
> WDYT?
>

Hi Till,

My gut response is remove the script.

However this may bring into play problems with jobs sticking in the
queue for no apparent reason that I mentioned in the original bug post.
This definitely occurs when printing from applications using gtk+ and is
caused by cups not picking up that GS has terminated with an error, in
this case "rangecheck in SetPageDevice. This error is only reported in
the error_log if debug logging is enabled. I think it would be a good
idea to fix this anyway!

I have been looking at a solution using cupsUIConstraint and
cupsUIResolver to forbid the use of non duplex page sizes when duplex
printing is selected and a .duplex page size is available. I have not
got it to work yet.
The idea is to insert lines like these after each .Duplex CustomMedia found.

             Attribute cupsUIContraints A4Pagesize "*Duplex *PageSize A4"
             Attribute cupsUIResolver A4PageSize "*Duplex *PageSize
A4.Duplex"
             Attribute cupsUIContraints A4PageRegion "*Duplex
*PageRegion A4"
             Attribute cupsUIResolver A4PageRegion "*Duplex *PageRegion
A4.Duplex"
             Attribute cupsUIContraints A4ImageableArea "*Duplex
*ImageableArea A4"
             Attribute cupsUIResolver A4ImageableArea "*Duplex
*ImageableArea A4.Duplex"
             Attribute cupsUIContraints A4PaperDimension "*Duplex
*PaperDimension A4"
             Attribute cupsUIResolver A4PaperDimension "*Duplex
*PaperDimension A4.Duplex"

Comments?

Roger

[Roger James (rogerjames99)]

I spelt constraints correctly in the next version and it still does seem to be doing anything.

[Till Kamppeter (till-kamppeter)]

Can you try out whether duplex printing works correctly with no script at all applied, using the original upstream hpcups.drv? Note that you have to choose the A4.Duplex page size for double-sided printing then.

[Roger James (rogerjames99)]

I thought I had posted a reply but i obviously had not.

I had already tried the the test you suggested.

I built a 3.15.7 version the hplip package with the make-duplex-page-sizes-default.sh script disabled and reinstalled with that. The hpcups.drv work fine for duplex printing with A4.duplex selected.

I have also tried printing duplex with the PaperSize set to plain A4. This did not crash with the setPageDevice error as was happening before. Loolking at the logs the PageSize being sent to gs was just A4 not Custom.A4 as before. so something was happening differently I will have to revert to the original installation to check that I was running an identical test, but I am fairly certain I am.

I not sure what the meaning is of these Custom.XXX pagesizes, or what is setting them.

I will have another look at what is happening with cupsUIConstraints stuff over the next few days.

But as far as I am concerned removing the script is good to go.

[Till Kamppeter (till-kamppeter)]

If any program (driver, PPD, ...) generates " Custom.A4" this is totally wrong. It must be either a paper size listed in the PPD, like "A4" or "A4.Duplex" or "Custom" with an explicit size in numbers, like "Custom.10x20cm", or "Custom.8x11in". Also simply "Custom" is wrong.

So one needs to find out what generates "Custom.A4" and to which package this belongs.

A possible SRU for Xenial would be to remove the script which modifies the hpcups.drv file.

[Roger James (rogerjames99)]

I have upgraded to Xenial and I can no longer reproduce the original bug. I can only assume it was something in gtk+ this has been fixed in Xenial. The fact that when it happened the jobs stuck in the queue unless deleted with the only evidence that anything was amiss being the lack of print output and a message in the error log that was only available if debug mode was switched on. Running the xenial printer-driver-hpcups source on my Wily system still showed showed the bug.

I am happy to run a local patched version on Xenial. So as far as I am concerned you can either let this bug time out or mark it as invalid. If anyone wants to raise an SRU it is up to them. That is a learning curve I do not want to experience.

Thanks for your time.

Roger

[Launchpad Janitor (janitor)]

[Expired for hplip (Ubuntu) because there has been no activity for 60 days.]

[Roger James (rogerjames99)]

I am changing the name of this bug and reopening it because the problem with the invalid ppd file still exists.

The make-duplex-page-sizes-default.sh generates causes bad ppd files to be generated for the following printers.

hp-officejet_6800.ppd: FAIL
hp-officejet_pro_6830.ppd: FAIL
hp-photosmart_5510d_series.ppd: FAIL
hp-officejet_pro_6230.ppd: FAIL
hp-photosmart_6510_series.ppd: FAIL
hp-envy_7640_series.ppd: FAIL
hp-officejet_5740_series.ppd: FAIL
hp-envy_5640_series.ppd: FAIL
hp-envy_5660_series.ppd: FAIL
hp-officejet_8040_series.ppd: FAIL
hp-officejet_6700.ppd: FAIL
hp-officejet_pro_3610.ppd: FAIL
hp-photosmart_7520_series.ppd: FAIL
hp-officejet_7610_series.ppd: FAIL
hp-officejet_7110_series.ppd: FAIL
hp-officejet_pro_8500_a909a.ppd: FAIL
hp-officejet_pro_8500_a909g.ppd: FAIL
hp-officejet_pro_8500_a910.ppd: FAIL
hp-photosmart_c309a_series.ppd: FAIL
hp-officejet_pro_3620.ppd: FAIL
hp-photosmart_7510_series.ppd: FAIL
hp-officejet_pro_8500_a909n.ppd: FAIL
hp-officejet_6000_e609n.ppd: FAIL
hp-deskjet_3540_series.ppd: FAIL
hp-photosmart_premium_c309g-m.ppd: FAIL
hp-photosmart_prem-web_c309n-s.ppd: FAIL
hp-officejet_6500_e709n.ppd: FAIL
hp-envy_4500_series.ppd: FAIL
hp-photosmart_prem_c310_series.ppd: FAIL
hp-officejet_6500_e710n-z.ppd: FAIL
hp-deskjet_4510_series.ppd: FAIL
hp-officejet_4630_series.ppd: FAIL
hp-officejet_pro_8000_a809.ppd: FAIL
hp-deskjet_4640_series.ppd: FAIL
hp-photosmart_estn_c510_series.ppd: FAIL
hp-photosmart_prem_c410_series.ppd: FAIL
hp-envy_5530_series.ppd: FAIL
hp-laserjet_professional_p1609dn.ppd: FAIL
hp-laserjet_professional_p1606dn.ppd: FAIL
hp-laserjet_professional_p1607dn.ppd: FAIL
hp-laserjet_professional_p1608dn.ppd: FAIL

[Till Kamppeter (till-kamppeter)]

Fixed in hplip 3.16.7+repack0-1ubuntu1 in Yakkety.