[Desktop_printing] Kicking off the Open Printing Summit

Michael Sweet mike at easysw.com
Sat Jan 7 06:20:57 PST 2006

Robert L Krawitz wrote:
> ...
> There are some issues here:
> 1) The technical criteria to use.  What's acceptable to one person
>    might not be acceptable to someone else; if there's a color
>    problem, it might be fine for most people but not for people who
>    are more finicky.

It might make sense to just indicate the type(s) of color management
the driver supports, e.g. "none", "srgb", "icc", and "custom".

> 2) Auxiliary printer functions.  A lot of printers are multi-function
>    devices, with fax, scanning, and copying built in.  From what I've
>    seen, many users expect that a working printer also implies that
>    the other functions will work, but that's not always the case,
>    since the folks who write printer drivers aren't the same people
>    who do SANE.  Another problem that sometimes happens is that
>    vendors will release specs for the printer but not for the
>    scanner.  I suspect that these devices are produced by two
>    different organizations within the company with different levels of
>    friendliness toward FOSS.

In many cases, the vendor has to rely on a third-party (that provided
the scanner technology, for example) for any documentation/support, and
NDA/IP issues may prevent disclosure as well.

Anyways, again we can break out the print, scan, and fax portions of
the functionality to be "N/A", "Yes", and "No".

>    A related problem is that sometimes there will be some auxiliary
>    printing functionality, such as printing to CD's.  A particular
>    printer might work quite well, with certain functional exceptions.
>    Whatever scheme used needs to factor that in.  The same kind of
>    issue, of course, exists for roll paper, manual feed (to enable
>    printing to boards that cannot bend, for example), and so forth.

For a certification process we should require full functionality
at least for printing.

> 3) Paper and ink types.  Vendors generally want to see their inks and
>    papers supported, and generally don't much want to see third party
>    supplies supported.  I suppose vendors don't care too much about
>    specialized third party supplies such as premium inks and papers
>    (which cost more than the OEM supplies and have very limited
>    markets), but there can be a lot of controversy over cheap third
>    party inks and refilling.  I'm not going to get into the technical
>    merits or demerits here, but there could be some issues here in
>    certification.

Here I see two options: a vendor supplies an open source driver and
list third-party stuff, or they supply a closed-source driver and
do not list third-party stuff.

(and yes, I think we need to allow for closed-source drivers)

> I'd personally really hate to see distributions (and architectures,
> for that matter) thrown into the mix.  That's going to contribute to
> fragmentation of the Linux community.  It's also going to get too
> complicated for end users, especially with installable drivers and
> driver updates (for example, we were very successful in releasing
> updates to Gimp-Print 4.2 that added new drivers).

I agree - the whole driver certification/availability issue should
be separate from Linux distributions, aside from requiring LSB
conformance on Linux.


Here is an off-the-cuff self-certification form for printer vendors:

         Manufacturer: _____________

           Model Name: _____________

           Driver URL: _____________

          Driver Type: __ PostScript  __ CUPS Raster  __ IJS

       Driver License: __ Open Source  __ Closed Source
                       (certified drivers must allow unlimited

         CUPS Version: __ CUPS 1.1 and higher
                       __ CUPS 1.1.19 and higher
                       __ CUPS 1.2 and higher

     Color Management: __ sRGB  __ ICC  __ Custom
                       (check all that apply)

             Scanning: __ Yes  __ No  __ Not Applicable

               Faxing: __ Yes  __ No  __ Not Applicable

    Operating Systems: __ FreeBSD INTEL (5 and higher)
                       __ Linux IA32 (LSB conformance required)
                       __ Linux IA64 (LSB conformance required)
                       __ Linux AMD64 (LSB conformance required)
                       __ Linux PPC (LSB conformance required)
                       __ Linux SPARC (LSB conformance required)
                       __ Linux S/390 (LSB conformance required)
                       __ MacOS X PPC (10.3 and higher)
                       __ MacOS X Intel (10.3 and higher)
                       __ Solaris SPARC (7 and higher)
                       __ Solaris INTEL (7 and higher)
                       __ Other: ________________

            Languages: __ English (required)
                       __ French
                       __ German
                       __ Italian
                       __ Japanese
                       __ Spanish
                       __ Other: ________________

                 PPDs: __ Yes  __ No

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

More information about the Printing-summit mailing list