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

[Till Kamppeter]

Michael Sweet wrote:
> [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...  :(
> 

Also on linuxprinting.org we have manufacturer-supplied PPD and I had 
sometimes to ask the vendors to correct the PPDs to pass cupstestppd.

>> 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.
> 

Perhaps standardize on a way for having general string and password 
options is the more flexible solution.

>> 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...
> 

This is a great feature, especially if it could get binaries fitting to 
the system actually used.

>> 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.

>> o proprietary protocols require cooperation from the manufacturer
> 
> 
> Yeah, and most vendors will not provide information for open-source
> drivers...
> 

This is a big problem.

>> 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?

>> 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.

>> 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.
>

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.

>> 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...
> 

Many new features are also interesting for desktop users, like the 
backchannel to get decent error messages, the easier setup of local 
printers with the web interface, the possibility to not letting queues 
being disabled when the printer is turned off, ...

>> 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... :)
>

Still did not find anything useful. The subscriptions.conf help file 
seems not to be filled in yet (snapshot of before the Portland meeting).


>> 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...)
> 

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.

    Till