omniprint-user — User discussion of the Omni driver

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

[Robert L K. <rl...@al...>]

   From: Ben Woodard <be...@zo...>
   Date: Mon, 07 Jan 2002 15:44:42 -0800

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

How many applications generate PDF 1.4?  How many applications
generate PostScript?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

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

[Pete Z. <pz...@us...>]

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

This all really depends on what set of problems you want to solve.
If you look at several scenarios it will better define the components
that are needed and the way you could handle most of the scenarios.
We need to handle:
-  Device configuration information dynamic from the printer
-  Status information returned from the printer
-  Local configured printer
-  Network configured printer

1. Local printer configuration and capabilities

  The local printing (single user) scenario is fairly easily handled
  when utilizing IPC mechanisms.  Latency and information about the
  printer go away in this scenario because you don't have to worry
  about the 100 user scenarios.
  Information does not necessarily need to be statically maintained
  unless the printer does not handle bi-directional information
  that fully describes its configuration.  If the printer does not
  handle everything, then it should be up to some API interface into
  the print subsystem to be able to provide a representation of the
  configuration back to the application.  Notice I said interface and
  is required no matter where the information is coming from.

  The Print Summit was about interfaces and how do we get at the info.
  that is needed so that there can be consistency as the print system
  in Linux does its necessary evolution.

  It can be done by reading a PPD or it can be done by calling a printer
  driver and getting the current information back.  In either scenario,
  it would be a very good idea to have an API that can return the
  information in a STANDARD format to a calling application.  It would
  be of benefit if any information that may need to be extended, such
  as driver information, be abstracted away to an API that will allow
  for a standard format of information to be passed back so that as
  things evolve the APIs should be consistent from an application
  perspective.

   Local printer status information

  When doing local printing, the status should be immediate and any
  device specific protocol converter (daemon) of the data be manage
  the flow to and from the printer to always maintain an accurate
  account of the status of the job and printer state.

2. Networked printer configuration and capabilities

  In a networked environment with multiple users the problem gets
  a little harder.  It now depends on the components and how you
  manage the components but you are going to have to rely more on
  a static representation of the printer than a dynamic one.
  Again, if you have some protocol conversion daemon that is managing
  the data going back and forth between the printer and the system,
  it will know the current state of the printer and if it will have to
  rely on a statically cached version of the configuration or it can
  actually request an update from the printer.

   Networked printer status

  This one will work very similar in that if the converter is managing
  the flow of data and it understands the state of the printer, it can
  make the decision on if it can query the printer or it has to pass
  back to a caller (spooler or gui app) a static cache of the last known
  state of the printer.
  The static cache is necessary to avoid latency in the information.
  The conversion code should be able to know the type of the printer and
  when a transaction can occur with the printer.


Again, there should be:

  - Common API interfaces for getting the information to the application
  - Standard data format that is returned to the application looking for
    capabilities
    Underlying code and implementation does not need to be exposed as long
    as there is a defined API for getting the data in a standard format.
  - Tightly coupled component with the printer driver to manage the data
    flow to and from the printer and allow for things like getting caps.
    information from the printer, getting status from the printer,
    restarting pages and/or jobs, and aborting jobs.
  - An IPC mechanism for getting dynamic information from the driver and
    subsystem will be mandatory for licensing purposes.  It would likely
    be simpler if a singular interface could be used by both an application
    and the renderer.


** This of course doesn't include multiple systems hitting one printer or
   a networked environment where the printers are on different networks.

We went round and round a number of times on implementations and for
capabilities once we did the preliminary work for the summit, it really
got down to standardizing a way for the application to get the information
about the device and a way the driver gets told the settings when the job's
data is to be generated.

Fonts and drawing caps. are a different issue and purely dependant on the
rendering system and printer driver combo.



Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...

