omniprint-developer — Discussion of the Omni driver by developers

[Omniprint-developer] 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-developer] 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-developer] 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-developer] 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-developer] 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

[Omniprint-developer] 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-developer] 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-developer] 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-developer] Re: get_combo_data_grove() still broken

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

I have looked into the CVS, The Foomatic/Foomatic.cpp is OK, but you 
didn't check in my Foomatic/bin/newDB file, it contains a lot of fixes 
and also additions of new printers (the CVS contains still the very 
first version of the file).

    Till


Mark Hamzy wrote:

> I have already taken your changes and put them into CVS.  We just haven't
> released a new version of omni yet.

[Omniprint-developer] Re: get_combo_data_grove() still broken

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

Mark Hamzy wrote:

> Hey Till,
> 
> I have already taken your changes and put them into CVS.  We just haven't
> released a new version of omni yet.
>


In 0.5.1 I didn't see them, perhaps you added them afterwards.

 
> I think that it may be usefull if printer names could have parenthesis in
> them as well as other special characters.
> 


Here I agree with you for the human-readable names which appear on the 
printers database web pages or in graphical installers, but file names 
(and Foomatic IDs are file names) should not contain characters which 
are handled in a special way by the shell, as parantheses, spaces, 
slshes, backslashes, asterisks, question marks, or exclamation marks. 
One must be able to type a file name streight away on the command line. 
I would simply replace all of them by an underscore for forming an 
ID/file name. The complete file name/ID I form by putting the 
manufacturer's and the models names (both with special characters 
replaced by "_") together with a "-".

    Till

[Omniprint-developer] Re: get_combo_data_grove() still broken

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

Hey Till,

I have already taken your changes and put them into CVS.  We just haven't
released a new version of omni yet.

I think that it may be usefull if printer names could have parenthesis in
them as well as other special characters.

Mark

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

[Omniprint-developer] Re: get_combo_data_grove() still broken

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

The Foomatic generator of Omni has several problems, I have rewritten it 
to use it in mandrake Linux, you can download it from

    http://www.linuxprinting.org/till/Omni-New-Foomatic.tar.bz2

Go to the "Foomatic" subdirectory of the Omni source and unpack the 
tarball there, then do

    mv newDB bin/

and after building Omni go to the Foomatic directory again and run the 
"Foomatic" executable. Then do

    ( cd foomatic-db; tar -cf - * ) | ( cd 
/usr/share/foomatic/db/source; tar -xkf - 2> /dev/null )

to install the Omni Foomatic entries in the local Foomatic database. Do 
not use "foomatic-kitload" to not overwrite the printer's entries which 
are already there with the ones of Omni.

All printer names are cleaned up to follow the patterns of Foomatic, 
they do not contain spaces, parantheses, or anything else strange. In 
addition, the paper size is set for both GhostScript and the Omni 
libraries, as one has to do it according to the driver's README file.

I have already sent this to the Omni guys, but they didn't include it yet.

    Till


Crutcher Dunnavant wrote:

> Grant Taylor wrote:
> 
> 
>>cru...@re... (Crutcher Dunnavant) writes:
>>
> 
>>>still cats to a file made from the value in $poid, and when that value
>>>doesn't play nice with shell (such as when it contains '(' or ')'), then
>>>things break.
>>>
> 
>>We have poid's with () in them?  This is simply illegal.  Legal
>>characters for poids are [\w\d\_\-\.].  This was intentionally done to
>>avoid escaping/parsing issues: no spaces or anything even slightly
>>metacharater-like.
>>
> 
> Hmm, on ivestigation, I'm getting those from Omni.
> 
> 

[Omniprint-developer] 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-developer] 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-developer] 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-developer] printer driver interface

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

I was thinking about what is necessary to implement a generic application
or
rendering engine to printer driver interface.  This is based on a
comparison of
some of the features that are in Omni's implementation of IJS and
Ghostscript's
implementation of IJS.

Setting the device name
-----------------------

The manufacturer and model name should be required as one of the first
commands that are sent.  It is the only way to know what device information
to use.  There will be instances where the user would like to select the
driver that they want to use to send output to a device.  In these
instances, the device should be selectable.  This flexibility could be
needed if the printer had the ability to support multiple personalities and
the user would have liked to select one of the personalities (typically
driver/ language related) prior to printing the job

   IJS seems to get the device name from a bidi query.  Therefore, it is
      optional and may not work if bidi is not supported.
   Omni has multiple printer drivers underneath and uses the device name
      to choose which driver to select.  The device name is required.

