Why require static "hpijs" PPDs foomatic-rip-hplip?

Hi Johannes,

> New question #25654 on HPLIP:
> https://answers.launchpad.net/hplip/+question/25654
>
> TheHPLIP 2.8.2 release notes describe that
> "Foomatic-rip-hplip is for distros that do not have the
> latest foomatic-rip
> which is required for drv support."
>
> On the other hand this could mean that foomatic-rip-hplip
> is not required if no drv stuff (i.e. dynamic PPD stuff) is
> to be done.
>
> But all static "hpijs" PPDs require foomatic-rip-hplip
> via their "*cupsFilter:" line and consequently one cannot use
> --enable-foomatic-ppd-install and --disable-foomatic-rip-hplip-install
> to make HPLIP 2.8.2 in a traditional way (provide readymade PPDs
> and rely on the foomatic-rip of the installed system).
>
> I do not understand why the static "hpijs" PPDs require
> foomatic-rip-hplip.
>
> Why are the static "hpijs" PPDs not backward compatible
> to older foomatic-rip?
>
> Could you explain the reason behind?

The static PPDs distributed with HPLIP 2.8.2 were generated from the hpijs.drv file using the CUPSDDK's ppdc compiler. We no longer generate HPLIP PPDs from the foomatic database. Unfortunately drv generated PPDs are only compatible with the latest version of the foomatic-rip. Till made some changes to foomatic-rip in order to support the CUPSDDK. Since the static PPDs included in the tar ball are not compatible with older versions of foomatic-rip, we included a copy of the latest foomatic-rip called foomatic-rip-hplip.

I built foomatic-rip-hplip from foomatic-filters-3.0-current.tar.gz dated 1/23/2008.

In the interest of keeping the tar ball small we choose to include static PPDs for the foomatic-rip-hplip filter only. Most new distros use dynamic ppd configuration so this decision does not effect them. For older distros you will want to install foomatic-rip-hplip. For new distros that want the static PPDs based on foomatic-rip, see the following static ppd configuration suggestions.

For dynamic ppd configuration you must use the foomatic-rip-hplip or use the latest foomatic-rip from linuxprinting.org.

  --enable-foomatic-drv-install
  --enable-foomatic-rip-hplip-install

or

  --enable-foomatic-drv-install
  --disable-foomatic-rip-hplip-install

For static ppd configuration you have three options.

   1. Install foomatic-rip-hplip and the static PPDs from the tar ball.

      --disable-foomatic-drv-install
      --enable-foomatic-ppd-install
      --enable-foomatic-rip-hplip-install

   2. Install without foomatic-rip-hplip and modify the static PPDs to call foomatic-rip instead of foomatic-rip-hplip.

      --disable-foomatic-drv-install
      --enable-foomatic-ppd-install
      --disable-foomatic-rip-hplip-install

      For all PPDs change *cupsFilter line from foomatic-rip-hpijs to foomatic-rip then "make", "make install".

   3. Install without foomatic-rip-hplip and create new static ppd files using ppdc.

      --disable-foomatic-drv-install
      --enable-foomatic-ppd-install
      --disable-foomatic-rip-hplip-install

      Run "ppdc prnt/drv/hpijs.drv" then "make", "make install".

> By the way:
>
> Your "Technical Documentation: Portablity Reference" reads that
> "CUPS drv support provides more PPD options,
> faster PPD file generation,"
>
> Could you give some examples which PPD options require
> dynamic PPD generation (i.e. which cannot be provided
> in a readymade PPD file)?
>
> Finally I like to disagree a bit that a dynamically generated PPD
> is faster available than a readymade PPD file on the disk ;-)

Ok what I really mean with the "faster PPD file generation" statement is that drv generated PPDs are much faster than foomatic generated PPDs. In fact a drv generated PPD is so fast I would expect most users would think it was a static PPD :)

I highly recommend dynamic PPD configuration over static because the PPD footprint is much smaller and it simplifies PPD file management. Some distros put all the PPDs in one package (ie: foomatic-ppd) which makes it harder to update PPDs for a single manufacturer. Some distros put the PPDs in two packages (ie: foomatic-ppd and hplip) which can result in multiple PPD copies.

With dynamic PPD configuration, a package manager can keep the hplip.drv file with the HPLIP package which should simplify package updates.

-dave

Very many thanks for the explanation!

I am always very interested how I could provide
the newest HPLIP even for older systems in particular
Suse Linux Enterprise Server/Desktop 10 which is based
on Suse Linux 10.1 with CUPS 1.1 and old foomatic-rip
so that we (i.e. HP and Novell/Suse) could make
even big business customers happy
(those customers who mainly pay my salary ;-)

I like to suggest to enhance your
"Technical Documentation: Portablity Reference"
in particular regarding all three options for static ppd configuration.

In particular what you wrote in option 2. is interesting because
it means that during runtime no foomatic-rip-hplip is required
because it seems your static PPDs from the tar ball work even
with older foomatic-rip but on the other hand you wrote that
"drv generated PPDs are only compatible with the latest version
of the foomatic-rip"?

To be on the safe side I use now option 1 for my packages at
http://download.opensuse.org/repositories/home:/jsmeix/

Regarding dynamic PPD generation:

The drawback is that the driver which generates the PPDs
does not have unlimited time to finish. As far as I know there is
some timeout until it must be finished. There have been problems
at least in a certain CUPS version when the foomatic driver
in /usr/lib/cups/driver/ was too slow to geenerate all its PPDs
so that many or all its PPDs were not recognized by CUPS
because of the timeout.

The main advantage of dynamic PPD generation is that the driver
can query the actually connected printer device regarding
installed options (e.g. duplexer, finisher, installed memory, ...)
and generate an exactly matching PPD (e.g. leave out options
which are not supported by the actual device hardware).
If the driver fails to query the device (e.g. because it is currently
switched off or there is a timeout), it would spit out a fallback PPD
which is the static PPD.

The main advantage of readymade installed PPD files is that
there is less stuff which is involved.
It works more reliable and predictable.
The latter is important to provide good customer support.
I.e. the PPD file which is installed on the machine of our
support department is exactly the same as what is installed
on the customer's machine.
Think about possible customer questions how to enable
a special finisher after a finisher unit was added later
but the dynamic PPD was generated before without
options for the special finisher unit.