[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

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

[Ben W. <be...@zo...>]

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

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

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

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

What ever happend PDF 1.4.

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

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.

-ben

> 
> > ...
> > 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
> 
> _______________________________________________
> printing-cap mailing list
> pri...@fr...
> http://freestandards.org/mailman/listinfo/printing-cap

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

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

On Friday 28 December 2001 11:01 am, Robert L Krawitz wrote:
> ...
> That would probably work, although applications would need to reread
> the PPD whenever they wanted to start a new print job.

I think this would be the case, even for a dynamic data interface.

>                                                          For that
> matter, so would CUPS.

Yes, but the device daemons that are being used do this by telling
CUPS to use the new PPD file (i.e. CUPS only re-reads the file as
needed)

> ...
>    Well, for CUPS-based drivers at least it will work, and other apps
>    will "see" the standard PPD file that will still work everywhere.
>
> I'm nervous about what this leads to.  If CUPS has one set of
> extensions, another IPP-based system has another, and so forth, we
> get into trouble fast.

Not to "toot our own horn" too much, but right now CUPS is the only
IPP implementation that actually deals with printer drivers, options,
etc. at this level.  MS IPP and Novell IPP both still deal just with
sending raw print data... :(  Also, CUPS is already extending IPP
by providing PPD files, drivers, etc. on top of IPP (documented and
registered, of course, with the PWG), and anything we do to support
printer drivers on top of IPP will be an extension...

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

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

[Robert L K. <rl...@al...>]

   From: Michael Sweet <mi...@ea...>
   Date: Fri, 28 Dec 2001 09:59:29 -0500

   On Thursday 27 December 2001 07:12 pm, Robert L Krawitz wrote:
   > ...
   > I'm generally in favor of a dynamic view of what the driver can do,
   > because the constraints might be very complex, but this is an
   > interesting thought.  However, why do we need an actual file in the
   > filesystem (as opposed to some virtualized way of getting a handle to
   > a PPD file)?  Do applications rely on open()/fopen() of PPD files, or
   > is there some more abstract way of getting this information?

   Well, the printing system layer could generate the file for the
   client, however I'm pretty sure all existing clients need to
   ultimately read the PPD file from an actual file, although the
   KDEprint stuff might be just loading from the HTTP data, I dunno...

It's a pity that UNIX domain sockets don't quite have plain-file
semantics about open/read and the like; that would be a great way to
emulate static files with dynamic semantics.

   That said, there are enough existing apps that read PPDs directly
   from files (e.g. StarOffice) that we'll need to support a static
   snapshot file of some sort.  *How* that file is generated is a
   design decision, however I know of two developers that are using a
   background device daemon that monitors the print devices and update
   the local PPD files for the current configuration.  I suspect that
   this will remain the most flexible (i.e. least printing-system
   centric) design...

That would probably work, although applications would need to reread
the PPD whenever they wanted to start a new print job.  For that
matter, so would CUPS.

   > Extensions like this don't scale very well either; everybody will
   > define their own extensions (look at what Cups-o-matic does; it uses
   > structured comments in the PPD file to encode a perl data
   > structure!).

   Well, for CUPS-based drivers at least it will work, and other apps
   will "see" the standard PPD file that will still work everywhere.

I'm nervous about what this leads to.  If CUPS has one set of
extensions, another IPP-based system has another, and so forth, we get
into trouble fast.

   > I don't think we should think in terms of a single-threaded
   > server-based driver, but having some way of querying the driver (even
   > if it's a different process) would be useful.  I'm not convinced that
   > we need to address this in the first go-round, but ultimately we
   > will.

   The problem is that in most cases you can't query the printer while
   printing, and there are some major security issues with an app
   talking directly to a device.  Better to define a common set of
   attributes (there are a lot of them defined by IPP already) that
   the driver can report to the printing system, which can be provided
   to a client on request.  If you are monitoring the device when not
   printing, the scheduler status data can be updated on-the-fly...

I certainly don't want applications talking directly to the printer.
In my view, the driver handles all of this.  Of course, "driver" means
more than just the blitter (to use the OMNI terminology); it may well
mean a few cooperating programs (the blitter, the option enumerator,
and so forth).  How those (hypothetical) programs (driver components)
interact with each other is beyond the scope of what we're trying to
do here.

================================================================

Of course, there's the whole issue of what we're really trying to
accomplish; I think we're going around in circles.  I'd rather
understand specifically what IPP in general and CUPS specifically
don't do that we need, and understand whether the problems are
reasonably fixable, before going off to design yet another piece of
middleware.  While I like a dynamic view of the driver myself, it's
unclear to me that this is the most important problem to solve.  We
can emulate dynamic semantics with PPD files, as you note; if
applications will only read a PPD file once, it doesn't help.  I don't
think the weakest part of the UNIX printing system is at the blitter
stage; we as a group (both the people on these lists and the free
source community in general) are good at this kind of thing.

The problem that all this points to, as I see it, is that the
interface between applications and the printing system is weak.  The
traditional interface is a one-way pipe from application to printing
command (lpr or lp).  Postscript is a nice bolt-on that fits very well
within this, as long as you don't try to do anything fancy (like
understand what the printer can actually do beyond what /etc/printcrap
is able to express).  The problem is that modern printers (or drivers;
it's completely irrelevant whether the printer can actually do
something or the driver emulates it) are much more capable than the
guys at Berkeley designed for back in the late 1970's, and
applications are a lot more sophisticated.  KDE and GNOME are at least
asking some of the right questions, even if some of the answers might
be a bit strange.

The issue I noted about applications possibly not rereading PPD files
really has little to do with the use of PPD files vs. any other
mechanism.  Using PPD files as an IL is probably fine.  The problem is
that each application takes its own view of the world, and takes a
completely noninteractive view of printing (Netscape actually bothers
to give you a popup with the output of the lpr command, which is
better than a lot of things).  It is my belief that we cannot fix
things as long as this is the prevailing approach; we need to
standardize something more powerful at this layer before it even makes
sense to talk about the driver interface.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

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

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

On Thursday 27 December 2001 08:31 pm, Raph Levien wrote:
> ...
> This kind of thing seems potentially quite tricky to me: how does
> the print driver _know_ that tray 2 contains yellow paper? I am
> unaware of any printers that have colorimeters in their paper trays.
> ...

Most laser printers that support the PostScript MediaColor attribute
have a way to set the media color, type, and size for each tray
from the control panel.  Most current laser printers can detect
media size automatically, so the type and color are the other
attributes you have to setup manually on the printer.

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

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

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

On Thursday 27 December 2001 07:12 pm, Robert L Krawitz wrote:
> ...
> I'm generally in favor of a dynamic view of what the driver can do,
> because the constraints might be very complex, but this is an
> interesting thought.  However, why do we need an actual file in the
> filesystem (as opposed to some virtualized way of getting a handle to
> a PPD file)?  Do applications rely on open()/fopen() of PPD files, or
> is there some more abstract way of getting this information?

Well, the printing system layer could generate the file for the
client, however I'm pretty sure all existing clients need to
ultimately read the PPD file from an actual file, although the
KDEprint stuff might be just loading from the HTTP data, I dunno...

That said, there are enough existing apps that read PPDs directly
from files (e.g. StarOffice) that we'll need to support a static
snapshot file of some sort.  *How* that file is generated is a
design decision, however I know of two developers that are using
a background device daemon that monitors the print devices and
update the local PPD files for the current configuration.  I
suspect that this will remain the most flexible (i.e. least
printing-system centric) design...

> ...
> Extensions like this don't scale very well either; everybody will
> define their own extensions (look at what Cups-o-matic does; it uses
> structured comments in the PPD file to encode a perl data
> structure!).

Well, for CUPS-based drivers at least it will work, and other apps
will "see" the standard PPD file that will still work everywhere.

As for CUPS-o-matic, the perl data will almost certainly stay as
it is, but I'm pretty sure that the options can be updated to
use the new CUPS naming without a lot of trouble...

> ...
> I don't think we should think in terms of a single-threaded
> server-based driver, but having some way of querying the driver (even
> if it's a different process) would be useful.  I'm not convinced that
> we need to address this in the first go-round, but ultimately we
> will.

The problem is that in most cases you can't query the printer while
printing, and there are some major security issues with an app
talking directly to a device.  Better to define a common set
of attributes (there are a lot of them defined by IPP already)
that the driver can report to the printing system, which can
be provided to a client on request.  If you are monitoring the
device when not printing, the scheduler status data can be
updated on-the-fly...

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

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

[Raph L. <ra...@ca...>]

On Wed, Dec 26, 2001 at 03:16:52PM -0600, Mark Hamzy wrote:
> First, I would like to point out that I am not an IBM spokesperson.  Don't
> take my views as "IBM says you should do this." I am just someone who has
> worked with printer drivers on multiple operating systems for ten years.

Understood.

> Second, this group came together to work on standards for Linux in the area
> of printing.  No one person should control it and everyone should come
> together in agreement for what direction Linux should take.  At this stage,
> proposals should be announced.  It shouldn't be one or another.  We should
> look at existing solutions and if they do not provide what we need, then we
> should take the best ideas from everyone and create something new.

I basically agree here. However, if creating something new means
incompatibility with IJS, or reinventing most of IPP, I'm not sure
that's a good thing.

> IPP has looked at and standardized on many things that relate to printing.
> However, they look at it from the view point of the physical printer
> instead
> 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 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.

Yes. I think IPP was designed to handle a number of scenarios, including
physical devices implementing IPP and also print servers of various
flavors. Certainly, the protocol emphasizes very different things than
the IJS work. There is no doubt nontrivial work remaining to "profile"
IPP to be most useful in Linux frameworks. The experience of the CUPS
project will no doubt be extremely useful towards this goal.

> I think that there are many different areas that make up a printer driver.
> It is not just a filter to translate raster bitmap data into printer
> control
> 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?

Bingo! This is the _real_ question. What is a printer driver?
Presumably, in this context, most printer drivers will be shipped as
RPM packages for some subset of Linux distributions. What should be in
this package? I think we have very strong consensus that _one_ of the
components should be an executable that does the raster to escape code
translation, speaking some kind of IPC protocol with the module that
actually provides the raster data.

I think the questions about how to package the _other_ components of
the printer driver are much more challenging. Perhaps we should try to
pile as much of it into the IPC protocol as possible. I personally
don't think this is the best solution. I believe there are some needed
features that can't be implemented entirely within the IPC protocol
(such as discovering the most appropriate driver for the printer), and
others that would be better implemented using a combination of static
data with IPC protocol assist for the parts that need to dynamic
(capabilities and UI pieces).

> All of the things that are considered as "the Omni group" put into PDC
> should not be viewed as proprietary extensions.  These are some of the
> things
> that I think are necessary as paradigms of common printer driver
> information and setup.  I have tried to design this to be as easy as
> possible for other printer drivers to implement.  There should be as much
> information and routines as possible to be common for the best user
> experience.
> 
> Now that that was said, let me move on to the differences between PDC and
> IJS.

Thanks very much for this. I think it's extremely helpful for
resolving the remaining technical issues.

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

I agree that dynamic printer capability reporting is important. That's
why IJS contains support for enumerating and querying parameters. Some
capabilities, such as duplexing and color support, are defined in the
base IJS spec. Others will need to be defined as extensions.

The latest rev of the spec also imports the PPD namespace for finishing
options (the Finishing: prefix), and also reserves space for other
PPD parameters.

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

I agree. However, I rather strongly believe that the rasterizer <->
driver IPC connection is the wrong place for it.

For one, as far as I can determine, all of this information can be
provided statically. Even in the case of dynamic capabilities, the
strings and icons to represent these capabilities can be static.

Second, GUI _applications_ should not be talking directly to the
printer driver through an IPC channel. It is clear that another
layer is needed. I don't see the value in having the rasterizer
simply pass this information through.

Third, not having the UI bits in the driver IPC protocol makes life
easier for people packaging up printer drivers. In particular, it's
possible to add strings, icons, etc., without having to mess with
the driver executable itself.

Lastly, coming up with a good standard for UI bits usable for all of
the Linux desktop platforms is a formidable challenge. Perhaps it's
one the Printing Working Group is willing to take on. It's not one
I'm willing to take on with IJS.

> High Level Device Acceleration
> ------------------------------
> 
> 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?

This is a good question, and I think the answer is "yes".

That said, the current IJS proposal is in no way limited to raster
data. I added the PageImageFormat parameter explicitly to allow
compressed and higher level formats.

Characterizing the command set of a printer is hard. PCL printers
have notoriously wide variation in the exact PCL dialect implemented.
I don't think the major/minor/micro version number is adequate.

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

I believe that _accurately_ characterizing the fonts available on
the printer to the client is a big giant can of worms. To get this
right, you have to deal with font metrics, glyph complement, and
encoding.

That said, there's no reason why the IJS wire protocol can't accommodate
this kind of information.

> Constraints
> -----------
> 
> In order to prevent printing duplex on transparencies, the application
> should be told by the printer driver that this will cause a problem.  A
> printer driver writer will know what are the constraints that the device
> places on the coder but there is no way to let an application know.

IJS actually provides a way to address this: the server can make
the Duplex enumeration report no duplexing when transparencies are
selected.

> Job id vs New Instance of Communications
> ----------------------------------------
> 
> I believe that making the client allocate and keep track of job ids causes
> extra complexity without any benefit.  It is easier to start another
> communications session to the printer driver.  This way, the printer driver
> does not have to keep track that id X is in page Y and band Z while id X'
> has just started.  Also, I don't see how the output from multiple
> simultaneous jobs are kept separate.

Hmm. This means that the printer driver must support listening for
multiple connections. In addition, you have to standardize how clients
can discover the various printer drivers with open ports, as well as
nailing down how the driver does access control.

Incidentally, I'm now thinking that "master" and "slave" are more
appropriate names for the IJS roles than "client" and "server". This
terminology is far more intuitive for describing a process which is
both an IJS master and a server for some other protocol, for example
IPP.

Output can be kept separate by specifying finishing options.

> Form Size vs Form Name
> ----------------------
> 
> The form should be selected by the media name.  First, there is a non-exact
> conversion between inches and millimeters.  Second, it is easier to
> remember
> the form name rather than the form size.  For example, a non-US user wants
> to print out on A3 paper.  Is it easier to specify 11.69x16.53 or iso_A3?
> While a table may help, if a new form comes out, then it will be unknown to
> the application.

Possibly. I'm not convinced. In any case, the IJS wire protocol can
easily handle form names as an extension parameter.

> Device Name
> -----------
> 
> Printer drivers that handle many different categories of devices need to be
> told unequivocally what the model name and device name is.  It should not
> have to do a bidirectional call to query the printer name (one reason why
> would be printing to a file).  I believe that this is something that the
> operating system should store and tell the application and printer driver.

This is an architectural question having to do with the way the driver
is used. There's nothing about IJS that forces clients to query the
device name.

> All of the Job Properties
> -------------------------
> 
> I think that the protocol should send every job property to the printer
> driver.  It should also, in the best case, set all of the job properties at
> once.  PDC tries to define a set of common job properties that are the same
> between all drivers.  It is difficult for the user to know that there is a
> set of Ghostscript job properties (-sPAPERSIZE=a4, -r300) and a set of IJS
> job properties (-dIjsDepth=24, -sIjsParam="...").

I'm afraid I simply don't understand this issue.

> Printer Properties
> ------------------
> 
> Printer properties are necessary to know things like 4Mb of memory is
> installed and yellow paper is in tray 2.  The printer driver will send
> different commands to the printer based on what printer properties are set.

I agree that such a thing is desirable. In the PostScript world,
PPD files generally provide this functionality. To the extent that
it should be implemented in the IPC protocol, I can see it implemented
as sub-namespace of IJS parameters.

This kind of thing seems potentially quite tricky to me: how does
the print driver _know_ that tray 2 contains yellow paper? I am
unaware of any printers that have colorimeters in their paper trays.


I think it's possible to come to some closure here. The goal of IJS is
basically to solve the easy problems needed to make inkjet printers
work reasonably well in current Linux/Unix systems. It avoids the
harder problems of parameterized UI bits, non-raster PDL and font
characterization, driver selection for autosensed device ID's, and so
on.

These are important issues, and I truly wish the PWG<2> success in
dealing with them. I believe that IJS is a useful starting point, and
that it would be beneficial for users and driver developers alike to
be able to implement a simple driver based on IJS at first, and add in
PWG<2> enhancements as needed, and as they become standardized. I am
open to suggestions on how to make IJS a suitable basis for this
future work, particularly in terms of providing a robust extension
mechanism.

I personally do not have the time or energy to participate fully in
a standards process for these rather tricky issues. Thus, in terms
of process, I see myself pushing IJS to a 1.0 version in a relatively
short timespan, then handing it over to another group (perhaps the
PWG<2>) for future extensions.

On the other hand, I'm not going to try to stop the PWG<2> from
adopting an incompatible wire protocol if that's what they truly want
to do.

Raph

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

[Robert L K. <rl...@al...>]

   From: Michael Sweet <mi...@ea...>
   Date: Wed, 26 Dec 2001 19:05:00 -0500

   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)

I'm generally in favor of a dynamic view of what the driver can do,
because the constraints might be very complex, but this is an
interesting thought.  However, why do we need an actual file in the
filesystem (as opposed to some virtualized way of getting a handle to
a PPD file)?  Do applications rely on open()/fopen() of PPD files, or
is there some more abstract way of getting this information?

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

Extensions like this don't scale very well either; everybody will
define their own extensions (look at what Cups-o-matic does; it uses
structured comments in the PPD file to encode a perl data
structure!).

   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.

I don't think we should think in terms of a single-threaded
server-based driver, but having some way of querying the driver (even
if it's a different process) would be useful.  I'm not convinced that
we need to address this in the first go-round, but ultimately we
will.

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

   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.

I agree wholeheartedly with this.  Applications normally shouldn't
generate raw printer data; Postscript is no worse of an IL than
anything else.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Omniprint-user] Help setting up Omni print driver on Redhat 7.9

[Mark H. <ha...@us...>]

Hey Ken,

I know I have run into that problem all the time.  You want to install one
package but are forced to bring in more packages which bring in even more
packages.  But it does stop at some point.

I know that you can specify multiple packages on the rpm upgrade command
line.  The question is are you adverse to upgrading all the other packages?

Another avenue you can try is to ask the foomatic people on
http://www.linuxprinting.org/newsportal/thread.php3?name=linuxprinting.foomatic.devel
if you can run on older systems.

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

Re: [Omniprint-user] Help setting up Omni print driver on Redhat 7.9

[Mark H. <ha...@us...>]

Once upon a time on Wed, 26 Dec 2001 15:25:29 -0600
"Mark Hamzy" <ha...@us...> Wrote:

> Hey Ken,
>
> There is a new errata on Red Hat.  Download it from:
> http://www.redhat.com/support/errata/RHSA-2001-138.html
> It has a new version of printconf and foomatic.
> When you install this, you can use printconf to setup a printer driver.
>
> I hope this helps,
>
> Mark
>
Mark;

It helps a bit but I am having trouble upgrading Perl from my redhat 7.0
version to the latest Perl for version redhat 7.2. Seems foomatic needs the
latest perl.

 libdb-3.2.so   is needed by perl-5.6.0-17

when I try to install db3-3.2.9-4.i386.rpm  which is what is supposed to
give me libdb-3.2.so I get the foloowing dependencies problems.

error: failed dependencies:
        libdb-3.1.so is needed by python-1.5.2-27
        libdb-3.1.so is needed by kpackage-1.3.10-7
        libdb-3.1.so is needed by rpm-build-4.0.2-7x
        libdb-3.1.so is needed by rpm-python-4.0.2-7x
        libdb-3.1.so   is needed by gnorpm-0.95.1-6.7x
        libdb-3.1.so   is needed by perl-5.6.0-10a
        libdb-3.1.so   is needed by rpm-4.0.2-8
        libdb-3.1.so is needed by sendmail-8.11.6-2.7.0
        libdb-3.1.so is needed by pam-0.72-37

What is the solution? Is there an upgrade path or a way to get Omni print
drivers to run on a redhat 7.0 system?

Thanks;  ken

Re: [Omniprint-user] Help setting up Omni print driver on Redhat 7.9

[Mark H. <ha...@us...>]

Hey Ken,

There is a new errata on Red Hat.  Download it from:
http://www.redhat.com/support/errata/RHSA-2001-138.html
It has a new version of printconf and foomatic.
When you install this, you can use printconf to setup a printer driver.

I hope this helps,

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[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

[Omniprint-user] Re: Taking a step back

[Mark H. <ha...@us...>]

First, I would like to point out that I am not an IBM spokesperson.  Don't
take my views as "IBM says you should do this." I am just someone who has
worked with printer drivers on multiple operating systems for ten years.

Second, this group came together to work on standards for Linux in the area
of printing.  No one person should control it and everyone should come
together in agreement for what direction Linux should take.  At this stage,
proposals should be announced.  It shouldn't be one or another.  We should
look at existing solutions and if they do not provide what we need, then we
should take the best ideas from everyone and create something new.

IPP has looked at and standardized on many things that relate to printing.
However, they look at it from the view point of the physical printer
instead
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 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.

I think that there are many different areas that make up a printer driver.
It is not just a filter to translate raster bitmap data into printer
control
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?

All of the things that are considered as "the Omni group" put into PDC
should not be viewed as proprietary extensions.  These are some of the
things
that I think are necessary as paradigms of common printer driver
information and setup.  I have tried to design this to be as easy as
possible for other printer drivers to implement.  There should be as much
information and routines as possible to be common for the best user
experience.

Now that that was said, let me move on to the differences between PDC and
IJS.

Printer Capabilities
--------------------

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.

Translatable Resources
----------------------

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

High Level Device Acceleration
------------------------------

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?

Device Fonts
------------

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.

Constraints
-----------

In order to prevent printing duplex on transparencies, the application
should be told by the printer driver that this will cause a problem.  A
printer driver writer will know what are the constraints that the device
places on the coder but there is no way to let an application know.

Job id vs New Instance of Communications
----------------------------------------

I believe that making the client allocate and keep track of job ids causes
extra complexity without any benefit.  It is easier to start another
communications session to the printer driver.  This way, the printer driver
does not have to keep track that id X is in page Y and band Z while id X'
has just started.  Also, I don't see how the output from multiple
simultaneous jobs are kept separate.

Form Size vs Form Name
----------------------

The form should be selected by the media name.  First, there is a non-exact
conversion between inches and millimeters.  Second, it is easier to
remember
the form name rather than the form size.  For example, a non-US user wants
to print out on A3 paper.  Is it easier to specify 11.69x16.53 or iso_A3?
While a table may help, if a new form comes out, then it will be unknown to
the application.

Device Name
-----------

Printer drivers that handle many different categories of devices need to be
told unequivocally what the model name and device name is.  It should not
have to do a bidirectional call to query the printer name (one reason why
would be printing to a file).  I believe that this is something that the
operating system should store and tell the application and printer driver.

All of the Job Properties
-------------------------

I think that the protocol should send every job property to the printer
driver.  It should also, in the best case, set all of the job properties at
once.  PDC tries to define a set of common job properties that are the same
between all drivers.  It is difficult for the user to know that there is a
set of Ghostscript job properties (-sPAPERSIZE=a4, -r300) and a set of IJS
job properties (-dIjsDepth=24, -sIjsParam="...").

Printer Properties
------------------

Printer properties are necessary to know things like 4Mb of memory is
installed and yellow paper is in tray 2.  The printer driver will send
different commands to the printer based on what printer properties are set.

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] rpm's needed for a complete install of Omni print drivers

[Kenneth J. K. <kk...@bc...>]

What rpm's do I need for a complete install of Omni print drivers for a redhat 
7.0 system? I already installed 0.5.1 drivers for my printer.
Does anyone know if there are rpm's for redhat 7.0 as I only have found rpm's 
for version redhat 7.2. I wonder if they will install without any dependency 
problems?

thanks; ken

[Omniprint-user] Help setting up Omni print driver on Redhat 7.9

[ken k. <kk...@bc...>]

I downloaded the rpm for my printer. Now how do I get the printer to use these drivers? Sorry I didn't see any howto on this at the website. Perhaps someone can direct me to something that describes how to use the Omni drivers for Linux

thanks;  ken

[Omniprint-user] proposal(4) of what features the communication to a printer driver should support

[Mark H. <ha...@us...>]

Here is version 4 of a proposal of what features the communication
to a printer driver should support.

I propose to call this communication PDC for Printer Driver Communication.

If you want to start coding testcases, the omni driver supports this
proposal.  The source code is freely available and is located at
http://www.sourceforge.net/projects/omniprint/ under the following files:
   OmniServer.[hc]pp, OmniPDCProxy.[hc]pp, DeviceTester8.cpp,
   PrinterCommand.[hc]pp

What license should this code be under?  We can rerelease it under any
license that the group decides.

todo -
   define input formats (text, bitblt, ...) and raster formats.
   add more informational stuff to form name (selectable)

Communication method
--------------------

Currently:

PDC is based on inter-process communication (IPC) through a named pipe.
All commands are read and written through this pipe except for commands
which contain a lot of data.  One example is PDCCMD_RASTERIZE.  This
command uses shared memory buffers to transfer the bitmap bits.  The
printer driver will send the printer control language through standard
output.  This is a client/server approach.  The client will spawn the
printer driver server program and set two environment variables.  These
variables are the names of the two named pipes.  The first,
PDC_SRV_TO_CLIENT, is the server to client channel and the second,
PDC_CLIENT_TO_SRV, is the client to server channel.

Future:

Obviously, this needs to change.  The client needs to call an API set.
This has been called a service provider interface (SPI).  This API will
talk to multiple printer drivers.  They need to be able to run as a daemon
and handle multiple PDC sessions.

The group needs to agree on a communications method.  Some possibilities
are: TCP/IP and CORBA.

One thing to keep in mind, though, is that the printer driver may use
PDC for internal communications between components.  For example, omni
has a pluggable blitter that uses a stripped down version of PDC to talk
to a blitter (app -> PDC -> omni -> pdc -> blitter).
I don't want the implementation to preclude this.

Structure of Message Block
--------------------------

Packets are variably-lengthed.  They will always contain the command, size
of the packet, and the type of the variable data.

typedef enum _PrinterDriverCommunicationCommand {
   PDCCMD_ACK = 1,
   ...
} PDC_CMD, *PPDC_CMD;

typedef enum _PrinterDriverCommunicationFormat {
   PDCFMT_NULL = 1,
   PDCFMT_STRING,
   PDCFMT_BINARY,
   PDCFMT_INTEGER,
   PDCFMT_LONG
} PDC_FMT, *PPDC_FMT;

typedef struct _PrinterDriverCommunicationPacket {
   PDC_CMD eCommand;          // Printer Driver Command
   size_t  cbLength;          // Length of this packet
   PDC_FMT eFormat;           // Type of the following data
   char    achCommandLine[1]; // Start of data
} __attribute__ ((aligned (1))) __attribute__ ((packed))
  PDC_PACKET, *PPDC_PACKET;

Session management
------------------

PDCCMD_INITIALIZE_SESSION "Version"
   The first command should be a hand-shaking of the versions.
   A good response is:
      PDCCMD_ACK "Version"

PDCCMD_CLOSE_SESSION
   Close the session.
   There is no response.

PDCCMD_IS_CMD_SUPPORTED cmd
   This command exists so that a client can query if a server supports a
   command.  This provides more information/granularity than the version
   string.
   A good response is:
      PDCCMD_ACK

PDCMD_SET_TRANSLATABLE_LANGUAGE abbreviation
   This command tells the printer driver to return all translatable strings in
   the language from these choices:
     aa - Afar
     ab - Abkhazian
     af - Afrikaans
     am - Amharic
     ar - Arabic
     as - Assamese
     ay - Aymara
     az - Azerbaijani
     ba - Bashkir
     be - Byelorussian
     bg - Bulgarian
     bh - Bihari
     bi - Bislama
     bn - Bengali Bangla
     bo - Tibetan
     br - Breton
     ca - Catalan
     co - Corsican
     cs - Czech
     cy - Welsh
     da - Danish
     de - German
     dz - Bhutani
     el - Greek
     en - English
     eo - Esperanto
     es - Spanish
     et - Estonian
     eu - Basque
     fa - Farsi
     fi - Finnish
     fj - Fiji
     fo - Faeroese
     fr - French
     fy - Frisian
     ga - Irish
     gd - Scots Gaelic
     gl - Galician
     gn - Guarani
     gu - Gujarati
     gv - Manx Gaelic
     ha - Hausa
     he - Hebrew
     hi - Hindi
     hr - Croatian
     hu - Hungarian
     hy - Armenian
     ia - Interlingua
     id - Indonesian
     ie - Interlingue
     ik - Inupiak
     in - Indonesian
     is - Icelandic
     it - Italian
     iu - Inuktitut
     iw - Hebrew
     ja - Japanese
     ji - Yiddish
     jw - Javanese
     ka - Georgian
     kk - Kazakh
     kl - Greenlandic
     km - Cambodian
     kn - Kannada
     ko - Korean
     ks - Kashmiri
     ku - Kurdish
     ky - Kirghiz
     la - Latin
     lo - Laothian
     ln - Lingala
     lt - Lithuanian
     lv - Latvian Lettish
     mg - Malagasy
     mi - Maori
     mk - Macedonian
     ml - Malayalam
     mn - Mongolian
     mo - Moldavian
     mr - Marathi
     ms - Malay
     mt - Maltese
     my - Burmese
     na - Nauru
     ne - Nepali
     nl - Dutch
     no - Norwegian
     oc - Occitan
     om - Oromo Afan
     or - Oriya
     pa - Punjabi
     pl - Polish
     ps - Pashto Pushto
     pt - Portuguese
     qu - Quechua
     rm - Rhaeto Romance
     rn - Kirundi
     ro - Romanian
     ru - Russian
     rw - Kinyarwanda
     sa - Sanskrit
     sg - Sangro
     sh - Serbo Croatian
     sd - Sindhi
     si - Singhalese
     sk - Slovak
     sl - Slovenian
     sm - Samoan
     sn - Shona
     so - Somali
     sq - Albanian
     sr - Serbian
     ss - Siswati
     st - Sesotho
     su - Sundanese
     sv - Swedish
     sw - Swahili
     ta - Tamil
     te - Telugu
     tg - Tajik
     th - Thai
     ti - Tigrinya
     tk - Turkmen
     tl - Tagalog
     tn - Setswana
     to - Tonga
     tr - Turkish
     ts - Tsonga
     tt - Tatar
     tw - Twi
     ug - Uighur
     uk - Ukrainian
     ur - Urdu
     uz - Uzbek
     vi - Vietnamese
     vo - Volapk
     wo - Wolof
     xh - Xhosa
     yi - Yiddish
     yo - Yoruba
     zh - Chinese
     zu - Zulu
   The default is en (English).
   A good response is:
      PDCCMD_ACK

PDCMD_QUERY_TRANSLATABLE_LANGUAGES
   This command asks the printer driver what translatable languages that it
   supports.  See PDCMD_SET_TRANSLATABLE_LANGUAGE for a list of valid language
   codes.  The response is a space separated list of language codes.
   A good response is:
      PDCCMD_ACK en

Device management
-----------------

PDCCMD_ENUM_DEVICES [PDLLevel PDLSubLevel PDLMajorRevisionLevel PDLMinorRevisionLevel]
   Enumerate all supported devices that a printer driver supports.
   You can optionally pass in a set of PDL information to match against.
   You receive a nul-terminated separated list of device names.
   NOTE:  This can either the entire list or what subset is installed.
   A good response is:
      PDCCMD_ACK "Brother.Brother HJ-100i\0...Star.Star ZA-250 Multi-Font\0\0"

PDCCMD_SET_DEVICE_NAME "DeviceName"
   Associate a device name to the communications.  This is a required command
   for the rest of the following commands in this document.  This must be
   the name of a supported device.
   A good response is:
      PDCCMD_ACK

PDCCMD_IS_VALID_DEVICE_NAME "DeviceName"
   Query the driver to see if the driver supports a device name.
   A good response is:
      PDCCMD_ACK

PDCCMD_GET_PDL_INFO
   Query a device's programatic language description. (PCL, ESC/P2, PS, HG/GL).
   It returns 4 space separated integers in a string as follows: PDL level,
     PDL sublevel, PDL major revision level, and PDL minor revision level.
   This of course is a proposal of a simple way to determine a printer driver's
   language.
   NOTE:  This can allow spoolers to move jobs between similar print queues.
   A good response is:
      PDCCMD_ACK PDLLevel PDLSubLevel PDLMajorRevisionLevel PDLMinorRevisionLevel

Configuration Storage
---------------------

Drivers should standardize on where to store configuration entries on the
local system.

Job Properties
--------------

Drivers should support a set of core properties.  For example, at a minimum,
a driver should support (note: this is only a sample):
   form
   media
   tray
   resolution
   orientation
   color/monochrome
   copies

For the core properties, a driver should support a set of standardized
selections.  This will help in moving jobs between different printer
drivers that support a printer.  For example:

   form
      Some examples are:
         na_letter_8.5x11x0.1x0.1x0.1x0.1in
         na_legal_8.5x14x0x0x0x0in
         iso_a3_297x420x0.12x0.08x0x0mm
         jis_b4_257x364x1x2x1x1mm
         jpn_hagaki_100x148x0x0x1x1mm
      The first part is the only part that is required to set the form.
         It consists of a prefix (na - north america, iso - international
         standards organization, jis - japan industrial standard, jpn -
         japan, prc - people's republic of china) followed by an
         underscore followed by the form name followed by an underscore.
      The rest is optional and is of an informational nature.  It
         consists of 6 numbers as follows:  width, height, left, top,
         right, and bottom unprintable margins.  Following this is
         the suffix of the units of measure (in - inches, mm -
         millimeters).

       A printer driver may allow a short-cut of not requiring the prefix
         to select the form.  An example would be "form=letter".
         However, it does not guarantee an exact match and the result is
            undefined.  Some conflicting names are jis_b4 vs iso_b4,
            iso_a2 vs na_a2, iso_c5 vs na_c5, and prc_16k vs roc_16k.

   media
      Some examples are:
         stationery
         stationery-coated
         stationery-inkjet
         stationery-preprinted
         stationery-letterhead
         stationery-prepunched
         stationery-fine
         stationery-heavyweight
         stationery-lightweight
         transparency
         envelope
         envelope-plain
         envelope-window
         continuous
         continuous-long
         continuous-short
         tab-stock
         pre-cut-tabs
         full-cut-tabs
         multi-part-form
         labels
         multi-layer
         screen
         screen-paged
         photographic
         photographic-glossy
         photographic-high-gloss
         photographic-semi-gloss
         photographic-satin
         photographic-matte
         photographic-film
         back-print-film
         cardstock
         roll

   tray

   resolution
      Resolution is either given as two integers separated by an 'x' or one
        integer.  In the second case, the resolution is considered square or
        equal.  Some examples are 1440x720, 300x300, or 600.

      There can be a word that will associate to a resolution to make life
        simpler to users.  For example: draft, fine, group-3, group-4, high,
        low, medium, normal, photo-quality, and presentation.  These are
        considered non-standard and driver dependant.

   orientation
      The choices are:
         portrait
         landscape
         reverse-portrait
         reverse-landscape

   color
      This is used to select between monochrome or color.  The choices are:
         monochrome
         color

   copies
      This is used to determine how many copies of a job are printed.

The driver should also have a set of driver specific properties.

PDCCMD_SET_JOB_PROPERTIES "JobProperties"
   Set the job properties for a session.  The job properties is a space
   separated list of key=value entries.
   NOTE: I think that all the properties should be set in one command.  I
         can envision scenarios where individual sets could paint the
         driver into a corner.
         There should be default job properties if some or none of the
         job properties are set.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_JOB_PROPERTIES
   Query the current job properties.  This returns a list of common and
   driver specific job properties.
   NOTE: This can happen both before and after the job properties are set.
   A good response is:
      PDCCMD_ACK "orientation=... form=... tray=... ..."

PDCCMD_LIST_JOB_PROPERTY_KEYS
   Enumerate the set of common job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "orientation form tray ..."

PDCCMD_LIST_DEVICE_JOB_PROPERTY_KEYS
   Enumerate the device specific job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "scaling ..."

PDCCMD_GET_JOB_PROPERTY key
   Enumerate the options for a job property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "landscape portrait ..."

PDCCMD_GET_JOB_PROPERTY_TYPE key
   Enumerate the type of a job property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string portrait"

Printer Properties
------------------

Drivers need to know about what optional features are installed for
a printer.

Perhaps there can be a core set of printer properties.  For example,
   a duplexer is installed
   extra memory is installed
   an extra tray is installed or is configured to hold certain paper

PDCCMD_SET_PRINTER_PROPERTIES "PrinterProperties"
   Set the printer properties.
   NOTE: I think that all the properties should be set in one command.  I
         can envision scenarios where individual sets could paint the
         driver into a corner.
         There should be default printer properties if some or none of the
         printer properties are set.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_PRINTER_PROPERTIES
   Query the printer properties.  This returns a list of common and
   driver specific printer properties.
   NOTE: This can happen both before and after the printer properties are
         set.
   A good response is:
      PDCCMD_ACK "duplexer=... memory=... ..."

PDCCMD_LIST_PRINTER_PROPERTY_KEYS
   Enumerate the common printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "duplexer memory ..."

PDCCMD_LIST_DEVICE_PRINTER_PROPERTY_KEYS
   Enumerate the device specific printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "stapler ..."

PDCCMD_GET_PRINTER_PROPERTY key
   Enumerate the options for a printer property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "on off ..."

PDCCMD_GET_PRINTER_PROPERTY_TYPE key
   Enumerate the type of a printer property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string on"

Job Control
-----------

PDCCMD_BEGIN_JOB
   Start a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_START_PAGE
   Start a page.
   NOTE: You can optionally change the properties for the page by calling
         PDCCMD_SET_JOB_PROPERTIES "JobProperties" before this command.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_PAGE
   End a page.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_JOB
   End a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_PAGE
   Abort a page.
   NOTE: This is optional.  If this fails then one must abort the
         entire job.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_JOB
   Abort a job.
   NOTE: This is required.
   A good response is:
      PDCCMD_ACK

Job Data
--------

Here is where you have to ask yourself:  Are you a graphics engine
that is talking to a printer driver or are you an application that
is talking to a printer driver.

If you are a graphics engine, then you will want to allow the
device to accelerate high level commands (Ex: drawing a box with rounded
corners).  Every command that is not supported at a high level will be
rasterized into a series of banded bitmaps and then sent down to the
device.  It should be drawn into the bitmap format that the device
wants  (Ex: RGB, CMYK, CcMmYK; 1, 8, 24 bits per pel; 8 or 32 bit scan
line aligned; top or bottom orientation; etc).

If you are an application, you want to print simply.  Some examples are:
   a series (1 or more) of bitmaps of any color depth at any position
     on the page.
   postscript commands
   printer specific data - do not modify this data stream at all!
   plain text

PDCCMD_MODE_IS_RENDERER boolean
   This command indentifies to the printer driver that a renderer is
   talking to it.  This command is optional.  The default is false
   (an application is talking to it).
   A good response is:
      PDCCMD_ACK

PDCCMD_ATTACH_BUFFER1 id
PDCCMD_ATTACH_BUFFER2 id
PDCCMD_DETACH_BUFFER1 id
PDCCMD_DETACH_BUFFER2 id
PDCCMD_RASTERIZE
   These commands are shared for printing a series (1 or more) of bitmaps
   of any color depth and for a series of banded bitmaps of the page.
   The first is a structure that describes the bitmap data.  It contains:
      cx             - the width of the bitmap data
      cy             - the height of the bitmap data
      cPlanes        - the number of planes in the bitmap
      cBitCount      - the color depth of the bitmap
      ulCompresstion - the compression of the bitmap data
      cclrUsed       - the number of colors used in the bitmap
      cclrImportant  - the number of colors that are important
      argbColor      - the color table if there is one
      We should add a bitmap type field that contains the alignment
      and direction.
   The second contains the bits of the bitmap.
   First the client attaches both buffers, then it will call
   PDCCMD_RASTERIZE.
   A good response is:
      PDCCMD_ACK

PDCMD_QUERY_INPUT_FORMATS
   This command returns a space separeted list of valid input formats for the
   current device.  They are as follows:
      bitmap       - Data is a series of bitblts.
      text         - Data is plain text file.
      text-unicode - Data is plain text file in unicode format.
      postscript   - Data is a postscript file.
      rawdata      - Data is a printer control language.

PDCMD_SET_INPUT_FORMAT format

Job Information
---------------

This section is for applications to query information about the
windows equivalent presentation space.

PDCMD_IS_COLOR_PRINTER
   This command returns 1 if the printer can print in color and 0 if it
   cannot.
   A good response is:
      PDCCMD_ACK 1

PDCMD_HAS_HARDWARE_COPY
   This command returns 1 if the printer supports the number of copies as
   a hardware command.  If it is 1 then the job will only be sent once.
   A good response is:
      PDCCMD_ACK 1

PDCCMD_ TBD
   Query printable area.

PDCCMD_ TBD
   Font metric information.

PDCCMD_ TBD
   Resolution of the page.

Capabilities Information
------------------------

This section is for applications or dialog code that wants to know what
the capabilities are for a device.

PDCCMD_IS_ORIENTATION_SUPPORTED id
PDCCMD_IS_FORM_SUPPORTED id
PDCCMD_IS_TRAY_SUPPORTED id
PDCCMD_IS_MEDIA_SUPPORTED id
PDCCMD_IS_RESOLUTION_SUPPORTED id
PDCCMD_IS_PRINT_MODE_SUPPORTED id
   This says if an id is supported for the current printer that has been
   associated to the communications.
   A good response is:
      PDCCMD_ACK

proposed replacement:

PDCCMD_IS_KEY_VALUE_SUPPORTED "key=value"
   This says if a key/value pair is supported for the current printer that
   has been associated to the communications.
   A good response is:
      PDCCMD_ACK

PDCCMD_TRANSLATE_KEY_VALUE "key=value"
   This will translate a key/value pair into a translated text message in
   the current language.
   A good response is:
      PDCCMD_ACK "text"

Bidirectional information
-------------------------

PDCCMD_QUERY_BIDI_STATUS
   This command returns an integer status that corresponds to the following list:

   900 - 999: Developer Specific Status Codes
   ------------------------------------------

   850 - 899: Print Device Operational Specific Status Codes
   ---------------------------------------------------------
   850 - Printer is not available

   860 - Printer is offline
   861 - Printer is busy
   862 - Printer has been paused by user
   863 - Printer has been resumed by user
   864 - A generic printer error ocurred
   865 - Printer top cover is open

   870 - Printer communication problem
   871 - Printer requesting servicing by user

   800 - 849: Print Device Paper Specific Status Codes
   ---------------------------------------------------
   800 - Printer is out-of-paper
   801 - Paper is jammed in printer

   750 - 799: Print Device Ink Specific Status Codes
   -------------------------------------------------
   750 - Black ink level is low
   751 - Color ink level is low
   752 - Cyan ink level is low
   753 - Magenta ink level is low
   754 - Yellow ink level is low
   755 - Light Cyan ink level is low
   756 - Light Magenta ink level is low

   760 - Out of Black ink
   761 - Out of Color ink
   762 - Out of Cyan ink
   763 - Out of Magenta ink
   764 - Out of Yellow ink
   765 - Out of Light Cyan ink
   766 - Out of Light Magenta ink

   770 - Black cartage is missing
   771 - Color cartage is missing
   772 - Cyan cartage is missing
   773 - Magenta cartage is missing
   774 - Yellow cartage is missing
   775 - Light Cyan cartage is missing
   776 - Light Magenta cartage is missing

   780 - Printer is cleaning ink cartage

   500 - 549: Job Specific Status Codes
   ------------------------------------
   500 - Print job has started
   501 - Print job has been completed
   502 - Print job has been canceled

   400 - 449: Page Specific Status Codes
   -------------------------------------
   400 - Printing the page has started
   401 - Printing the page has been completed
   402 - Printing the page was canceled

   100 - 149: Fatal and/or internal Specific Status Codes
   ------------------------------------------------------
   100 - A fatal error has occurred
   101 - An internal error has occurred

   000 - No error

   A good response is:
      PDCCMD_ACK 0

PDCCMD_TRANSLATE_BIDI_STATUS number
   This command takes a number and provides a translated text message in the
   current language.

   A good response is:
      PDCCMD_ACK "No error"

PDCCMD_QUERY_PRINTER_NAME
   This command returns the IEEE 1284 manufacturer and model strings.

Acknowledgements
----------------

Mark Hamzy     - ha...@us...
Till Kamppeter - til...@gm...
Robert Krawitz - rl...@al...
Glen Petrie    - gle...@ei...
David Suffield - dav...@hp...
Ben Woodard    - wo...@re...
Pete Zannucci  - pz...@us...

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] Re: [printing-cap] proposal of what features the communication to a printer driver should support

[Mark H. <ha...@us...>]

Hey Ben,

> Generally, it looks good. Do not take the number of my questions and
> comments as a sign of disapproval. I just want to fully understand
> what is going on here. I do think there are some rather big oversights
> and a few things we could do better but it does sound like a good
> place to start.

I don't mind at all.  At least you are reading it.

> Q1: I'm sort of assuming that this is more or less a IPC protocol
> between whatever backend part of the print system that wants the
> information that the driver has. Is that correct?

Yes.  This proposal was a direct result of the Inkjet mailing list's
call for a new inkjet printing architecture at:
   http://www.linuxprinting.org/pipermail/inkjet-list/2001q2/000001.html

> Comment1: If that is correct, as a weak personal opinion I would sort
> of like the IPC part of it abstracted away in the standard. I would
> like to have a C SPI or something like that rather than a raw network
> protocol. I don't care how this protocol is actually implemented on
> the back end. Some ideas that pop into mind are IPC. Creating a CORBA
> object. Loading a DLL.

Well, the files in omni (OmniPDCProxy.*) implement a C++ SPI which is
trivial to switch to a C SPI.

> Q2: How do I find the driver that I am supposed to talk to? Does this
> assume that you have bound a UNIX domain or inet socket?
>
> Q3: How do we support multiple drivers which implement the same
> interface? If we say that this is listening on port 5678 for example
> where do we put the other drivers?
>
> Q4: How is the driver run? If it is an inet driver you could put it in
> inetd.conf but it seems to me like this is more of a local domain
> socket kind of thing.

This has yet to be implemented.  I have no personal preference right
now and would like to consider different solutions.  One thing to keep
in mind, though, is that the omni driver has a pluggable blitter that
uses a stripped down version of PDC to talk to a blitter.  I don't
want the implementation to preclude this (app -> PDC -> omni -> pdc
-> blitter).

> Q4.1: From the capabilities subsystem point of view what happens. The
> user asks for the capabilities of X print queue. At the moment that
> the user does the query omni may or may not be active. Do I fork and
> exec omni and then connect to it's socket?

This will need to be handled by the print subsystem.  If a printer
driver is connected to a print queue, then some sort of daemon needs to
be spawned.

> Q4.2 What happens if it already running rendering a print job? Do I
> will I have to wait until the print job completes before this is
> taken care of?

No!  I envision a server ability to handle multiple streams at any
given time.  This way, the question of different print jobs active in
one stream goes away and becomes multiple streams.

> > PDCCMD_TERMINATE_SESSION
> >    Close the session.
> >    There is no response.
> >
>
> Comment 2: As a person who has been recently terminated. Terminate is
> such a strong word. ;-) End? Done? Complete?

Well, I was considering terminate with extreme prejudice. :-P  I can
change it to PDCCMD_CLOSE_SESSION.

> > PDCCMD_IS_CMD_SUPPORTED cmd
> >    This command exists so that a client can query if a server supports
a
> >    command.  This provides more information/granularity than the
version
> >    string.
> >    A good response is:
> >       PDCCMD_ACK
> >
> > Device management
> > -----------------
> >
> > PDCCMD_ENUM_DEVICES [PDLLevel PDLSubLevel PDLMajorRevisionLevel
PDLMinorRevisionLevel]
> >    Enumerate all supported devices that a printer driver supports.
> >    You can optionally pass in a set of PDL information to match
against.
> >    You receive a space separated list of device names.
> >    NOTE:  This can either the entire list or what subset is installed.
> >    A good response is:
> >       PDCCMD_ACK "Brother.Brother HJ-100i ..."
> >
>
> Q5: OK now we are to the point where I have a connection to omni. The
> spooler's configuration knows what kind of printer printer this is
> because it autodetected the printer by either reading IEEE-1284
> parallel port status readbacks, or doing a SNMP query of the device.

Well, that is one way to detect a device.  However, there is the simpler
case of assigning a printer driver to a queue through some configuration
entry.

> So I have a string which tells me what kind of device this is. I'm
> looking for one driver out of the many that are installed that support
> my printer. Will this support aliases to ensure that we can get an
> acceptable match?

I can add that to the proposal.  However, consider that I view an alias
as a "clone" of an existing device.  I add that as a new device name
in the printer driver.

> Q6: Do you think you could add a function where I can ask, "Do you
> support this kind of device?"

Yes.

> > PDCCMD_SET_DEVICE_NAME "DeviceName"
> >    Associate a device name to the communications.  This is a required
command
> >    for the rest of the following commands in this document.  This must
be
> >    the name of a supported device.
> >    A good response is:
> >       PDCCMD_ACK
> >
>
> Q7: From the interface it appears that this is one of the types
> returned from PDCCMD_ENUM_DEVICES. How do you associate a particular
> physical printing device with the printer properties that you are
> fetching so that you can get useful "printer properties" not just
> generic ones for that make and model of printer.

Well, there are two sets of storage for both printer properties and job
properties.  The first is compiled into the driver.  The second set is
stored somehow in configuration files.  The first set is considered
defaults if the second set does not exist.  After you have something to
initialize to, you then verfiy that that data is correct (example,
old data from previous version).

> > PDCCMD_GET_PDL_LEVEL
> > PDCCMD_GET_PDL_SUBLEVEL
> > PDCCMD_GET_PDL_MAJOR_REVISION_LEVEL
> > PDCCMD_GET_PDL_MINOR_REVISION_LEVEL
> >    Query a device's programatic language description. (PCL, ESC/P2, PS,
HG/GL).
> >    This of course is a proposal of a simple way to determine a printer
driver's
> >    language.
> >    NOTE:  This can allow spoolers to move jobs between similar print
queues.
> >    A good response is:
> >       PDCCMD_ACK integer
>
> Q8: Is there a way I can bulk up these requests and fetch all the
> information at once?

