[printing-discuss] Re: [Inkjet-list] Device capabilities?

Michael Sweet mike at easysw.com
Thu Apr 4 05:22:27 PST 2002


luke.kendall at cisra.canon.com.au wrote:
> ...
>> Yes, however that kind of printing doesn't scale (think spooling
>> 720+ DPI image data for every page, or even print data)...
> 
> 
> Eh?  The rendering has to be done at some stage.  I assume you mean,
> you want that rendering to be done as close to the printer as possible,
> (and preferably rendered in bands), to minimise network traffic and
> memory use.

And disk use; imagine spooling 200+MB *for each page* onto disk.  A 100
page document would fill most user's disks.

> ...
>> Well, assuming that it is even possible to get such information
>> (when looking at the "big" picture, most commercial UNIX's don't
>> have the device support needed for bidirectional communications
>> over the parallel port, and don't support USB, etc.),
> 
> 
> I looked at Solaris 8 about 6 months ago; it seems to have something
> almost equivalent to the Linux model, which does support USB (and
> hence, bidirectional comms).

But only on newer hardware...  As a UNIX software vendor, *believe me*
when I say that most systems just don't support it (they don't have
the hardware, and those that do don't always have the software support)

>>what is normally done is to update the local PPD file as needed when
>>the device state changes.
> 
> 
> Gack!  What happens when you have 6 printers of the same model
> installed on your print server, and they are configured differently?
> Frankly, that sounds like a gross hack.

Each printer has its own copy of the PPD file, with changes specific
to that printer.  You need this anyways to support installable options
in the PPD file (unless you use the "include" method, which opens up
security holes)

In CUPS, PPD files are copied from /usr/share/cups/model to
/etc/cups/ppd/<printername>.ppd, and then users can make changes
to the copy via lpadmin, the web interface, etc.  Access is
managed via HTTP (password protected by default, and so forth...)

> And it means that if I want to write a small application with printing
> capabilities, then my program has to have root (or PPD file owner)
> permissions to work, or else have to access the capabilities via a
> separate program that has such permission.

Nope, you use a printing system (like CUPS) that manages access to the
files.  For most applications you just ask for the PPD file (with CUPS,
you get "http://servername:631/printers/printername.ppd", probably using
the CUPS API) so that you can read the current state.

Printer drivers run from the scheduler and can access/modify the PPD
file directly as needed.  If you decide to provide a separate background
process that monitors the printer, then that process just needs to
run as the "lp" user (not even root) to manage the local file, or
you can have a user program download, update, and upload the PPD file
via HTTP.

> ...
>>As for IP issues, from the perspective of a driver developer
>>all I can say is that generally what printer manufacturers  find new or
>>innovative has been done dozens of times before  by their competitors
>>already, or in other fields.  That said, I know I'm shouting into the
>>wind...
> 
> Someone has to be first, though, and it *is* a very fiercely competitive
> area.  But eventually, sure, the new tech becomes commonplace.

I'll tell you, in 8 years of writing commercial drivers and 7 years
before that just fooling around, I haven't seen anything innovative
in the printer commands sent to a printer.  If anything, printers
have become *less* capable in order to print costs down - all of the
innovation seems to be happening in the hardware and vendor-supplied
printer drivers, not in the commands sent to the printer...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com





More information about the printing-discuss mailing list