Querying information about the printer
--------------------------------------

Some spoolers may want a programmatic way of querying the printer driver's
language.  This is useful to find a matching or compatible printer driver
for functions like moving a job between print queues.  Reference previous
item "Setting the device name"

   Omni can describe its device in terms of a PDL (Page Description
Language).

Setting Job Properties
----------------------

Job properties should be grouped into two sets.  The first set should be
common between all drivers.  This includes the name of the form and the
tray.  The second set is printer driver and device specific.  Currently
there is discussion about a SET_PARAM and GET_PARAM but no clear definition
as to their use.  Typically a drivers state is set in one pass so singular
settings are not needed.  With the SET_PARAM it implies that the driver can
set individual parameters and there is no guarantee of a tie in to all the
parameters since some may get defaulted disallowing others set by the user
to be valid.

   IJS supports form size, dpi and print mode.
   Omni supports form, tray, media, resolution, dithering, print mode, and
      device specific options.

Enumerating Job Properties
--------------------------

Print dialogs need to be able to enumerate every settable job property.
For
each property, it needs to be ably to query it type, range, and default.

   IJS may support it through IJS_ENUM_PARAM.  If the device name is
unknown,
      then it could only return general instead of specific information.
   Omni supports enumerating all job properties that are specific for a
      particular device.

Querying Job Properties
-----------------------

An application needs to be able to query specific information about each
job
property.  From the current proposal, the interface is for the renderer to
setup the driver.  This concept needs to be extended to allow the
application the ability to know about the output page and format the output
for correct placement within the page boundaries.

   Omni will return all the information about a property that it does
through
      the old method of interacting with applications.

Form name as Job Property
-------------------------

There should be a grouping of the form, tray, and media in the print job.
These should be set all at once and not individually.  In many
environments,
people configure a form name based on the form size, color, and finish
option.  The form name will tie all these parameters together to allow for
the selection of specifically what the user wanted which many times will
tie
into changes that are needed for the color management, paper handling, and
tray selection functions.  Also, constraint logic needs the form name.

   IJS uses a Postscript W.WWxH.HH description.  Custom forms with the same
      size may have problems.  The paper size can be unknown in the common
      case.
   Omni is using a new standard that is common with IPP, UPDF, and UPnP.

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

Each job should be associated with a new instance of or connection to the
server.  Multiplexing between different print jobs in one stream will
serialize the processing.

   IJS is page oriented.
   Omni is job oriented.  Job properties can change on a page by page
basis.

Job data
--------

An application can print individual bitmaps easily.  However, there is a
lot
of work involved in formatting the input bitmap data to a printer driver.
The entire printable area of the page must be broken up into sections to
lessen the memory requirements.  Sometimes, the printer driver needs a
multiple of rows to generate print data so the band size must be a multiple
of the print head size.  Also, the things that are drawn on the page by an
application will have to be journalled.  That is recorded and played back
(with appropriate offsets) for each band on the page.  In memory
constrained
devices or when doing higher performance printing, the utilization of a
page
location and direction for the bitmap can greatly increase the performance
of printing the job along with reducing substantially the amount of memory
needed to render the output since a complete band is not necessarily
needed.

   IJS sends only a banded page bitmap.
   Omni supports a generic bitblt mode and a banded page bitmap mode.

Mark

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

[Omniprint-developer] Re: [Inkjet-list] Proposal for new IJS commands and parameters

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

> PrintableArea
>
> This parameter is in W.WWxH.HH format, and describes the printable
> area of the page. It is expected that the client will usually get it.
> Any attempt to set it is allowed to fail with an error, even if it's
> the same value as the get. The value may change dynamically depending
> on PaperSize and other parameters.

IPP, UPDF, and UPnP are standardizing on a set of form names.  We should
leverage their work and be compatible with them.  They look like the
following:
   na_letter_8.5x11in
   na_legal_8.5x14in
   iso_a4_210x297mm

> PrintableTopLeft
>
> This parameter is in W.WWxH.HH, and contains the left and top margins
> of the printable area with respect to the media. It is the companion
> to PrintableArea (I'm considering having a single parameter that
> ASCII encodes the four floats).
>
> TopLeft
>
> This parameter, in W.WWxH.HH is intended to be set, and controls the
> placement of the raster image on the page. The corresponding size of
> the raster image area can be inferred from the Width, Height, and Dpi
> parameters.