Sure.  I can change that.  I was just introducing people to the concept
of a PDL.

> Q9: These are basically what I was talking about in the
> capabilites discussion as the small amount of more or less static
> information. To more or less throw the agument that was thrown at me
> back at you. Do you believe that these are sufficient for all time or
> is there a possiblity that we may need more items at some time in the
> future? The ones that I inherited from the land of PPD's are:

Well, the commands in PDC will grow over time.  That was the reason for
the version strings and the PDCCMD_IS_CMD_SUPPORTED command.

> language_level;         // Language level of device
> color_device;           // 1 = color device, 0 = grayscale
> variable_sizes;         // 1 = supports variable sizes,0 = doesn't
> landscape;              // which way is landscape -90 or 90?
> model_number;           // Device-specific model number
> manual_copies;          // 1 = Copies done manually, 0 = hardware
> colorspace;             // Default colorspace
> lang_encoding;          // Language encoding
> lang_version;           // Language version (English, Spanish, etc.)
> modelname;              // Model name (general)
> manufacturer;           // Manufacturer name
> product;                // Product name (from PS RIP/interpreter)
> nickname;               // Nickname (specific)
> shortnickname;          // Short version of nickname
> custom_min[2];          // Minimum variable page size
> custom_max[2];          // Maximum variable page size
> custom_margins[4];      // Margins around page
>
>   << these are probably for PS only >>
> accurate_screens;       // 1 = supports accurate screens, 0 = not
> contone_only;           // 1 = continuous tone only, 0 = not
>
> Also:
> list of fonts_formats accepted; // bitstream, raster, TT, PS...
> list of installed fonts;
> list of available forms and their margins;
>
> Comment 3: I feel that your range of supported information is rather
> spartan. I realize that in many cases your driver won't know all this
> information and in those cases we can return a code that says that the
> information is not available but I think we should fill in as much
> information as we can on a best effort basis.

