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

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

On Wednesday 26 December 2001 04:16 pm, Mark Hamzy wrote:
> ...
> of from the software printer driver.  I need to reread all the IPP
> documentation.  However, if each printer driver is an IPP server, can
> it handle that?  Also, it defines the contents of the job as a block

Yes.  It can also handle multiple printers using the same "server"
but using different URIs.  More specifically, each printer is an
object, which can be mapped to one or more actual servers.

> of binary data.  There are many steps in going from high level calls
> to the printer control language that a printer driver and operating
> system need.

No, it defines the print data as a typed block of data, which can
be "application/octet-stream" (auto-sense the type) or a specific
format identified by MIME type.

In the case of CUPS, we figure out the file type and then determine
which filter(s) need to be run to make a printable version of it.
The MIME type database is loaded at runtime from one or more config
files, and the PPD files for printers supplement this information
via the cupsFilter attributes.  Finally, the filtered print data is
piped into a backend process which communicates with the printer.

> ...
> language.  For example, there is another subgroup that is talking
> about printer capabilities.  That should be included in what makes up
> a printer driver.  Also, drivers need to have translatable resources
> such as form names that can be used to build a graphical
> representation of itself. Should there be many different pieces of
> software to install or protocols to
> speak to be able to handle each of these?

Again, in the case of CUPS we use PPD files with extra attributes
(which are ignored by Windows and MacOS clients) that define the
available capabilities, options, conflicts, and data for the driver
and filters that determine what the driver ends up getting.

Ultimately, you *really* want a static snapshot of what a driver can
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)

> ...
> The capabilities subgroup needs to query the printer driver at
> runtime and not though a static file (like a PPD).  Also, I believe
> that applications will want to be able to select between different
> print paths based on the printer's capabilities.

This isn't Windows or OS/2.  Applications will almost universally
produce PostScript until another format is universally supported.
Also, many PostScript apps already support PPD files, so it makes
sense to try to support it (even if you add your own extended
attributes which the standard apps ignore)

Also, trying to get printer drivers and applications to talk to
each other directly is a mistake.  It doesn't scale.  Better to
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.

> ...
> A GUI application will need to query the printer driver for its
> strings as well as hints as to how to display the information.

Again, a *static* file makes this a lot easier.  I'm not 100%
happy that the PPD spec only allows a single language right now,
but others have suggested a common translation catalog that covers
common options...

> ...
> While inkjets may not need acceleration, there are other printers
> that do. It is much more efficient to transfer a high level call like
> drawing a rounded box than it is to transfer a bitmap image of that
> box.  Some examples of high level languages are: HP-GL/2, PCL6, and
> even Postscript. Should there be two different code paths for
> printing to an inkjet printer vs printing to a Postscript printer?

HP-GL/2 is a waste of time.  There are too many special cases and
too many differences in appearance between models (even within HP
models).

PCL 6 is an option, but can be handled by existing software like
Ghostscript without requiring the application to know about it.

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.

> ...
> One example of reducing data that is sent to the printer driver is to
> use device fonts that are resident in the printer.  To achieve
> WYSIWYG printing,
> an application will have to query the printer driver for its font
> metrics.

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.

> ...
> something that the operating system should store and tell the
> application and printer driver.

The application should no nothing about what driver is being used,
just what capabilities the printer has...

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