The unprintable area should be informational only.  It could be used to
help match a form from another printer onto the current printer.  That
information should come from the server to the client and be passed
around in the job.

Mark

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

[Omniprint-developer] Re: [printing-discuss] IJS Protocol for bitblts

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

BTW,
The note below just outlines several of the things that I think
should be included in the interfaces between the driver and the
renderer (Ghostscript).  I know it would take a fair amount of
time to move  to full function print support. It would be good to
have each of the people that has an interest in creating this
interface to define their requirements so we can come up with
a roadmap to work from to decide what can be accomplished
in any given timeframe.
Once we itemize the requirements we should be more aware
of what our focus points should be and if the function can be
implemented in the near term without major architectural
changes.


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...
---------------------- Forwarded by Pete Zannucci/Austin/IBM on 11/05/2001
10:50 AM ---------------------------

Pete Zannucci/Austin/IBM@IB...@li... on 11/05/2001 07:43:09
AM

Sent by:  omn...@li...


To:   pri...@fr...
cc:   Mark Hamzy/Austin/IBM@IBMUS, Omn...@so...,
      ink...@li..., Raph Levien <ra...@le...>
Subject:  [Omniprint-developer] Re: [printing-discuss] Re: [Inkjet-list]
      IJS Protocol for bitblts



To all,
Just for a level set.
There are a number of requirements that need to be met by a driver/renderer
architecture.
One major hot button is the ability to support higher level drivers (such
as PCL5/6) which
with the rendering a full page of raster data is not what you do.
Basically we need the ability to support device fonts among other things.
With the ability
to place text on a page in particular locations (probably speed up printing
50X+ ) there will
be the need to combine bitmaps, paths (regions) and text on the same page.
This brings
on the requirement that we need to be able to add the page location along
with other
information about the bitmap(s) into the implementation we decide upon.
We need to examine HARD the ability to extend support for accelerated
devices into the
architecture.
Yes it is nice if it is lightweight (I'm not sure that extending it will
make it fat either) but it needs to
give us the flexibility to do everything we would need to do to provide
high performance, high
function printing or is there a need for yet another architecture?
I thought we were here consolidate our efforts and cut back on additional
fragmentation of
the components that are currently in place for printing.

Thanks,

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


Raph Levien <ra...@le...>@freestandards.org on 11/02/2001 06:51:24 PM

Sent by:  pri...@fr...


To:   Mark Hamzy/Austin/IBM@IBMUS
cc:   Omn...@so...,
      pri...@fr..., ink...@li...
Subject:  [printing-discuss] Re: [Inkjet-list] IJS Protocol for bitblts



On Fri, Nov 02, 2001 at 02:51:32PM -0600, Mark Hamzy wrote:
> Hello,
>
>   I think that the protocol should be generalized in the case of raster
> data transfer.  This will allow other applications and rendering engines
> to talk to printer drivers.
>
>   Right now, there are 3 keys that control the format of the
> raster data:  NumChan, BitsPerSample, and ColorSpace.  I assume that the
> size of the bitmap will be exactly the size of the printable page.
>
>   There should be two modes of bitmap transfer.  The first mode should be
> a series of banded bitmaps that are in the color space format that the
> printer driver wants.  It should be sequential bands of the page.  It
> could be either top-to-bottom or bottom-to-top.  It can also have an
> optimization of not sending the starting and trailing white-space bands.
>
>   The second mode should be a number of one or more bitmaps.  Each bitmap
> will have it's size, color depth, and position on the page.  I have
> written some code that can take the second mode and translate to the
> first mode.  It is freely available in the omni driver.
>
>   What do you all think?

My first reaction is no.

Basically, this is a form of data compression. Given that ijs will be
used with a shm transport, it's unclear to me that there will be _any_
performance improvement by implementing compression.

That said, I'm open to the idea of ijs being a somewhat extensible
protocol. If we want to have a parameter for data format, defaulting
to raw uncompressed bitmaps, but settable to the data compression
scheme of your choice, that's fine. The server should always be able
to return an error code if it doesn't support the mode.

Raph "Lightweight" Levien


_______________________________________________
printing-discuss mailing list
pri...@fr...
http://base.freestandards.org/mailman/listinfo/printing-discuss