Ok.  We can work on that.

> >
> > Job Properties
> > --------------
>
> Q10: These seem to be what I would call device options as opposed to
> job properties. Am I missing something? These are things that you can
> specify with each page printed correct?

Job properties are properties that can change on a job-by-job (or
page-by-page) basis.

> > Drivers should support a set of core properties.  For example, at a
minimum,
> > a driver should support (note: this is only a sample):
> >    form
> >    media
> >    tray
> >    resolution
> >    orientation
> >    color/monochrome
>
> Comment 4: In my opinion. This is different than what I have
> above. What I have above is "does this device even have the capability
> to do color". What you have here is "make the device go into color mode".

Yes.  We should differentiate beteween the ability to go into color mode
and the fact that this page is in color.

> > For the core properties, a driver should support a set of standardized
> > selections.  This will help in moving jobs between different printer
> > drivers that support a printer.  For example:
> >    form
> >       Here is a sample proposal from IPP/UPDF/UPnP.
> >         na_letter_8.5x11in
> >         na_legal_8.5x14in
> >         iso_a3_297x420mm
> >         jis_b4_257x364mm
> >         jpn_hagaki_100x148mm
> >       It has some good points to it:
> >         All forms have a name to it.  If, in the future, a new form is
> >           created, then a program would not know how to call a form
> >           that was selected with only its size (6.12x7.59 is called
what?).
> >         More information is returned.  The size of the form is returned
> >           with the name.
> >       Some bad points are:
> >         Hard copy clipping information should also be returned.
>
> Comment 5: This is why forms are listed in the static information
> area. In the static information area. This makes it possible to have a
> richer data structure for forms. They are not only enumerated but they
> have limit information associated with them. What you have here in the
> "job properties" or device options section is subtlely different than
> what I have in the static information section in much the same way as
> the two forms of color are differnt. The forms section of static
> information says what the device can do. The forms section of the
> device options, allows someone to select the form that they want to
> use.

