Bug 471243

Already reported upstream:
https://bugs.launchpad.net/hplip/+bug/235148

Currently (i.e. in HPLIP 2.8.7) the PPD is probably
"HP Deskjet 6500 Foomatic/hpijs, hpijs 2.8.7.3"

In YaST you would have to enter for example
"deskjet 65"
and then click [Show matching drivers] to get this PPD.
See also bug #468046

*** This bug has been marked as a duplicate of bug 468046 ***

The HPIJS PPD nickname (and file name) are generated from the device-id. If the HP Deskjet 6500 has no "series" in the device-id there will be no "series" in the nickname field.

Note that all case parts or models *are* listed in the PPD "*Product" field. This means that one PPD can support multiple products. For the Deskjet 6500 PPD there are 10 *product entries and the 6540 is one of them.

Hello David!
I appreciate it very much that you have a look at
our bug report!

hp-deskjet_6500-hpijs.ppd contains
-----------------------------------------------------
*Product: "HP Deskjet 6520"
*Product: "HP Deskjet 6500"
*Product: "HP Deskjet 6520xi"
*Product: "HP Deskjet 6540"
*Product: "HP Deskjet 6540d"
*Product: "HP Deskjet 6540xi"
*Product: "HP Deskjet 6543"
*Product: "HP Deskjet 6543d"
*Product: "HP Deskjet 6548"
*Product: "HP Deskjet 6540dt"
...
*NickName: "HP Deskjet 6500 Foomatic/hpijs, hpijs 2.8.7.3"
...
*1284DeviceID: "MFG:HP;MDL:deskjet_6500;DES:deskjet_6500;"
*Product: "HP Deskjet 6520"
*Product: "HP Deskjet 6500"
*Product: "HP Deskjet 6520xi"
*Product: "HP Deskjet 6540"
*Product: "HP Deskjet 6540d"
*Product: "HP Deskjet 6540xi"
*Product: "HP Deskjet 6543"
*Product: "HP Deskjet 6543d"
*Product: "HP Deskjet 6548"
*Product: "HP Deskjet 6540dt"
-----------------------------------------------------


a)
The Product lines are duplicated therein.
This is another bug in the PPD (I think I remember that there
is already a bug report on https://bugs.launchpad.net/hplip/).


b)
When the NickName contains a string which the printer
actually reports via USB then YaST will find the PPD
because YaST uses the autodetected model string
(what "lpinfo -l -v" reports as "make-and-model")
to search PPDs where the NickName contains this string.

I.e. when a HP DeskJet 6540 shows up at the USB
as "HP DeskJet 6500", YaST will find the PPD
(regardless if there would be an addendum "series").
Therefore I guess (unfortunately the initial reporter
did not provide sufficient information) that a
"HP DeskJet 6540" does not show up at the USB
as "HP DeskJet 6500" but somehow different.

To verify it (I don't have a HP DeskJet 6540),
I use a "fake" backend /usr/lib/cups/backend/fake
-----------------------------------------------------------------------
#! /bin/bash
# output "Device Discovery" information on stdout
if test "$#" = "0"
then
  echo 'direct fake:/dev/null "HP DeskJet 6500" "HP DeskJet 6500 fake"'
fi
exit 0
-----------------------------------------------------------------------
which results in "lpinfo -l -v" the output
-----------------------------------------------------------------------
Device: uri = fake:/dev/null
        class = direct
        info = HP DeskJet 6500 fake
        make-and-model = HP DeskJet 6500
        device-id = 
-----------------------------------------------------------------------
and now YaST finds the PPD hp-deskjet_6500-hpijs.ppd

I cannot inspect the PPD files directly (and search therein
e.g. for Product entries) because inspecting PPD files directly
is no longer in compliance how CUPS works.
The reason is that since CUPS 1.2 PPD info can be generated
on the fly by so called "drivers" in /usr/lib/cups/driver/.
In this case there are no PPD files on the disc
which a printer setup tool could inspect directly.
Therefore all a printer setup tool can do is to work
only with the values which it gets from CUPS.
It is CUPS and only CUPS which already has the information
and which knwos how to get it correctly for the currently
running CUPS version in the particular user's environment
(depending on the particular user environment a so called
"driver" may spit out this or that PPD info - e.g. based
on the actually connected particular printer model).


c)
Regarding multiple Product entries, see
https://bugs.launchpad.net/hplip/+bug/235148/comments/3
In short:
This doesn't work (at least not up to CUPS 1.3).