_______________________________________________
Omniprint-developer mailing list
Omn...@li...
https://lists.sourceforge.net/lists/listinfo/omniprint-developer

[Omniprint-developer] Re: [Inkjet-list] IJS Protocol for bitblts

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

> >   I think that the protocol should be generalized in the case of raster
> > data transfer.  This will allow other applications and rendering
engines
> > to talk to printer drivers.
> >
> >   Right now, there are 3 keys that control the format of the
> > raster data:  NumChan, BitsPerSample, and ColorSpace.  I assume that
the
> > size of the bitmap will be exactly the size of the printable page.
> >
> >   There should be two modes of bitmap transfer.  The first mode should
be
> > a series of banded bitmaps that are in the color space format that the
> > printer driver wants.  It should be sequential bands of the page.  It
> > could be either top-to-bottom or bottom-to-top.  It can also have an
> > optimization of not sending the starting and trailing white-space
bands.
> >
> >   The second mode should be a number of one or more bitmaps.  Each
bitmap
> > will have it's size, color depth, and position on the page.  I have
> > written some code that can take the second mode and translate to the
> > first mode.  It is freely available in the omni driver.
> >
> >   What do you all think?
>
> My first reaction is no.

I had a number of topics that I wanted to discuss and I thought that they
would be ignored if they were all in one note.  So, I picked what I thought
would be a small subset and it seems that what I feared still happened.
What do you think about the other proposal that I made?

> Basically, this is a form of data compression. Given that ijs will be
> used with a shm transport, it's unclear to me that there will be _any_
> performance improvement by implementing compression.

This is not a form of data compression at all.  This is a form of
optimization.  The first half of the process knows that there is only
drawing on the middle of the bands.  It saves the second part of the
process
from having to look at bands of bitmaps and only find out that there is
nothing to do.

Mark

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

[Omniprint-developer] Re: [printing-discuss] Re: [Inkjet-list] IJS Protocol for bitblts

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

To all,
Just for a level set.
There are a number of requirements that need to be met by a driver/renderer
architecture.
One major hot button is the ability to support higher level drivers (such
as PCL5/6) which
with the rendering a full page of raster data is not what you do.
Basically we need the ability to support device fonts among other things.
With the ability
to place text on a page in particular locations (probably speed up printing
50X+ ) there will
be the need to combine bitmaps, paths (regions) and text on the same page.
This brings
on the requirement that we need to be able to add the page location along
with other
information about the bitmap(s) into the implementation we decide upon.
We need to examine HARD the ability to extend support for accelerated
devices into the
architecture.
Yes it is nice if it is lightweight (I'm not sure that extending it will
make it fat either) but it needs to
give us the flexibility to do everything we would need to do to provide
high performance, high
function printing or is there a need for yet another architecture?
I thought we were here consolidate our efforts and cut back on additional
fragmentation of
the components that are currently in place for printing.

Thanks,

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


Raph Levien <ra...@le...>@freestandards.org on 11/02/2001 06:51:24 PM

Sent by:  pri...@fr...


To:   Mark Hamzy/Austin/IBM@IBMUS
cc:   Omn...@so...,
      pri...@fr..., ink...@li...
Subject:  [printing-discuss] Re: [Inkjet-list] IJS Protocol for bitblts



On Fri, Nov 02, 2001 at 02:51:32PM -0600, Mark Hamzy wrote:
> Hello,
>
>   I think that the protocol should be generalized in the case of raster
> data transfer.  This will allow other applications and rendering engines
> to talk to printer drivers.
>
>   Right now, there are 3 keys that control the format of the
> raster data:  NumChan, BitsPerSample, and ColorSpace.  I assume that the
> size of the bitmap will be exactly the size of the printable page.
>
>   There should be two modes of bitmap transfer.  The first mode should be
> a series of banded bitmaps that are in the color space format that the
> printer driver wants.  It should be sequential bands of the page.  It
> could be either top-to-bottom or bottom-to-top.  It can also have an
> optimization of not sending the starting and trailing white-space bands.
>
>   The second mode should be a number of one or more bitmaps.  Each bitmap
> will have it's size, color depth, and position on the page.  I have
> written some code that can take the second mode and translate to the
> first mode.  It is freely available in the omni driver.
>
>   What do you all think?

My first reaction is no.

Basically, this is a form of data compression. Given that ijs will be
used with a shm transport, it's unclear to me that there will be _any_
performance improvement by implementing compression.