I think that your terminology of static information matches my
terminology of printer properties and job information.

> >    media
> >      Here is a sample proposal from UPDF
> >        stationery
> >        stationery-coated
> >        stationery-inkjet
> >        stationery-preprinted
> >
> > The driver should also have a set of driver specific properties.
>
> Q11: Many of these options including the forms and the media are going
> to have two forms. One that is used internally to communicate between
> the various components of the print system, like the ones that you
> specified above and one that will be more human readable to be
> presented to the user. Where do I get the strings that I present to
> the user in a dialog box?
>
> Q12: How do I specify what localization the user wants the strings in?
> Or are you going to pass me back all the human readable strings in all
> the available translations.

That was in the todo section of the version 3 document and is easily
implementable.  What I had envisioned was that you set a language and
then receive translatable strings in that language.

> Q13: How do I find out what localizations are available?

By querying them of course :).

> > PDCCMD_SET_JOB_PROPERTIES "JobProperties"
> >    Set the job properties for a session.  The job properties is a space
> >    separated list of key=value entries.
> >    NOTE: I think that all the properties should be set in one command.
I
> >          can envision scenarios where individual sets could paint the
> >          driver into a corner.
> >          There should be default job properties if some or none of the
> >          job properties are set.
> >    A good response is:
> >       PDCCMD_ACK
>
> Q14: Do you have to set all the properties at once or is this a merge
> kind of interface? If I only want to set only one option.
>
> Q15: If it is a merge kind of interface how do I delete a kv pair?
>
> Q16: Would you consider adding a function to set just one property?
>
> Q17: How do you handle properties which have spaces in their names?
>
> Q18: What do you do if particular set of properties more or less
> conflict with each other? Just ignore it?
>

Well, this is a set call.  It is recommended to set them all at once but
you can set just one as well.  The current defaults will supply the rest.
We can come up with a standard to specify properties.  If a space is used
to separate them, then it will have to be quoted some how to include it
in a value.

We can define how to handle conflicts.  Right now, it ignores them and
you requery what the current properties are.

> > PDCCMD_QUERY_CURRENT_JOB_PROPERTIES
> >    Query the current job properties.  This returns a list of common and
> >    driver specific job properties.
> >    NOTE: This can happen both before and after the job properties are
set.
> >    A good response is:
> >       PDCCMD_ACK "orientation=... form=... tray=... ..."
>
> Q19: One thing that PPD files do which I find very useful for
> organizing the user interface is they arrange the options into
> groups. Each group can have subgroups XOR it can have options in
> it. Can we add a layer of groups and subgroups to this?

Can you give examples?

> >
> > PDCCMD_LIST_JOB_PROPERTY_KEYS
> >    Enumerate the set of common job properties.  This returns a space
> >    separated list of key entries.
> >    A good response is:
> >       PDCCMD_ACK "orientation form tray ..."
> >
> > PDCCMD_LIST_DEVICE_JOB_PROPERTY_KEYS
> >    Enumerate the device specific job properties.  This returns a space
> >    separated list of key entries.
> >    A good response is:
> >       PDCCMD_ACK "scaling ..."
> >
> > PDCCMD_GET_JOB_PROPERTY key
> >    Enumerate the options for a job property.  This returns a space
> >    separated list of value entries.
> >    A good response is:
> >       PDCCMD_ACK "landscape portrait ..."
> >
> > PDCCMD_GET_JOB_PROPERTY_TYPE key
> >    Enumerate the type of a job property.  This returns the type
followed
> >    by the default optionally followed by the minimum range and the
maximum
> >    range.  The type can be the following: integer, string, float, or
> >    boolean.  This is only a proposal.  Comments are welcome.
> >    A good response is:
> >       PDCCMD_ACK "string portrait"
> >
>
> Comment 6: I like this.
>
> > Printer Properties
> > ------------------
> >
> > Drivers need to know about what optional features are installed for
> > a printer.
> >
>
> Q20: How do these printer optional features relate to the "job
> properties" listed above? In your implementation there doesn't seem to
> be any constraints. So how do thing work together? In PPD files, the
> information is in two places. For example, you have the "job property"
> of duplexing and you have the "printer property" of duplexer
> installed. A constraint joins those pieces of information by stating
> that a duplexer=no conflicts with duplex=true. I don't know how you
> can implement such things with your system.

Well you would have a context associated with the command.  For example,
   PDCCMD_SET_JOB_PROPERTIES "duplex=simplex"
   PDCCMD_SET_PRINTER_PROPERTIES "duplex=installed" (or whatever verb).

"installed" is not a valid job property.

> > Perhaps there can be a core set of printer properties.  For example,
> >    a duplexer is installed
> >    extra memory is installed
> >    an extra tray is installed or is configured to hold certain paper
> >
> > PDCCMD_SET_PRINTER_PROPERTIES "PrinterProperties"
> >    Set the printer properties.
> >    NOTE: I think that all the properties should be set in one command.
I
> >          can envision scenarios where individual sets could paint the
> >          driver into a corner.
> >          There should be default printer properties if some or none of
the
> >          printer properties are set.
>
> Q21: Can you please explain this point of view a little more? It seems
> non-sequiter to me. Is the first sentence related to the second one or
> do they just happen to be right next to each other.

I am a fan of setting everything at once.  I can imagine cases where
setting
individual keys could lead down a path that is different than setting
every key at once.
The second sentence implies that there is a set of default printer
properties that are active for the first time case.

> >    A good response is:
> >       PDCCMD_ACK
>
> Q22: Why can you set printer properties? It seems to me like this is
> something that you should get directly from the printer.

That assumes that the printer is always connected and always on and
that every printer supports a bidirectional interface to query that
information.  Yes, in the case that this information is available,
the printer driver should use it.  But I see that internal query as being
called during the installation of a printer driver to a system.

> > PDCCMD_QUERY_CURRENT_PRINTER_PROPERTIES
> >    Query the printer properties.  This returns a list of common and
> >    driver specific printer properties.
> >    NOTE: This can happen both before and after the printer properties
are
> >          set.
> >    A good response is:
> >       PDCCMD_ACK "duplexer=... memory=... ..."
> >
>
> Q23: I assume that you can and will query the printer device for these
> options. What happens if someone does a query of the printer but the
> printer is turned off or something like that? Does the call hang? Does
> it time out or what?

Bidirectional calls should have time outs.  However, you probably do
not need to speak to the device at all and just update your configuration
files.

