Mixed up LaserJet 6P (PCL) and 6MP (PostScript) in two same PPDs

[Johannes Meixner]

HPLIP 3.9.8 contains two identical PPDs
hp-laserjet_6mp-ps.ppd and hp-laserjet_6p-ps.ppd for
"HP LaserJet 6P/6MP - PostScript Postscript"

But according to
https://bugzilla.novell.com/show_bug.cgi?id=556310
there is a difference:
HP LaserJet 6P does not understand PostScript
HP LaserJet 6MP understands PostScript

Therefore there cannot be one PPD for both models
(and two same PPDs does not make sense at all).

I suugest to remove hp-laserjet_6p-ps.ppd from HPLIP
and change hp-laserjet_6mp-ps.ppd so that this one
is only for a HP LaserJet 6MP.

[Stanislav Brabec (sbrabec-suse)]

There is a result of PostScript detection:

<ESC>%-12345X@PJL INFO VARIABLES

Then check section PERSONALITY.

This is a reply from 6P:

PERSONALITY=AUTO [2 ENUMERATED]
 AUTO
 PCL

This is a reply from PostScript capable printer:

PERSONALITY=AUTO [3 ENUMERATED]
        AUTO
        PCL
        POSTSCRIPT

[Till Kamppeter (till-kamppeter)]

There are very many duplicate PPDs in HPLIP. See bug 493282.

Duplicate PPDs do not only waste space, but they also produce duplicate entries in the driver lists of printer setup tools. See the first two entries in the driver list in the screenshot attached to the SUSE/Novell bug report (https://bugzillafiles.novell.org/attachment.cgi?id=328291). This irritates uses and makes them think that there are perhaps differences between the two entries.

The correct fix is deleting all duplicates and NOT replacing them by symlinks. CUPS determines the supported printer models and drivers only by make, model, and nickname fields in the PPD, not by the PPD's file name. So there will be no more supported printer models listed by CUPS if PPDs are provided under more different file names.

In addition, if there are two flavors of a certain printer, one coming with PostScript module and one without (and having the possibility to buy the PostScript module later), the version without should not have PostScript as driver in its driver list, so that the printer simply works out of the box.

[Johannes Meixner (jsmeix)]

Regarding printers with an optional PostScript module:

Two different PPDs are needed,
one for the printer without the PostScript module
(usually a PPD for a PCL driver) and
one for the printer with the PostScript module.

I assume the problem is that usually both flavors of
such a printer show up at the USB or at the parallel port
as exactly the same model so that the usual generic
printer autodetection cannot distinguish them.

Stanislav Brabec, FYI:
What you described in your above comment #1
https://bugs.launchpad.net/hplip/+bug/485218/comments/1
is not done by generic printer autodetection.

When both flavors of such a printer are indistinguishable
by generic printer autodetection, the "recommended" PPD
must be the one which works without the PostScript module
to make sure that both flavors of such a printer work
out of the box.

To the HPLIP developers:

When both flavors of such a printer are indistinguishable
by generic CUPS printer autodetection, HPLIP's "hp" backend
may nevertheless try to do whatever additional more
sophisticated autodetection stuff (e.g. something like
what Stanislav Brabec described above) but it should
fall back to generic autodetection it the sophisticated
autodetection fails.

This way the "hp" backend could output different model names
for the two flavors of the printer.
Then each PPD which matches exactly to a particular flavour
must contain exactly the special name from the "hp" backend.
In the end a perfect automated setup via the "hp" backend
would be possible in a way which is still in full compliance
to CUPS (as far as I see currently).

Probably *ModelName and *NickName in both PPDs
should still contain the usual name but *1284DeviceID
contains the special name from the "hp" backend?
But currently I feel uncertain if this is really the best way
how to implement it.

But perhaps the root problem is that the PostScript PPDs
in HPLIP are not under the control of the HPLIP developers
because from HPLIP's point of view the PostScript PPDs
might be only a "third-party addon" (from somewhere at HP)
which is just bundled "as is"?

packaged "as is"

[Stanislav Brabec (sbrabec-suse)]

Is it possible to compare printer driver backend language and the answer of the printer using PJL query and then offer only models that match? There was (is) more printers with optional PostScript slot.

[Johannes Meixner (jsmeix)]

CUPS backends spit out autodetection information
in the form which is described in "man 7 backend".

To find matching PPDs, the "device-make-and-model"
in the backend's output should match to
the "*ModelName" and "*NickName" entries in the PPD
and the optional "device-id" in the backend's output
should match to the optional "*1284DeviceID" entry
in the PPD.

As far as I know any other magic is not in compliance
to how CUPS works.

I.e. any other magic to find matching PPDs can only work
for those special printer setup tools which know about the
magic (e.g. only HPLIP's "hp-setup" may find the actually
right PPD while all other printer setup tools fail).

The hp backend could try to do PJL queries
or whatever it likes to find out the exact model
(and have a fallback if this does not work)
and spit out autodetection information accordingly
so that only the exact right PPDs which are provided
by HPLIP match exactly.

E.g. when PJL query works, it may spit out
"HP LaserJet 6P" or "HP LaserJet 6MP"
depending on the exact model and use
e.g. "HP LaserJet 6 series" as fallback
or something like this (I don't know about the
exact details and versions of those models).