[Printing-architecture] Problem related to automatic driver download

[Printing-architecture] Problem related to automatic driver download

[George Liu]

While downloading a PPD file or a driver package from openprinting.org,
user can see the requirement or instructions from printer/driver
information page. 

It will introduce confusion if a downloaded PPD/driver does not work on
user's Linux box.

Scenario 1: 
Printer has Postscript as option. CUPS downloaded Postscript drivers
automatically without informing user Postscript option needs to be
installed on the printer. 


Scenario 2:
User installed CUPS 1.3 (which supports auto PPD/driver download) on Red
Hat Enterprise Server 4. CUPS downloaded an GS-opvp driver, but GS/opvp
is not supported on the Linux box. 


Here's my suggestions on how these problems can be addressed:

1. Make a PPD extension "*DriverInformation: ". It can state either
"Recommended" or whatever deems fit. E.g.
*DriverInformation: "Recommended"
*DriverInformation: "Printer needs to have Postscript Option Installed"
Printer setup utility or CUPS web UI need to display it to user.
 

2. Make another PPD extension and list all the required components. E.g.
*DriverDependencies: foomatic-rip	3.43
*DriverDependencies: gs       8.15    
*DriverDependencies: LSB	3.1
Distribution can use which command/or whatever they chose to determine
whether the required components exist.

WDYT?


-----Original Message-----
From: printing-architecture-bounces@lists.freestandards.org
[mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf
Of Till Kamppeter
Sent: Wednesday, April 04, 2007 3:41 AM
To: printing-architecture@lists.freestandards.org
Subject: [Printing-architecture] Status of distribution-independent
driverpackages/LSB DDK

Hi,

here is an update on the distribution-independent driver packages and 
the LSB DDK.

As I probably already reported on earlier telecons the API for querying 
driver packages and related driver info is up and running:

http://www.linux-foundation.org/en/OpenPrinting/Database/Query

To be able to create and test distribution-independent driver packages 
the LSB DDK is needed. It consists of the following components:

- LSB Build Environment (supplied by LSB, for current work version 3.1.1
   is used)
- CUPS (created a distribution-independent CUPS 1.2.10 package, which
   installs in LSB Build Environment - DONE)
- GhostScript (created a distribution-independent ESP GhostScript 8.15.4
   package, which installs in LSB Build Environment - DONE)
- foomatic-filters (TO DO)
- RPM macro set for maintainer scripts. Due to several missing
   facilities in the LSB which are needed to easily implement system
   tool/component packages the maintainer scripts (pre/post (un)install
   scripts) get very awkward. To make it easy for driver authors and
   printer manufacturers to supply correct maintainer scripts in their
   packages I plan to create appropriate RPM macros. I also reported on
   the lsb-discuss mailing list that system config features are missing
   in the LSB.

In addition, a little change is needed in the printing requirements of 
the LSB 3.2:

Distribution maintainers (Red Hat, Ubuntu) complained about that the 
CUPS package requires directories in and links into /opt and /usr/local.

Therefore I decided to let all distribution-independent driver packages 
work as follows:

- Install all files into /opt/<supplier> according to FHS requirements 
for applications.

- Let the PPD directory of the driver package get symlinked into 
/usr/share/ppd by the packages maintainer scripts

- Let the maintainer script also do additional tasks like symlinking 
CUPS backends into the appropriate directories and add directories with 
printer maintenance tools (ink levels, nozzle cleaning, ...) to the
path.

The directory requirements for LSB 3.2 reduce then to have

/usr/share/ppd/<supplier>

as PPD search directory.

Example for a distribution-independent driver package:

http://openprinting.org/show_driver.cgi?driver=gutenprint

Examples for the awkward maintainer scripts:

http://www.linuxprinting.org/download/printdriver/SPECS/cups.spec
http://www.linuxprinting.org/download/printdriver/SPECS/ghostscript.spec
http://www.linuxprinting.org/download/printdriver/SPECS/gutenprint.spec

    Till

_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.freestandards.org
http://lists.freestandards.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Problem related to automatic driver download

[Till Kamppeter]

George Liu wrote:
> While downloading a PPD file or a driver package from openprinting.org,
> user can see the requirement or instructions from printer/driver
> information page. 
> 
> It will introduce confusion if a downloaded PPD/driver does not work on
> user's Linux box.
> 
> Scenario 1: 
> Printer has Postscript as option. CUPS downloaded Postscript drivers
> automatically without informing user Postscript option needs to be
> installed on the printer. 
> 
> 
> Scenario 2:
> User installed CUPS 1.3 (which supports auto PPD/driver download) on Red
> Hat Enterprise Server 4. CUPS downloaded an GS-opvp driver, but GS/opvp
> is not supported on the Linux box. 
> 
> 
> Here's my suggestions on how these problems can be addressed:
> 
> 1. Make a PPD extension "*DriverInformation: ". It can state either
> "Recommended" or whatever deems fit. E.g.
> *DriverInformation: "Recommended"
> *DriverInformation: "Printer needs to have Postscript Option Installed"
> Printer setup utility or CUPS web UI need to display it to user.
>

A field for warning messages is also a nice feature. So special cases 
which cannot be auto-detected can get covered,

The case of having the PostScript option installed can perhaps even be 
auto-detected, for example on some printer models "PS" or "PS3" gets 
added to the "CMD" field of the IEEE-1284 device ID.

> 
> 2. Make another PPD extension and list all the required components. E.g.
> *DriverDependencies: foomatic-rip	3.43
> *DriverDependencies: gs       8.15    
> *DriverDependencies: LSB	3.1
> Distribution can use which command/or whatever they chose to determine
> whether the required components exist.
> 
> WDYT?

I think this is a good idea, especially as in the future it can easily 
happen that driver packages for different LSB versions can be on the server.

 From LSB 3.2 on a certain version of GhostScript is already there due 
to the LSB 3.2, same for foomatic-rip, so the dependencies need only to 
be mentioned explicitly if the driver really needs special versions. 
With all fully LSB-compliant driver packages it is enough to only put 
the LSB dependency.

    Till