> > PDCCMD_LIST_PRINTER_PROPERTY_KEYS
> >    Enumerate the common printer properties.  This returns a space
> >    separated list of key entries.
> >    A good response is:
> >       PDCCMD_ACK "duplexer memory ..."
> >
> > PDCCMD_LIST_DEVICE_PRINTER_PROPERTY_KEYS
> >    Enumerate the device specific printer properties.  This returns a
space
> >    separated list of key entries.
> >    A good response is:
> >       PDCCMD_ACK "stapler ..."
> >
> > PDCCMD_GET_PRINTER_PROPERTY key
> >    Enumerate the options for a printer property.  This returns a space
> >    separated list of value entries.
> >    A good response is:
> >       PDCCMD_ACK "on off ..."
> >
> > PDCCMD_GET_PRINTER_PROPERTY_TYPE key
> >    Enumerate the type of a printer property.  This returns the type
followed
> >    by the default optionally followed by the minimum range and the
maximum
> >    range.  The type can be the following: integer, string, float, or
> >    boolean.  This is only a proposal.  Comments are welcome.
> >    A good response is:
> >       PDCCMD_ACK "string on"
> >
> > Job Control
> > -----------
> >
> > PDCCMD_BEGIN_JOB
> >    Start a job.
> >    A good response is:
> >       PDCCMD_ACK
> >
>
> Q24: Say a program wants to use the driver to find out the device
> capabilities and communicate with the device but it wants to generate
> its own print data. There doesn't seem to be anywhere in this whole
> protocol where you provide a facility for an application to find out
> how to access the particular features. Is there any plan to make that
> available?

There is a way to send raw data.  Are you asking for a way to query
printer commands for particular features?  In that case, it sounds
like the application wants to be a printer driver.

> Q25: I don't really follow the flow here. Is this socket or whatever
> it is also the socket that you use to pass print data?

Yes.  All communication to the printer driver is done through the PDC.

> > PDCCMD_START_PAGE
> >    Start a page.
> >    NOTE: You can optionally change the properties for the page by
calling
> >          PDCCMD_SET_JOB_PROPERTIES "JobProperties" before this command.
> >    A good response is:
> >       PDCCMD_ACK
>
> Q26: Some options only make sense at at job or document
> boundries. Others are completely fine anywhere. In your getting and
> setting of properties the information of where particular properties
> are reasonable is lost.

That is up to the printer driver to manage that.  By definition, a job
property is something that can change between jobs or pages.  Right now,
the common job properties can change for every page.  Obviously, if you
change duplexing, it may take a page to kick in.

> > PDCCMD_END_PAGE
> >    End a page.
> >    A good response is:
> >       PDCCMD_ACK
> >
> > PDCCMD_END_JOB
> >    End a job.
> >    A good response is:
> >       PDCCMD_ACK
> >
> > PDCCMD_ABORT_PAGE
> >    Abort a page.
> >    NOTE: This is optional.  If this fails then one must abort the
> >          entire page.
> >    A good response is:
> >       PDCCMD_ACK
> >
> > PDCCMD_ABORT_JOB
> >    Abort a job.
> >    NOTE: This is required.
> >    A good response is:
> >       PDCCMD_ACK
> >
> > Job Data
> > --------
> >
> > Here is where you have to ask yourself:  Are you a graphics engine
> > that is talking to a printer driver or are you an application that
> > is talking to a printer driver.
> >
> > If you are a graphics engine, then you will want to allow the
> > device to accelerate high level commands (Ex: drawing a box with
rounded
> > corners).  Every command that is not supported at a high level will be
> > rasterized into a series of banded bitmaps and then sent down to the
> > device.  It should be drawn into the bitmap format that the device
> > wants  (Ex: RGB, CMYK, CcMmYK; 1, 8, 24 bits per pel; 8 or 32 bit scan
> > line aligned; top or bottom orientation; etc).
> >
>
> Q27: So if I were just interested in the device's capabilities. I
> would have terminated by this point? The driver doesn't get upset if I
> connect to it and then not send a print job.

No!  Not at all.  If fact, code that will pop up a dialog of job
properties can quit now as well if it is saving defaults for the
application.

> Q28: Can multiple people connect to it simultaneously? e.g. a print
> data job and a capabilities query.

Yes!  Most definately!

> Q29: Where would we insert a color correction profile?

That will be added to the standard when a good nomination is made.

> > If you are an application, you want to print simply.  Some examples
are:
> >    a series (1 or more) of bitmaps of any color depth
> >    postscript commands
> >    printer specific data
> >    plain text
> >
> > PDCCMD_MODE_IS_RENDERER boolean
> >    This command indentifies to the printer driver that a renderer is
> >    talking to it.  This command is optional.  The default is false
> >    (an application is talking to it).
> >    A good response is:
> >       PDCCMD_ACK
> >
> > PDCCMD_ATTACH_BUFFER1 id
> > PDCCMD_ATTACH_BUFFER2 id
> > PDCCMD_DETACH_BUFFER1 id
> > PDCCMD_DETACH_BUFFER2 id
> > PDCCMD_RASTERIZE
> >    These commands are shared for printing a series (1 or more) of
bitmaps
> >    of any color depth and for a series of banded bitmaps of the page.
> >    The first is a structure that describes the bitmap data.  It
contains:
> >       cx             - the width of the bitmap data
> >       cy             - the height of the bitmap data
> >       cPlanes        - the number of planes in the bitmap
> >       cBitCount      - the color depth of the bitmap
> >       ulCompresstion - the compression of the bitmap data
> >       cclrUsed       - the number of colors used in the bitmap
> >       cclrImportant  - the number of colors that are important
> >       argbColor      - the color table if there is one
> >       We should add a bitmap type field that contains the alignment
> >       and direction.
> >    The second contains the bits of the bitmap.
> >    First the client attaches both buffers, then it will call
> >    PDCCMD_RASTERIZE.
> >    A good response is:
> >       PDCCMD_ACK
> >
> > Job Information
> > ---------------
> >
> > PDCCMD_ TBD
> >    Query printable area.
> >
> > PDCCMD_ TBD
> >    Font metric information.
> >
> > PDCCMD_ TBD
> >    Resolution of the page.
> >
>
> Comment 7: I would put these above in the static information section.
>
> > Capabilities Information
> > ------------------------
> >
> > This section is for applications or dialog code that wants to know what
> > the capabilities are for a device.
> >
> > PDCCMD_IS_ORIENTATION_SUPPORTED id
> > PDCCMD_IS_FORM_SUPPORTED id
> > PDCCMD_IS_TRAY_SUPPORTED id
> > PDCCMD_IS_MEDIA_SUPPORTED id
> > PDCCMD_IS_RESOLUTION_SUPPORTED id
> > PDCCMD_IS_PRINT_MODE_SUPPORTED id
> >    This says if an id is supported for the current printer that has
been
> >    associated to the communications
> >    A good response is:
> >       PDCCMD_ACK
> >
>
> Comment 7: I think that we need a better interface on this.

How about PDCCMD_IS_KEY_VALUE_SUPPORTED "key=value" ?

> > Bidirectional information
> > -------------------------
> >
> > PDCCMD_ TBD
> >    Error reporting.  (Printer offline, busy, out of ink)
> >
> > PDCCMD_ TBD
> >    Device reporting.  (Printer name)
> >
>
> I wondered when you would get to this...
>
> My big complaints are:
> 1) No human readable strings.
> 2) No internationalization support
> 3) Not enough static information
> 4) No way to group the device options.
> 5) No constraints to join device options and document options
>
> With a little more information I can start implementing to this. ;-)

We can work on this.

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] proposal(2) of what features the communication to a printer driver should support

[Mark H. <ha...@us...>]

Here is version 3 of a proposal of what features the communication
to a printer driver should support.

I propose to call this communication PDC for Printer Driver Communication.

If you want to start coding testcases, the omni driver supports this
proposal.  The source code is freely available and is located at
http://www.sourceforge.net/projects/omniprint/ under the following files:
   OmniServer.[hc]pp, OmniPDCProxy.[hc]pp, DeviceTester8.cpp,
   PrinterCommand.[hc]pp

What license should this code be under?  We can rerelease it under any
license that the group decides.

I also propose that an equivalent linked library version of this
communication format be defined.  This should be easy to create if the
group agrees.

todo -
   define input formats (text, bitblt, ...) and raster formats.
   define client translateable language selection
   add more informational stuff to form name (selectable)

Structure of Message Block
--------------------------

Packets are variably-lengthed.  They will always contain the command, size
of the packet, and the type of the variable data.

typedef enum _PrinterDriverCommunicationCommand {
   PDCCMD_ACK = 1,
   ...
} PDC_CMD, *PPDC_CMD;

typedef enum _PrinterDriverCommunicationFormat {
   PDCFMT_NULL = 1,
   PDCFMT_STRING,
   PDCFMT_BINARY,
   PDCFMT_INTEGER,
   PDCFMT_LONG
} PDC_FMT, *PPDC_FMT;

typedef struct _PrinterDriverCommunicationPacket {
   PDC_CMD eCommand;          // Printer Driver Command
   size_t  cbLength;          // Length of this packet
   PDC_FMT eFormat;           // Type of the following data
   char    achCommandLine[1]; // Start of data
} __attribute__ ((aligned (1))) __attribute__ ((packed))
  PDC_PACKET, *PPDC_PACKET;

Session management
------------------

PDCCMD_INITIALIZE_SESSION "Version"
   The first command should be a hand-shaking of the versions.
   A good response is:
      PDCCMD_ACK "Version"

PDCCMD_TERMINATE_SESSION
   Close the session.
   There is no response.

PDCCMD_IS_CMD_SUPPORTED cmd
   This command exists so that a client can query if a server supports a
   command.  This provides more information/granularity than the version
   string.
   A good response is:
      PDCCMD_ACK

Device management
-----------------

PDCCMD_ENUM_DEVICES [PDLLevel PDLSubLevel PDLMajorRevisionLevel PDLMinorRevisionLevel]
   Enumerate all supported devices that a printer driver supports.
   You can optionally pass in a set of PDL information to match against.
   You receive a nul-terminated separated list of device names.
   NOTE:  This can either the entire list or what subset is installed.
   A good response is:
      PDCCMD_ACK "Brother.Brother HJ-100i\0...Star.Star ZA-250 Multi-Font\0\0"

PDCCMD_SET_DEVICE_NAME "DeviceName"
   Associate a device name to the communications.  This is a required command
   for the rest of the following commands in this document.  This must be
   the name of a supported device.
   A good response is:
      PDCCMD_ACK

PDCCMD_GET_PDL_LEVEL
PDCCMD_GET_PDL_SUBLEVEL
PDCCMD_GET_PDL_MAJOR_REVISION_LEVEL
PDCCMD_GET_PDL_MINOR_REVISION_LEVEL
   Query a device's programatic language description. (PCL, ESC/P2, PS, HG/GL).
   This of course is a proposal of a simple way to determine a printer driver's
   language.
   NOTE:  This can allow spoolers to move jobs between similar print queues.
   A good response is:
      PDCCMD_ACK integer

Job Properties
--------------

Drivers should support a set of core properties.  For example, at a minimum,
a driver should support (note: this is only a sample):
   form
   media
   tray
   resolution
   orientation
   color/monochrome

