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

[Michael Sweet]

Till Kamppeter wrote:
> ...
>>> 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...
>>
> 
> This is a great feature, especially if it could get binaries fitting to 
> the system actually used.

You can get the dependency information from the cups.org database
(e.g. "requires rastertopclx"), which can then map to a distro-
specific driver downloader/installer.  Our hope is that the majority
of the PPD files will use standard filters - this is certainly
possible for ESC/P, PCL, and PostScript devices, and for some label
printers that are already supported by CUPS.

>>> 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.
>>
> 
> If the drivers support the specialties of modern printers and take care 
> of the differences between different models.

Yes, they are entirely data-driven - see the CUPS DDK documentation
to get an idea of what is supported.

> ...
>> Yeah, and most vendors will not provide information for open-source
>> drivers...
>>
> 
> This is a big problem.

It is and it isn't.  There are enough "open" printers that it isn't a
serious problem right now, but it is a pain for "converters" with
existing printers that are not compatible with Linux.

I think with continued education/evangelism about Linux and CUPS, we'll
be able to get support from the vendors for open source drivers.
Certainly this is the case for Epson, who has made remarkable changes
over the last 5 years.  I'm hoping that Canon and Lexmark will start
opening up more (in particular, Canon Europe is more open than Canon
USA or Canon Japan...)

HP is a bit of an enigma - they won't provide documentation for
everything, but then they go and provide a sample implementation
for you to work with... :)

>>> 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.
>>
> 
> Is this the vector driver API of the japanese OpenPrinting subgroup?

Yes.

>>> o i18n in ppd files - covered in cups 1.2
> 
> That's important.
> 
>>> 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...)
>>
> 
> With this I meant mainly the inkjets, we had a already a Dell laser here 
> at Mandriva, it simply worked.
> 
> 
>>> 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.
>>
> 
> With a native CUPS driver it will even integrate better.

Yes, and the performance improvement is dramatic.

> ...
> It is a bad hardware architecture to make two printers of the same model 
> undistinguishable for the computer. They would also have their problems 
> under Windows.

The "solution" for both Windows and OSX is to assign a virtual serial
number based on the assigned port - I'm still trying to figure out a
reliable way to do that on Linux and Solaris...

> ...
>> Go to "http://localhost:631/help" on a system with CUPS 1.2
>> installed... :)
>>
> 
> Still did not find anything useful. The subscriptions.conf help file 
> seems not to be filled in yet (snapshot of before the Portland meeting).

http://localhost/help/api-filter.html

We're still filling in and updating the help content, and
subscriptions.conf is low on the list right now (normally not
edited by mortals... :)

> ...
> Also great, especially for MF devices not needing to be configured 
> separately for network printing and scanning (like currently with CUPS 
> and SANE). But do not try to replace SANE completely, it will be a mess 
> for users to have to do different frontends for MF device scanners and 
> standalone scanners.

Definitely not - the idea would be to provide the new network access
protocol which would use the SANE stuff under the covers.  This
would also lead (hopefully) to easier setup/support, as right now
SANE configuration is a major pain.

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