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

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

Hey Ben,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yes.

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

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

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

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

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

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

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

Ok.  We can work on that.

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

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

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

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

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

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

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

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

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

By querying them of course :).

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

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

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

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

Can you give examples?

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

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

"installed" is not a valid job property.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yes!  Most definately!

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

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

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

How about PDCCMD_IS_KEY_VALUE_SUPPORTED "key=value" ?

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

We can work on this.

Mark

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