For the core properties, a driver should support a set of standardized
selections.  This will help in moving jobs between different printer
drivers that support a printer.  For example:

   form
      Some examples are:
         na_letter_8.5x11x0.1x0.1x0.1x0.1in
         na_legal_8.5x14x0x0x0x0in
         iso_a3_297x420x0.12x0.08x0x0mm
         jis_b4_257x364x1x2x1x1mm
         jpn_hagaki_100x148x0x0x1x1mm
      The first part is the only part that is required to set the form.
         It consists of a prefix (na - north america, iso - international
         standards organization, jis - japan industrial standard, jpn -
         japan, prc - people's republic of china) followed by an
         underscore followed by the form name followed by an underscore.
      The rest is optional and is of an informational nature.  It
         consists of 6 numbers as follows:  width, height, left, top,
         right, and bottom unprintable margins.  Following this is
         the suffix of the units of measure (in - inches, mm -
         millimeters).

       A printer driver may allow a short-cut of not requiring the prefix
         to select the form.  An example would be "form=letter".
         However, it does not guarantee an exact match and the result is
            undefined.  Some conflicting names are jis_b4 vs iso_b4,
            iso_a2 vs na_a2, iso_c5 vs na_c5, and prc_16k vs roc_16k.

   media
      Some examples are:
         stationery
         stationery-coated
         stationery-inkjet
         stationery-preprinted
         stationery-letterhead
         stationery-prepunched
         stationery-fine
         stationery-heavyweight
         stationery-lightweight
         transparency
         envelope
         envelope-plain
         envelope-window
         continuous
         continuous-long
         continuous-short
         tab-stock
         pre-cut-tabs
         full-cut-tabs
         multi-part-form
         labels
         multi-layer
         screen
         screen-paged
         photographic
         photographic-glossy
         photographic-high-gloss
         photographic-semi-gloss
         photographic-satin
         photographic-matte
         photographic-film
         back-print-film
         cardstock
         roll

   tray

   resolution
      Resolution is either given as two integers separated by an 'x' or one
        integer.  In the second case, the resolution is considered square or
        equal.  Some examples are 1440x720, 300x300, or 600.

      There can be a word that will associate to a resolution to make life
        simpler to users.  For example: draft, fine, group-3, group-4, high,
        low, medium, normal, photo-quality, and presentation.  These are
        considered non-standard and driver dependant.

   orientation
      The choices are:
         portrait
         landscape
         reverse-portrait
         reverse-landscape

   color
      This is used to select between monochrome or color.  The choices are:
         monochrome
         color

The driver should also have a set of driver specific properties.

PDCCMD_SET_JOB_PROPERTIES "JobProperties"
   Set the job properties for a session.  The job properties is a space
   separated list of key=value entries.
   NOTE: I think that all the properties should be set in one command.  I
         can envision scenarios where individual sets could paint the
         driver into a corner.
         There should be default job properties if some or none of the
         job properties are set.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_JOB_PROPERTIES
   Query the current job properties.  This returns a list of common and
   driver specific job properties.
   NOTE: This can happen both before and after the job properties are set.
   A good response is:
      PDCCMD_ACK "orientation=... form=... tray=... ..."

PDCCMD_LIST_JOB_PROPERTY_KEYS
   Enumerate the set of common job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "orientation form tray ..."

PDCCMD_LIST_DEVICE_JOB_PROPERTY_KEYS
   Enumerate the device specific job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "scaling ..."

PDCCMD_GET_JOB_PROPERTY key
   Enumerate the options for a job property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "landscape portrait ..."

PDCCMD_GET_JOB_PROPERTY_TYPE key
   Enumerate the type of a job property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string portrait"

Printer Properties
------------------

Drivers need to know about what optional features are installed for
a printer.

Perhaps there can be a core set of printer properties.  For example,
   a duplexer is installed
   extra memory is installed
   an extra tray is installed or is configured to hold certain paper

PDCCMD_SET_PRINTER_PROPERTIES "PrinterProperties"
   Set the printer properties.
   NOTE: I think that all the properties should be set in one command.  I
         can envision scenarios where individual sets could paint the
         driver into a corner.
         There should be default printer properties if some or none of the
         printer properties are set.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_PRINTER_PROPERTIES
   Query the printer properties.  This returns a list of common and
   driver specific printer properties.
   NOTE: This can happen both before and after the printer properties are
         set.
   A good response is:
      PDCCMD_ACK "duplexer=... memory=... ..."

PDCCMD_LIST_PRINTER_PROPERTY_KEYS
   Enumerate the common printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "duplexer memory ..."

PDCCMD_LIST_DEVICE_PRINTER_PROPERTY_KEYS
   Enumerate the device specific printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "stapler ..."

PDCCMD_GET_PRINTER_PROPERTY key
   Enumerate the options for a printer property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "on off ..."

PDCCMD_GET_PRINTER_PROPERTY_TYPE key
   Enumerate the type of a printer property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string on"

Job Control
-----------

PDCCMD_BEGIN_JOB
   Start a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_START_PAGE
   Start a page.
   NOTE: You can optionally change the properties for the page by calling
         PDCCMD_SET_JOB_PROPERTIES "JobProperties" before this command.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_PAGE
   End a page.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_JOB
   End a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_PAGE
   Abort a page.
   NOTE: This is optional.  If this fails then one must abort the
         entire page.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_JOB
   Abort a job.
   NOTE: This is required.
   A good response is:
      PDCCMD_ACK

Job Data
--------

Here is where you have to ask yourself:  Are you a graphics engine
that is talking to a printer driver or are you an application that
is talking to a printer driver.

If you are a graphics engine, then you will want to allow the
device to accelerate high level commands (Ex: drawing a box with rounded
corners).  Every command that is not supported at a high level will be
rasterized into a series of banded bitmaps and then sent down to the
device.  It should be drawn into the bitmap format that the device
wants  (Ex: RGB, CMYK, CcMmYK; 1, 8, 24 bits per pel; 8 or 32 bit scan
line aligned; top or bottom orientation; etc).

If you are an application, you want to print simply.  Some examples are:
   a series (1 or more) of bitmaps of any color depth at any position
     on the page.
   postscript commands
   printer specific data - do not modify this data stream at all!
   plain text

PDCCMD_MODE_IS_RENDERER boolean
   This command indentifies to the printer driver that a renderer is
   talking to it.  This command is optional.  The default is false
   (an application is talking to it).
   A good response is:
      PDCCMD_ACK

PDCCMD_ATTACH_BUFFER1 id
PDCCMD_ATTACH_BUFFER2 id
PDCCMD_DETACH_BUFFER1 id
PDCCMD_DETACH_BUFFER2 id
PDCCMD_RASTERIZE
   These commands are shared for printing a series (1 or more) of bitmaps
   of any color depth and for a series of banded bitmaps of the page.
   The first is a structure that describes the bitmap data.  It contains:
      cx             - the width of the bitmap data
      cy             - the height of the bitmap data
      cPlanes        - the number of planes in the bitmap
      cBitCount      - the color depth of the bitmap
      ulCompresstion - the compression of the bitmap data
      cclrUsed       - the number of colors used in the bitmap
      cclrImportant  - the number of colors that are important
      argbColor      - the color table if there is one
      We should add a bitmap type field that contains the alignment
      and direction.
   The second contains the bits of the bitmap.
   First the client attaches both buffers, then it will call
   PDCCMD_RASTERIZE.
   A good response is:
      PDCCMD_ACK

Job Information
---------------

This section is for applications to query information about the
windows equivalent presentation space.

PDCCMD_ TBD
   Query printable area.

PDCCMD_ TBD
   Font metric information.

PDCCMD_ TBD
   Resolution of the page.

Capabilities Information
------------------------

This section is for applications or dialog code that wants to know what
the capabilities are for a device.

PDCCMD_IS_ORIENTATION_SUPPORTED id
PDCCMD_IS_FORM_SUPPORTED id
PDCCMD_IS_TRAY_SUPPORTED id
PDCCMD_IS_MEDIA_SUPPORTED id
PDCCMD_IS_RESOLUTION_SUPPORTED id
PDCCMD_IS_PRINT_MODE_SUPPORTED id
   This says if an id is supported for the current printer that has been
   associated to the communications.
   A good response is:
      PDCCMD_ACK

Bidirectional information
-------------------------

PDCCMD_ TBD
   Error reporting.  (Printer offline, busy, out of ink)

PDCCMD_ TBD
   Device reporting.  (Printer name)

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] proposal of what features the communication to a printer driver should support

[Mark H. <ha...@us...>]

Here is the second revision of a proposal of what features the communication
to a printer driver should support.

I propose to call this communication PDC for Printer Driver Communication.

If you want to start coding testcases, the omni driver supports this
proposal.  The source code is freely available and is located at
http://www.sourceforge.net/projects/omniprint/ under the following files:
   OmniServer.[hc]pp, OmniPDCProxy.[hc]pp, DeviceTester8.cpp,
   PrinterCommand.[hc]pp

What license should this code be under?  We can rerelease it under any
license that the group decides.

I also propose that an equivalent linked library version header file of this
communication format be defined.  This should be easy to create if the
group agrees.

Session management
------------------

PDCCMD_INITIALIZE_SESSION "Version"
   The first command should be a hand-shaking of the versions.
   A good response is:
      PDCCMD_ACK "Version"

PDCCMD_TERMINATE_SESSION
   Close the session.
   There is no response.

PDCCMD_IS_CMD_SUPPORTED cmd
   This command exists so that a client can query if a server supports a
   command.  This provides more information/granularity than the version
   string.
   A good response is:
      PDCCMD_ACK

Device management
-----------------

PDCCMD_ENUM_DEVICES [PDLLevel PDLSubLevel PDLMajorRevisionLevel PDLMinorRevisionLevel]
   Enumerate all supported devices that a printer driver supports.
   You can optionally pass in a set of PDL information to match against.
   You receive a space separated list of device names.
   NOTE:  This can either the entire list or what subset is installed.
   A good response is:
      PDCCMD_ACK "Brother.Brother HJ-100i ..."

PDCCMD_SET_DEVICE_NAME "DeviceName"
   Associate a device name to the communications.  This is a required command
   for the rest of the following commands in this document.  This must be
   the name of a supported device.
   A good response is:
      PDCCMD_ACK

PDCCMD_GET_PDL_LEVEL
PDCCMD_GET_PDL_SUBLEVEL
PDCCMD_GET_PDL_MAJOR_REVISION_LEVEL
PDCCMD_GET_PDL_MINOR_REVISION_LEVEL
   Query a device's programatic language description. (PCL, ESC/P2, PS, HG/GL).
   This of course is a proposal of a simple way to determine a printer driver's
   language.
   NOTE:  This can allow spoolers to move jobs between similar print queues.
   A good response is:
      PDCCMD_ACK integer

Job Properties
--------------

Drivers should support a set of core properties.  For example, at a minimum,
a driver should support (note: this is only a sample):
   form
   media
   tray
   resolution
   orientation
   color/monochrome

For the core properties, a driver should support a set of standardized
selections.  This will help in moving jobs between different printer
drivers that support a printer.  For example:
   form
      Here is a sample proposal from IPP/UPDF/UPnP.
        na_letter_8.5x11in
        na_legal_8.5x14in
        iso_a3_297x420mm
        jis_b4_257x364mm
        jpn_hagaki_100x148mm
      It has some good points to it:
        All forms have a name to it.  If, in the future, a new form is
          created, then a program would not know how to call a form
          that was selected with only its size (6.12x7.59 is called what?).
        More information is returned.  The size of the form is returned
          with the name.
      Some bad points are:
        Hard copy clipping information should also be returned.
   media
     Here is a sample proposal from UPDF
       stationery
       stationery-coated
       stationery-inkjet
       stationery-preprinted

The driver should also have a set of driver specific properties.

PDCCMD_SET_JOB_PROPERTIES "JobProperties"
   Set the job properties for a session.  The job properties is a space
   separated list of key=value entries.
   NOTE: I think that all the properties should be set in one command.  I
         can envision scenarios where individual sets could paint the
         driver into a corner.
         There should be default job properties if some or none of the
         job properties are set.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_JOB_PROPERTIES
   Query the current job properties.  This returns a list of common and
   driver specific job properties.
   NOTE: This can happen both before and after the job properties are set.
   A good response is:
      PDCCMD_ACK "orientation=... form=... tray=... ..."

PDCCMD_LIST_JOB_PROPERTY_KEYS
   Enumerate the set of common job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "orientation form tray ..."

PDCCMD_LIST_DEVICE_JOB_PROPERTY_KEYS
   Enumerate the device specific job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "scaling ..."

PDCCMD_GET_JOB_PROPERTY key
   Enumerate the options for a job property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "landscape portrait ..."

PDCCMD_GET_JOB_PROPERTY_TYPE key
   Enumerate the type of a job property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string portrait"

Printer Properties
------------------

Drivers need to know about what optional features are installed for
a printer.

Perhaps there can be a core set of printer properties.  For example,
   a duplexer is installed
   extra memory is installed
   an extra tray is installed or is configured to hold certain paper

PDCCMD_SET_PRINTER_PROPERTIES "PrinterProperties"
   Set the printer properties.
   NOTE: I think that all the properties should be set in one command.  I
         can envision scenarios where individual sets could paint the
         driver into a corner.
         There should be default printer properties if some or none of the
         printer properties are set.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_PRINTER_PROPERTIES
   Query the printer properties.  This returns a list of common and
   driver specific printer properties.
   NOTE: This can happen both before and after the printer properties are
         set.
   A good response is:
      PDCCMD_ACK "duplexer=... memory=... ..."

PDCCMD_LIST_PRINTER_PROPERTY_KEYS
   Enumerate the common printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "duplexer memory ..."

PDCCMD_LIST_DEVICE_PRINTER_PROPERTY_KEYS
   Enumerate the device specific printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "stapler ..."

PDCCMD_GET_PRINTER_PROPERTY key
   Enumerate the options for a printer property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "on off ..."

PDCCMD_GET_PRINTER_PROPERTY_TYPE key
   Enumerate the type of a printer property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string on"

Job Control
-----------

PDCCMD_BEGIN_JOB
   Start a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_START_PAGE
   Start a page.
   NOTE: You can optionally change the properties for the page by calling
         PDCCMD_SET_JOB_PROPERTIES "JobProperties" before this command.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_PAGE
   End a page.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_JOB
   End a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_PAGE
   Abort a page.
   NOTE: This is optional.  If this fails then one must abort the
         entire page.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_JOB
   Abort a job.
   NOTE: This is required.
   A good response is:
      PDCCMD_ACK

Job Data
--------

Here is where you have to ask yourself:  Are you a graphics engine
that is talking to a printer driver or are you an application that
is talking to a printer driver.

If you are a graphics engine, then you will want to allow the
device to accelerate high level commands (Ex: drawing a box with rounded
corners).  Every command that is not supported at a high level will be
rasterized into a series of banded bitmaps and then sent down to the
device.  It should be drawn into the bitmap format that the device
wants  (Ex: RGB, CMYK, CcMmYK; 1, 8, 24 bits per pel; 8 or 32 bit scan
line aligned; top or bottom orientation; etc).

If you are an application, you want to print simply.  Some examples are:
   a series (1 or more) of bitmaps of any color depth
   postscript commands
   printer specific data
   plain text

PDCCMD_MODE_IS_RENDERER boolean
   This command indentifies to the printer driver that a renderer is
   talking to it.  This command is optional.  The default is false
   (an application is talking to it).
   A good response is:
      PDCCMD_ACK