That said, I'm open to the idea of ijs being a somewhat extensible
protocol. If we want to have a parameter for data format, defaulting
to raw uncompressed bitmaps, but settable to the data compression
scheme of your choice, that's fine. The server should always be able
to return an error code if it doesn't support the mode.

Raph "Lightweight" Levien


_______________________________________________
printing-discuss mailing list
pri...@fr...
http://base.freestandards.org/mailman/listinfo/printing-discuss

[Omniprint-developer] RE: [Inkjet-list] IJS Protocol for bitblts

[Andrew v. d. S. <aj...@gr...>]

Raph,

with the HP PPA printers, compression using pnm modes that deal with the
subject matter (ie using pbm rather than pnm for text) plus the compression
we try to use when sending data over the parallel port has nearly order of
magnitude speed ups for us. Compression is essentially the difference
between 2-3 ppm and one page every two minutes.

I'm not sure that the ijs architecture per se needs to be compression-aware,
but it certainly needs to flexible enough at every stage of the process to
allow less to occur, thus speeding things up.

That's why in my original proposals to this list (a while back, now), that I
felt the need to be able to let the driver/renderer know what type of output
is being rendered (text, photo image, solid color image). This would be best
done if region based, but rectangles would work for > 90% of occasions just
as well.

Andrew

-----Original Message-----
From: ink...@li...
[mailto:ink...@li...]On Behalf Of Raph Levien
Sent: Saturday, 3 November 2001 11:51 AM
To: Mark Hamzy
Cc: Omn...@so...;
pri...@fr...; ink...@li...
Subject: Re: [Inkjet-list] IJS Protocol for bitblts


On Fri, Nov 02, 2001 at 02:51:32PM -0600, Mark Hamzy wrote:
> Hello,
>
>   I think that the protocol should be generalized in the case of raster
> data transfer.  This will allow other applications and rendering engines
> to talk to printer drivers.
[snip]
>   What do you all think?

My first reaction is no.

Basically, this is a form of data compression. Given that ijs will be
[snip]

[Omniprint-developer] Re: [Inkjet-list] IJS Protocol for bitblts

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

On Fri, Nov 02, 2001 at 02:51:32PM -0600, Mark Hamzy wrote:
> Hello,
> 
>   I think that the protocol should be generalized in the case of raster
> data transfer.  This will allow other applications and rendering engines
> to talk to printer drivers.
> 
>   Right now, there are 3 keys that control the format of the
> raster data:  NumChan, BitsPerSample, and ColorSpace.  I assume that the
> size of the bitmap will be exactly the size of the printable page.
> 
>   There should be two modes of bitmap transfer.  The first mode should be
> a series of banded bitmaps that are in the color space format that the
> printer driver wants.  It should be sequential bands of the page.  It
> could be either top-to-bottom or bottom-to-top.  It can also have an
> optimization of not sending the starting and trailing white-space bands.
> 
>   The second mode should be a number of one or more bitmaps.  Each bitmap
> will have it's size, color depth, and position on the page.  I have
> written some code that can take the second mode and translate to the
> first mode.  It is freely available in the omni driver.
> 
>   What do you all think?

My first reaction is no.

Basically, this is a form of data compression. Given that ijs will be
used with a shm transport, it's unclear to me that there will be _any_
performance improvement by implementing compression.

That said, I'm open to the idea of ijs being a somewhat extensible
protocol. If we want to have a parameter for data format, defaulting
to raw uncompressed bitmaps, but settable to the data compression
scheme of your choice, that's fine. The server should always be able
to return an error code if it doesn't support the mode.

Raph "Lightweight" Levien

[Omniprint-developer] IJS Protocol for bitblts

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

Hello,

  I think that the protocol should be generalized in the case of raster
data transfer.  This will allow other applications and rendering engines
to talk to printer drivers.

  Right now, there are 3 keys that control the format of the
raster data:  NumChan, BitsPerSample, and ColorSpace.  I assume that the
size of the bitmap will be exactly the size of the printable page.

  There should be two modes of bitmap transfer.  The first mode should be
a series of banded bitmaps that are in the color space format that the
printer driver wants.  It should be sequential bands of the page.  It
could be either top-to-bottom or bottom-to-top.  It can also have an
optimization of not sending the starting and trailing white-space bands.

  The second mode should be a number of one or more bitmaps.  Each bitmap