According to the PPD spec multiple Product entries are
explicitely allowed but it is not the issue here
whether or not multiple Product entries are a bug.

The issue here is that HPLIP PPDs do not show it to the user
when one PPD is valid for more than one model.

The general problem is:
What is the right way to have one PPD for several models
in compliance to CUPS and to the PPD specification?
Perhaps the HPLP team may have to ask on cups@easysw.com
how to do it with the CUPS Driver Development Kit?

Perhaps multiple 1284DeviceID entries could also work?
At least I know about a few PPDs (for Kyocera printers)
with two 1284DeviceID entries, e.g.:
-----------------------------------------------------------------
*1284DeviceID: "MDL:FS-8000C;MFG:Kyocera"
*1284DeviceID: "MFG:Kyocera Mita;Model:Kyocera Mita FS-8000C;COM
MAND SET: POSTSCRIPT,PJL,PCL"
-----------------------------------------------------------------
but I don't know if this is perhaps a bug in those PPD?

In the end - as far as I understand the PPD spec - only
the NickName can be used because only this one is shown
to the user (but neither Product nor ModelName),
see the PPD spec regarding NickName
"It is used primarily at the user interface level
 when selecting a device..."
and compare the PPD spec regarding ModelName and Product.

Unfortunately the PPD spec does not allow more than
one NickName because it reads:
"There may be only one *NickName in a PPD file.
 If the PPD file is valid for more than one product,
 that fact must be reflected in the *NickName value
 as in *ModelName."
The PPD spec provides an example for a ModelName
in a PPD which is valid for more than one product:
 *ModelName: "ACME FunPrinter or NiftyPrinter"

Therefore according to the PPD spec you must provide
a NickName value which indicates that a PPD is for
more than one model for example as I described
https://bugs.launchpad.net/hplip/+bug/235148/comments/3

Hi Johannes :)

Good point about multiple *product fields. CUPS does not expose that with "lpinfo -m".

The real question is what is the device-id or USB enumeration for the customer's Deskjet 6540? If it is not Deskjet 6500 then we need to update our models.dat file.

For USB the exact model name can be determined with "lsusb -v -sbus:dev".

Michael Werner,
as root run first
  lsusb
and note the bus and device number of your DeskJet, then run
  lsusb -v -sbus:dev >/tmp/lsusb.dj6540
where bus is the bus number and dev the device number.
Finally attach /tmp/lsusb.dj6540 as MIME type "text/plain" to this bug.

Michael Werner,
as root run
  /usr/lib*/cups/backend/usb
and
  /usr/lib*/cups/backend/hp
and post the output here.


David,
in an older y2log file which I got via the older bug
https://bugzilla.novell.com/show_bug.cgi?id=392107#c4
which is for openSUSE 11.0 (where we had CUPS 1.2) I found:
-----------------------------------------------------------------
Probed printers: ... "modules":[["usblp" ... "model":"6540"
"sub_device":"Deskjet 6500", "sub_vendor":"HP" ... "vendor":"HP"
...
USB backend for device /dev/usb/lp0 detected 
["//HP/Deskjet%206500?serial=MY47F2R23M040N", "HP Deskjet 6500"]
...
"uri":"usb://HP/Deskjet%206500?serial=MY47F2R23M040N"
-----------------------------------------------------------------
so that at least the generic CUPS backend "usb" in CUPS 1.2
did detect such a printer as "HP Deskjet 6500".

But I don't have any information how the "hp" backend
would detect such a model.

The new YaST printer module since openSUSE 11.1, see
http://en.opensuse.org/YaST/Development/Printer_Enhancement
prefers the "hp" backend (the "usb" bakend is still
available in YaST via the [More Connections] button)
so that the crucial question is what the "hp" backend reports.