PDCCMD_ATTACH_BUFFER1 id
PDCCMD_ATTACH_BUFFER2 id
PDCCMD_DETACH_BUFFER1 id
PDCCMD_DETACH_BUFFER2 id
PDCCMD_RASTERIZE
   These commands are shared for printing a series (1 or more) of bitmaps
   of any color depth and for a series of banded bitmaps of the page.
   The first is a structure that describes the bitmap data.  It contains:
      cx             - the width of the bitmap data
      cy             - the height of the bitmap data
      cPlanes        - the number of planes in the bitmap
      cBitCount      - the color depth of the bitmap
      ulCompresstion - the compression of the bitmap data
      cclrUsed       - the number of colors used in the bitmap
      cclrImportant  - the number of colors that are important
      argbColor      - the color table if there is one
      We should add a bitmap type field that contains the alignment
      and direction.
   The second contains the bits of the bitmap.
   First the client attaches both buffers, then it will call
   PDCCMD_RASTERIZE.
   A good response is:
      PDCCMD_ACK

Job Information
---------------

PDCCMD_ TBD
   Query printable area.

PDCCMD_ TBD
   Font metric information.

PDCCMD_ TBD
   Resolution of the page.

Capabilities Information
------------------------

This section is for applications or dialog code that wants to know what
the capabilities are for a device.

PDCCMD_IS_ORIENTATION_SUPPORTED id
PDCCMD_IS_FORM_SUPPORTED id
PDCCMD_IS_TRAY_SUPPORTED id
PDCCMD_IS_MEDIA_SUPPORTED id
PDCCMD_IS_RESOLUTION_SUPPORTED id
PDCCMD_IS_PRINT_MODE_SUPPORTED id
   This says if an id is supported for the current printer that has been
   associated to the communications
   A good response is:
      PDCCMD_ACK

Bidirectional information
-------------------------

PDCCMD_ TBD
   Error reporting.  (Printer offline, busy, out of ink)

PDCCMD_ TBD
   Device reporting.  (Printer name)

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] Re: [printing-discuss] RE: [printing-driver] proposal of what features the communication toaprinter driver should support

[Till K. <til...@gm...>]

In case of the ink running out, the current page should be repeated 
after replacing the cartridges, if one prints Duplex an already printed 
back side must be repeated, too. Or one must declare the cartridge empty 
  when it still contais a little rest of ink, to avoid that it runs out 
in the middle of the page. The threashold to declare a cartridge as 
empty should perhaps depend on the paper size of the printer/the current 
page or even on the bitmap of the current page, especially for 
large-format printers (Epson Stylus Pro 10000 and so). One could even 
consider this separately for all the colors (C, M, Y, K, c, m). One 
could perhaps even hold a job when it comes to a page for which the 
current cartridges have not enough ink any more and let a job with a 
smaller paper size/ink density pass by.

    Till


Glen Petrie wrote:

> Actually, for out of ink or out of paper scenarios, you do not abort the
> job at all.  The printer is usually offline in those cases.  How about
> the ability to restart a job at a certain page?  I haven't come across
> a printer command that aborts a page, but I don't see the problem in
> providing both the ability to abort a job and abort a page.
> [glen]   Isn't restarting a job at a certain page more overhead for the
> print manager process than just stopping and sending the page in
> error/question.  And actually, to the driver the "restart job at a certain
> page" is just a new job (with less pages) since, based on the comment below,
> the driver never sees the entire job.    So this approach is supported by
> virtue of executing another job.
> 

[Omniprint-user] RE: [printing-driver] proposal of what features the communication toaprinter driver should support

[Glen P. <gle...@ei...>]

> [glen] Isn't the question of "query the language" a question to the
driver
> about the input format the driver accepts?   So for PS, PCL, HG/GL this
are
> input languages that drivers accept; but, ESCP/2 is how the driver talks
to
> the printer not the "language" if accepts (except in pass through mode).
> In this context, wouldn't the possible range of "languages" be something
> like;
>
> Raw (I assume this means image data of some format)
> PS
> PCL
> HG/GL
> HTML
> XHTML-Print
> IPP

What I was talking about was the output language that the printer driver
uses.  But, yes, you do need both input and output languages.
I think that a driver cannot support input languages such as PS, PCL (which
has mulitple variants), and HP/GL without a helper program (such as
Ghostscript in the case of PS).
By the way, IPP is a protocol. [glen] Ops... got carried away...
> [glen] I hope you reconsider the abort-page.   Example; some print
manager
> process has defined a 200 page job and began a session with the driver.
> The driver has accepted the job, printed 199 pages and start page 200.
> The toner (ink, whatever) is reported out (or the paper is out) via the
> status/monitoring I/O channel from the driver to the print manager
process.
> Does the print manager process abort the entire job and restart or does
it
> abort the current page; wait for the problem to be resolved; then resend
> page 200 to complete the job.

Actually, for out of ink or out of paper scenarios, you do not abort the
job at all.  The printer is usually offline in those cases.  How about
the ability to restart a job at a certain page?  I haven't come across
a printer command that aborts a page, but I don't see the problem in
providing both the ability to abort a job and abort a page.
[glen]   Isn't restarting a job at a certain page more overhead for the
print manager process than just stopping and sending the page in
error/question.  And actually, to the driver the "restart job at a certain
page" is just a new job (with less pages) since, based on the comment below,
the driver never sees the entire job.    So this approach is supported by
virtue of executing another job.
> [glen] If the driver is managing the entire job - it received (or at
> least has means to access) all pages, then an API call for abort-page
> is not necessary since processing is done internally.

Well, every printer driver that I have seen is transitory.  At most, it
will have access to the current band or the current page.  Only if it
supports a high-end laserjet that has a disk drive could it see previous
pages.
[glen]  This is my understanding also.

> [glen]  I am not sure I understand the group's definition of a "print
> queue".    I think of a "print queue" as process that manages a set of
> similar "printer queues".   In other words, there can be any number of
> devices associated with a "print queue".  All of those devices have
> common capabilities.  In this example, the Epson Stylus Photo 780 and
> Canon S800 belong to the same "print queue" (each printer has their own
> "printer queue") while the Epson Stylus C80 would belong to a "print
> queue" consisting of 4-color inkjet printers.    The challenge is to
> define the classes of "print queues" - this may be doable by using the
> information from [printing-cap] sub-team effort.

Well, my definition of a print queue is a construct that allows multiple
print jobs to spool to one physical port (such as LPT1).  Since job
properties can be associated with a queue, you don't want different
drivers or devices on the same queue because they wont understand the
differences between the properties.
[glen] I guess I don't normally consider the connection (physical port) as
the discriminator for printer selection based on job properties.   I must
have a different conceptual model of job-queues, print-queues,
printer-queues and where drivers fit in.   I will reexamine the notes from
the summit meeting.


Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] RE: [printing-driver] proposal of what features the communication to aprinter driver should support

[Mark H. <ha...@us...>]

Hi Glen,

> [glen] Isn't the question of "query the language" a question to the
driver
> about the input format the driver accepts?   So for PS, PCL, HG/GL this
are
> input languages that drivers accept; but, ESCP/2 is how the driver talks
to
> the printer not the "language" if accepts (except in pass through mode).
> In this context, wouldn't the possible range of "languages" be something
> like;
>
> Raw (I assume this means image data of some format)
> PS
> PCL
> HG/GL
> HTML
> XHTML-Print
> IPP

What I was talking about was the output language that the printer driver
uses.  But, yes, you do need both input and output languages.
I think that a driver cannot support input languages such as PS, PCL (which
has mulitple variants), and HP/GL without a helper program (such as
Ghostscript in the case of PS).
By the way, IPP is a protocol.

> [glen] I hope you reconsider the abort-page.   Example; some print
manager
> process has defined a 200 page job and began a session with the driver.
> The driver has accepted the job, printed 199 pages and start page 200.
> The toner (ink, whatever) is reported out (or the paper is out) via the
> status/monitoring I/O channel from the driver to the print manager
process.
> Does the print manager process abort the entire job and restart or does
it
> abort the current page; wait for the problem to be resolved; then resend
> page 200 to complete the job.

Actually, for out of ink or out of paper scenarios, you do not abort the
job at all.  The printer is usually offline in those cases.  How about
the ability to restart a job at a certain page?  I haven't come across
a printer command that aborts a page, but I don't see the problem in
providing both the ability to abort a job and abort a page.

> [glen] If the driver is managing the entire job - it received (or at
> least has means to access) all pages, then an API call for abort-page
> is not necessary since processing is done internally.

Well, every printer driver that I have seen is transitory.  At most, it
will have access to the current band or the current page.  Only if it
supports a high-end laserjet that has a disk drive could it see previous
pages.

> [glen]  I am not sure I understand the group's definition of a "print
> queue".    I think of a "print queue" as process that manages a set of
> similar "printer queues".   In other words, there can be any number of
> devices associated with a "print queue".  All of those devices have
> common capabilities.  In this example, the Epson Stylus Photo 780 and
> Canon S800 belong to the same "print queue" (each printer has their own
> "printer queue") while the Epson Stylus C80 would belong to a "print
> queue" consisting of 4-color inkjet printers.    The challenge is to
> define the classes of "print queues" - this may be doable by using the
> information from [printing-cap] sub-team effort.

Well, my definition of a print queue is a construct that allows multiple
print jobs to spool to one physical port (such as LPT1).  Since job
properties can be associated with a queue, you don't want different
drivers or devices on the same queue because they wont understand the
differences between the properties.

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] RE: [printing-driver] proposal of what features the communication to aprinter driver should support

[Glen P. <gle...@ei...>]

   I still think that defining a programmatic way to query the
   language level is feasible.  The driver developers could come up
   with a structure that describes how the language is formatted.  But
   you are right in that it would be difficult and perhaps error
   prone.

We need to define what a language is, first.  For PCL (at least the
LaserJet version) and PostScript, it's reasonably well defined, and
generally useful.  Probably even for ESCP, although there's the matter
of 9-pin and 24-pin printers.  I'm just not sure what good "ESCP/2
Raster" would do as a printer language; it's useless for actually
generating output unless the precise printer model is known.

[glen] Isn=92t the question of =93query the language=94 a question to the=
 driver
about the input format the driver accepts?   So for PS, PCL, HG/GL this a=
re
input languages that drivers accept; but, ESCP/2 is how the driver talks =
to
the printer not the =93language=94 if accepts (except in pass through mod=
e).
In this context, wouldn=92t the possible range of =93languages=94 be some=
thing
like;

Raw (I assume this means image data of some format)
PS
PCL
HG/GL
HTML
XHTML-Print
IPP
. . . . . .

------------------------------------------------------------------------

> It seems like a weird concept to me.  With on-the-fly output
> generation, this can be done with most inkjets, but it still feels
> very strange to me.  With laser printers, this doesn't make a whole lot
> of sense at all, and even I have difficulty envisioning a situation
> where this would be useful.  In any event, aborting a page is
> something I think we should defer.

Yes.  I agree.  It was a weird concept for me as well.  Which is why
I chose to go with the abort job path.


[glen] I hope you reconsider the abort-page.   Example; some print manage=
r
process has defined a 200 page job and began a session with the driver.  =
The
driver has accepted the job, printed 199 pages and start page 200.   The
toner (ink, whatever) is reported out (or the paper is out) via the
status/monitoring I/O channel from the driver to the print manager proces=
s.
Does the print manager process abort the entire job and restart or does i=
t
abort the current page; wait for the problem to be resolved; then resend
page 200 to complete the job.

[glen] If the driver is managing the entire job =96 it received (or at le=
ast
has means to access) all pages, then an API call for abort-page is not
necessary since processing is done internally.

------------------------------------------------------------------------

But even if we're not talking about a raw file (and I seriously hope
we're not; those things are just too big!), I think we should take a
higher level look at what constitutes a "similar print queue" from the
user's perspective.  Suppose I have three printers:

  Epson Stylus Photo 780
  Canon S800
  Epson Stylus C80

Suppose the 780 is down, but there are some (non-raw) files queued for
it.  Which printer should they be diverted to?  It isn't clear.  Most
likely I would want to divert it to the S800 (which is a very high
quality, 6-color photo printer), not to the C80.  The reasoning -- and
this cannot be captured by knowing anything about the familial
resemblance -- is that the C80 is a fast 4-color printer, so if I'm
printing to the 780 I'm probably printing a smaller graphic with more
demanding quality requirements.

[glen]  I am not sure I understand the group=92s definition of a =93print=
 queue=94
.    I think of a =93print queue=94 as process that manages a set of simi=
lar
=93printer queues=94.   In other words, there can be any number of device=
s
associated with a =93print queue=94.   All of those devices have common
capabilities.  In this example, the Epson Stylus Photo 780 and Canon S800
belong to the same =93print queue=94 (each printer has their own =93print=
er
 queue=94) while the Epson Stylus C80 would belong to a =93print queue=94
consisting of 4-color inkjet printers.    The challenge is to define the
classes of =93print queues=94 =96 this may be doable by using the informa=
tion from
[printing-cap] sub-team effort.


Rgds,
Glen W. Petrie
Manager, Software Printing Solutions
Epson Imaging Technology Center
150 River Oaks Parkway, Suite 200
San Jose, CA, 95134
Voice: 408.576.4131  Fax: 408.474.0511