will have it's size, color depth, and position on the page.  I have
written some code that can take the second mode and translate to the
first mode.  It is freely available in the omni driver.

  What do you all think?

Mark

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

[Omniprint-developer] Re: [Foomatic] Re: Problem on the stp web page/with Omni

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

Till,
Just wanted to get the naming convention changed for Omni.
We have changed to have Omni build as a non-debug build so until
we start putting in a bunch of new devices and/or function, it would be
nice if we could use omni-stable instead of omni-unstable.  We
will be adding unstable or devel to our CVS later.

All,
Another thing is that omni is not driven by the LD_LIBRARY_PATH
for loading and now loads out of the /opt/Omni/bin directory.  Sounds
like having multiple versions will require over-rides on where the
different
versions will live once we do provide multiple levels.
Lastly, there is a lot of work has gone into standardization of formnames
and some of the other parameters via UPDF, IPP, and UPNP.  We should
start looking at aligning a number of items so that we can make it much
easier to be able to manage and package the driver support.  Whatever
can be done across the projects for standardization will help anyone
writing tooling to utilize any of the projects simplify their work (ours
too in the
long run).
Any thoughts on what would be helpful from a standardization perspective?
It would be good to decide what would be the best direction to take for
the future along with defining an easy way to update properties and capa-
bilities if needed in a multi-user environment should the need arise.

Thanks,


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


Till Kamppeter <til...@gm...>@linuxprinting.org on 10/30/2001
06:11:07 PM

Sent by:  foo...@li...


To:   Grant Taylor <gt...@pi...>
cc:   Robert L Krawitz <rl...@al...>,
      gim...@so..., Pete Zannucci/Austin/IBM@IBMUS,
      Omn...@so...
Subject:  [Foomatic] Re: Problem on the stp web page/with Omni



So I will make it this way:

The following driver names will be used:

    gimp-print
    gimp-print-unstable
    omni-unstable

gimp-print will always carry the data of the newest GIMP-Print
(currently 4.2.x). gimp-print-unstable will carry the newest release of
the unstable series (currently 4.3). From Omni there is only a
development version, so there is only an "omni-unstable" driver entry.

Updating will not be done by the usual install script for the rest of
the site. It will be done by a special script, triggered by one of the
following mechanisms:

    1. Manually when we get notice of a new release of one of the
       drivers. For this we need the info of a new release appearing as
       fast as possible, also from the Omni folks.

    2. A cron job checks the download sites of Omni and GIMP-Print. When
       a new release appears, the update starts.

    3. The server account is subscribed to the GIMP-Print and Omni
       mailing lists and a script is started through the ~/.forward file.
       When a mail announcing a new release arrives, the update is
       triggered. This requires the subject line of the announcement
       following certain rules, as always being:

          ANNOUNCE: gimp-print-4.2.1 released!

The script should do the following:

    1. Download new driver release

    2. "make" but not "make install" i

    3. Remove old option and driver XML files from server.

    4. "foomatic-kitload" the new Foomatic data.

    5. e-mail the successful execution to Grant and me.

If one of these steps failed the script should not execute any
subsequent steps and mail a log to Grant and me.

This keeps the server always as up-to-date as possible, especially when
the script is triggered by a mailing list announcement or by an hourly
cron job.

For this the authors should cooperate by providing machine-readable
announcement titles, easy recognizable robot-downloadable source
tarballs, foomatic data being built always in the same directory, always
the same steps for building being used.

The authors should also have a decent comment in the driver XML files.
It should give a good, human-readable description of the driver, tell
that the Foomatic data is only for the current release (include version
number here), cross-reference between development and stable release
with links, warn users about possible bugs in unstable and that unstable
can be useful for them when stable does not support their printer.

WDYT about that?

    Till


Grant Taylor wrote:

>>>>>>Till Kamppeter <til...@gm...> writes:
>>>>>>
>
>>I would suggest to always have the newest GIMP-Print/Omni Foomatic
>>data online and some older versions (3 or so). The older versions
>>should be chosen depending on when changes to the Foomatic data of a
>>certain GIMP-Print version occur. Every time when a new GIMP-Print
>>version appears and its Foomatic data is not compatible to the
>>previous version, a new Foomatic data set should be added. Then also
>>the oldest can be removed. The GIMP-Print 4.0 data should conserved
>>for some more tims as "gimp-print-4.0", for GIMP-Print 4.2.0 there
>>should be a "gimp-print-4.2.0", when 4.2.2 will need new Foomatic
>>data there will be a "gimp-print-4.2.2", if there are more than
>>three driver entries for GIMP-Print 4.2.x, the oldest will be
>>removed.
>>
>
> Ugh.  No, this is the ugliness we want to avoid.  Use "omni" and
> "omni-unstable"; and "gimp-print" and "gimp-print-unstable".  Or
> perhaps "-devel".
>
> When a user installs a new gimp-print foomatic kit, make kitload
> automagically uninstall the previous one, and respin all existing
> configurations against the new data.
>
> When gimp makes a new release, switch the website to that data.  Don't
> try to track all manner of previous releases; that's hopeless.  Just
> flog gimp-print binary distributors into shipping the foomatic kits no
> matter what else they may do.  Perhaps Robert would put a two-line
> "thou shalt configure your gimp-print thusly for binary distribution"
> blurb in his readme.
>
>
>>All options must be versioned, too (ex: option ID:
>>"gimp-print-4.2.0-PageSize", file name:
>>"gimp-print-4.2.0-PageSize.xml", short name: "PageSize", long name:
>>"Page Size"), so that the different GIMP-Print versions do not
>>interfere.
>>
>
> Yes, but only inasmuch as there is a normal and -unstable driver name.
>
> Don't go all whacky putting in actual numbers; this will break many
> things including upgrades.
>
> The gimp-print release cycle allows the foomatic generator code there
> to know if it needs to put -devel on the end or not, so this can be
> all automagic.  Dunno what goes on in OMNI.
>
>
>>This requires from both the authors of Omni and GIMP-Print that they
>>inform Grant and me about every release and which release needs new
>>Foomatic data, so that we can keep linuxprinting.org up-to-date.
>>
>
> For all releases just do the update exercise regardless; you pretty
> much do this now as a function of making libgimpprint and omni rpms.
>
>
>>The impact for the database is probably not so high, the server has
>>plenty of resources
>>
>
> That's not the point.  *We* don't scale that way, and even if we were
> to arrange to it wouldn't actually solve a problem.
>
>
>>>Yes, this highlights one thing we need in foomatic: dependency
>>>checks.  PDQ has a scheme for this, whereby you plug in shell code to
>>>
>
>>You mean that Foomatic should check which drivers are installed on
>>the local machine (GS driver in "gs --help", filter in $PATH, for
>>UPP driver upp file available, and version check, shell script for
>>doing these checks should be in a field of the driver's DB entry)
>>and "foomatic-configure -O" only list ths combos which will work on
>>the current system?
>>
>
> Foomatic shouldn't be that clever.  It should simply offer a warning
> at configure time saying "such-and-such driver is not present, setting
> up anyway".  People can either install the driver or pick a different
> one.
>
> Not listing it with -O means that people will never figure out that
> there is a or a better driver in the world for them.  And the -O is
> used for autodetection as well, remember, so there may be no pruning
> there.
>
> We can get fancy about how to find and install missing drivers later;
> first things first.
>


_______________________________________________
Foomatic-devel mailing list
Foo...@li...
http://www.linuxprinting.org/cgi-bin/mailman/listinfo/foomatic-devel

[Omniprint-developer] Re: Problem on the stp web page/with Omni

[Grant T. <gt...@pi...>]

>>>>> Robert L Krawitz <rl...@al...> writes:

> For drivers like Gimp-print (4.2, at any rate) and Omni, there's *no*
> reason for people to download Foomatic kits from linuxprinting.org.

Quite.  I just want to fix the "gimp-print" driver link that's been
broken on my site for maybe a year now.

>> Yes, but only inasmuch as there is a normal and -unstable driver name.

> Perhaps we should use the soname of the library for this purpose?
> If you use shared libraries, you won't be able (without some nasty
> LD_LIBRARY_PATH hacking) to have 4.2.0 and 4.2.1 installed
> simultaneously, because the library sonames will be the same.

I dunno, this still breaks upgrades: if a user of 4.2 installs 4.4
someday, then any like-named option settings should still exist.  If
we explicitly version the thing, then all the option settings go away.

Using "gimp-print" and "gimp-print-devel" allows things to work
approximately as they should.

--
Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/
    Linux Printing Website and HOWTO:  http://www.linuxprinting.org/