[Desktop_architects] raw notes from drivers 12/01/2005 meeting

Michael Sweet mike at easysw.com
Fri Dec 2 14:25:16 PST 2005


[Commenting on Printing notes - thanks for providing them!]

Christopher Blizzard wrote:
> ...
> Printing
> 
> o good thing is that there's a lot of postscript printers - come with a
> ppd so they work well
> o ppd files - some manufacturers release as open source

We have been working with some vendors to get the plain PPD files up
on cups.org.  Progress is slow as there are many legal layers to sift
through and most vendors do not have PPD files that pass the
cupstestppd checks right now...  :(

> o would be nice if everyone did so so the printers worked out of the box
> o sometimes the ppd files need some specialization
> o passwords in ppd files? rico as an example - linux specific

I'm hoping some of the upcoming CUPS custom option stuff will solve
this problem, but we could also standardize on an attribute in the
PPD file to indicate that PINs are supported (and how many digits)
so that we can inject the right PJL or PostScript commands.

> o secure printing

This can be a tough one, since the "last meter" is typically not
encrypted.  System-to-system is already supported...

> o easy download for additional drivers

The original CUPS slides talked a bit about this; in short, the
new CUPS 1.2 driver interface can enumerate and download drivers
from a network repo automagically...

> o non-postscript printers? need a special driver for a specific driver
> o PCL only needs a little work to implement?

In most cases, yes.  We'd *really* like to see the Linux distros
distribute the CUPS DDK drivers, which support all known PCL and
most ESC/P devices.  The 1.1 release of the DDK will add support
for the older ESC/P impact printers and the newer 8-color ESC/P2
inkjets.

> o proprietary protocols require cooperation from the manufacturer

Yeah, and most vendors will not provide information for open-source
drivers...

> o ijs interface?  ghostscript drivers?  vector drivers don't have an
> interface yet

For raster drivers, vendors should be using the CUPS raster format
and interface - it works on Linux and OSX and has better raster
support than IJS.

The Epson and Canon ESP Ghostscript developers have been working on a
promising vector interface and have funding from the Japanese gov't
to develop an extensible vector interface for ESP Ghostscript and
Xpdf.  Last I heard they had the Xpdf prototype working and had
started on the Ghostscript stuff.

> o i18n in ppd files - covered in cups 1.2
> o 70% of the market has drivers available based on market share?

The main issue is the quality of the drivers; the PS drivers are
very good, the non-PS drivers vary considerably...

> o dell is labeling printer from other brand - usually a lexmark and
> that's bad

Bad for the inkjet and MFC devices, but the laser devices are
generally PS and/or PCL now (I have a 3100cn here in my lab and
it works great...)

> o HP is the best

Agreed.  I'm going to be providing HP with a native CUPS filter for
the HP ILP printer drivers, and working with them to use the DDK's
PPD compiler to provide even better drivers for the non-PS printers.

> o PPD files don't support enough for authentication?  for adobe?

Custom option values are the issue; CUPS 1.2 is extending things
to support the same "CustomFoo" and "ParamFoo" attributes that
Adobe uses for PageSize, so that may be enough.  Also, see my
other comment about standardizing a PIN attribute/option for
CUPS to pass in the print data...

>   o PPD files aren't extensible enough?

There are some valid issues extensibility issues, however some
driver writers want to offer things that don't make sense (direct
input of color LUTs, for example) for typical users and would
require special software to use, anyways...

> o Who is involved? Adobe owns the spec

ESP/CUPS and Apple are taking the lead on further developing PPD
for CUPS.

> o PPD drives features? Needs followup - needs to characterize the
> problem because it's not clear here

Agreed!

> o detection
> o USB vendor and product ID is bad because epson is always the same
> answer
> o have to use the IEEE 1284 device ID string can get from the printer
> with an I/O ctl

CUPS already does this, but note that not all vendors provide a
serial number so connecting more than one device of the same model
is often problematic.

> o backchannel from the printer to cups and back to the user is missing
> entirely
> o mike sweet has promised this for cups 1.2!

It is in the 1.2 snapshots on cups.org...

> o cups is for enterprise development, not desktop-driven. missing
> features

Need specifics on this - I'm pretty sure we are addressing the
major issues in 1.2...

> o once a week developer releases - in mandriva
> o back channel is not documented?  not sure if it's there

Go to "http://localhost:631/help" on a system with CUPS 1.2
installed... :)

> o simple apis should not be used by the desktop? use more complex apis?

CUPS 1.1.21 added the necessary bits to safely use the simple APIs
(look for the "2" versions)

CUPS 1.2 adds thread-safety, too!

> Scanner / Fax

Just one comment for this - there is/was some work within the PWG
to support scanning from MFDs using an IPP-based protocol that may
eventuallly see the light of day, possibly leading to a CUPS-based
or CUPS-like network framework for scanning/copying/faxing.  I don't
know the current status of the work, but it is worth tracking down
(I'll see if I can dig up some links...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com



More information about the Desktop_architects mailing list