I think some of the solutions we are coming up with do munge
the world of job control and PDL. This is because alot of the PDLs
we deal with (lets use Postscript as an example) have job control
built into them as well. I remember when I was reading the
DPA specifications, the standard states that the user can use
the DPA job submission attributes to override what is specified in
the PDL. I don't know how many people on the list have actually
spent time inside the architecture of a postscript interpreter, but
the above DPA requirement forces some major architectural changes
in most PDL implementations I am aware of.
There are some aspects of the job that are PDL-independent, like
do I want this on standard paper stock or transparency. But once
the final form PDL is generated (either directly from an
application, or through a device-specific print driver) I would
hope that we would not be attempting to override the PDL with
our IPP-specific job control. Some parameters, like the paper/
transparency decision would be ok, but I think we should stay
away from any job control that attempts to change the imaging
characteristics (aspect ratio, fonts, media size, etc.) that
might conflict with parameters that were used to generate the
PDL.
I guess I'm basically a purist and agree with Jay that we need
to keep job control and PDL separate; with job control specifying
more "macro" types of job characteristics like "Does this
printer support Postscript?" or "I would like this printed on
transparency", etc. Also, its very hard to do directory lookups
on anything more job-specific than this without doing parsing
of the PDL to determine the actual job requirements, so I think
the directory service attributes need to reflect the parameters
and printer characteristics that are easy to obtain, similar to
the "macro" type of job characteristics I have described.
Since we agreed in an earlier teleconference to utilize existing
device specific print drivers and just insert IPP as a "redirector",
we have basically agreed to be PDL-independent, so we can't parse
the job stream, nor do we have a mechanism for transmitting print
job metadata from the device-specific driver through some other
"channel".
Boy, you're right Jay, it does feel better to unload all this
baggage.
Randy
>
> My argument then is the same as it is now: Print Data is Print Data,
> and Job Control is Job Control (protocol and parameters), and the
> two should be separate in the requisite protocol transactions.
>
> Munging the two together just causes all kinds of parsing problems
> that usually end up impacting future extensions. A Client should be
> able to say "Here's some print data, please print it this way for
> such-and-such a person", and the Server should operate on that data,
> often in a relatively opaque manner (assuming the "Server" is
> architecturally separate from the RIP or similar imager).
>
> Sure, both PostScript and PCL embed all kinds of stuff in the print
> data stream...but I believe that's because there has never been a
> STANDARD PRINTING PROTOCOL in the world that everyone could play to.
>
> Sheesh, that's all I really want. A standard printing protocol.
> It just doesn't seem like that's too much to strive for, given the
> large body of experience in the Tower of Babel that has existed up
> to now.
>
> Ah, I feel better now. Thanks for letting me get that off my chest.
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
-- Randy Turner