[Omniprint-user] Re: [printing-cap] Re: [Inkjet-list] Re: Taking a step back

[Michael S. <mi...@ea...>]

On Monday 07 January 2002 06:44 pm, Ben Woodard wrote:
> > Ultimately, you *really* want a static snapshot of what a driver
> > can
>
> I think that this is a bit of an implementation thing. I really don't
> want a static representation.
>
> > do.  This ideally should be a data file that can be read by a
> > driver/ filter (using a standard API of course) to handle any
> > printer/job specific setup.  For devices whose options depend on,
> > say, what kind of ink cartridge is installed, a background driver
> > process can monitor the printer and update the static snapshot as
> > needed (and obviously any driver would need to reject/stop a job
> > that won't print on the current configuration)
>
> I'm really not a fan of this functionality. I'd much rather have some
> sort IPC mechanism rather than some sort of dropbox.

The problem with IPC is that it can cause major performance problems,
especially if you have to wait for a driver program to try to
communicate with a printer, which may be servicing a request from
another process/system which also wants to print...  Also, any IPC
mechanism you come up with has to be supported over networks to be
useful - network transparency is a requirement in today's "connected"
world...

No matter how you do it, your application will only have a static
snapshot from when it queried the printer driver.  Rebuilding this
snapshot each time it is requested is inefficient and will lead to
major performance and availability issues.

> > Also, trying to get printer drivers and applications to talk to
> > each other directly is a mistake.  It doesn't scale.  Better to
>
> I personally think this is completely wrong. I don't see how it
> doesn't scale at all.

Ben, I've been doing this stuff for a *long* time.  Sketch a quick
design for an API that allows multiple applications (possibly from
remote systems) to communicate with a driver directly, which then
talks directly to the printing device.

The bottleneck quickly becomes the printer and driver, which must
multiplex status inquiries from multiple sources, and also somehow
keep printing.  The only way to support such a scenario is to keep
an internal snapshot of the printer state and feed that to the
"clients" when they ask for it.  Guess what, you have a *static*
representation of the printer, but rather than storing that
representation someplace that can be quickly forwarded to the
client, you are re-processing everything.  On many printers this
can mean handling a *lot* of information (hundreds of media sizes
and types, not including resolution, quality, color, etc. modes)
for no real benefit.  If you do create a static snapshot that
is quickly sent to the client, then you have *exactly* the
mechanism provided by CUPS...

> > have the driver maintain a snapshot of the current configuration
> > than to introduce potentially long round-trip times which may
> > require UI intervention ("your printer is not connected or turned
> > off") or have to be postponed because the device is busy.
>
> I'm not a fan of this dropbox methodology that he is advocating. I
> agree that there is a problem if the printer or the printer is turned
> off we need to be able to provide the user with information in a
> timely manner but I still think that it needs to be provided by the
> drivers.

1. Printer configurations change infrequently.
2. Most conflicts between options can be stored statically; that is,
   duplex printing is *always* incompatible with transparency
   media, unless someone comes up with one-way ink :)  Those
   that depend on a hardware feature (which type of ink cartridge
   is installed) can still be expressed statically, but depend
   on some dynamic info that the driver needs to update as
   needed.
3. You *must* design for the 100 (or more) people trying to
   monitor/print to a printer.  See previous description of the
   problem.
4. There is a big difference between printer capababilities (that
   are provided to the user as a list of options) and printer
   state.  If tray 4 is empty, does that mean that a user can't
   print to tray 4?  Probably not.  Printer caps and state should
   be treated separately.

> ...
> > PostScript, with all its weaknesses, is still the defacto standard
> > printing format for UNIX apps.  Any printing solution will have to
> > support it to be accepted, which is why CUPS includes a version
> > of GNU Ghostscript for non-PS printers, and why we use PPDs.
>
> What ever happend PDF 1.4.

There are still a lot of problems with PDF in real-world printing.  It
works great if you want a document printed all on the same media,
with the same options, but it still doesn't support the full range
of printer options that PostScript does.  Basically, all you get (if
you have a compatible app, and Acrobat Reader doesn't even do this)
are a series of job ticket attributes that can be applied globally
or to individual pages, and unfortunately these attributes don't
support anything as simple as media type, etc.  See Adobe technote
5620, Portable Job Ticket Format.

> ...
> > The printer driver is not the right place for this; the printing
> > system needs to manage fonts, and provide an API for drivers to
> > register/retrieve them.
>
> Once again I think Michael and I differ here. I think that fonts
> should be part of the comabilities subsystem but I wasn't pushing
> that yet.

Both Microsoft and Apple put the font handling in the API, not in
the driver.  Drivers are free to support some fonts directly, however
all an app sees is a common set of fonts that are available.  If
a printer vendor provides a set of its own fonts, it must also
include display fonts so they are available to the system as a
whole.

Then it simply becomes a matter for the app to choose a font it
wishes to use; if the printer doesn't have that font, the driver
can either download the font (PCL/PS drivers do this in the
Windows world) or rasterize it at the printer's resolution.

Not surprisingly, this is the functionality that GNOME provides,
and KDE to a much lesser extent.  CUPS 1.2 will understand all of
the "required resource" stuff included with a PS file; when a
file uses a font called "Foo-Roman", the CUPS filter can look in
the PPD file to determine if the printer has that font, and if not
embed the font automatically.  CUPS already does this when printing
text files...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com