I think that we all agree that in a perfect world, the PDL contains no
embedded attributes and all attributes are specified externally.
Meanwhile, I would expect that customer will want to print existing
documents with attributes embedded in the PDL and want to override them
with external IPP attributes. Certainly, Jim's case of 4-up internally
and 2-up externally presents a problem. But other attributes, such as
sides to not present a problem, especially if the PDL interpreter
supports IPP attributes.
I also think that I don't understand how option 2 (below) works. How
does a client know whether an attribute should be embedded or external.
Are there some rules?
I think that IPP needs to support the following scenarios:
1) UPD printer: the printer honors an external attribute and
ignores the corresponding embedded attribute if any, unless
the external attribute is absent or has the value 'as-is'.
Note: I include true printer features in the list of such external
attributes and exclude image transformations, such as n-up.
Note: embedded attributes that are beyond IPP capabilities (e.g.
different media on different pages) require the 'as-is' value.
2) UPD client: the client queries the IPP printer for attributes and
generates external attributes. It does not embed control information
in the PDL.
If the printer is an IPP printer, then the supported production
attributes should be the same as those supported as embedded
attribute.
If the printer is a legacy printer (supported by an IPP print
server), then some attributes supported as embedded by the output
device may not be supported by the IPP print server. For such
a printer, a Windows client would use a legacy driver to gain
access to all the features. Unix clients should, likewise, use
their legacy mechanism for accessing a legacy printer.
Issue: what about the "different media on different pages" raised
above?
3) Windows client legacy: the client continues to send just a PDL
file with attributes embedded in the PDL. The attributes are known
to the client and do not come from the IPP printer. The IPP printer
must not attempt to add external IPP attributes unless their
value is 'as-is'.
4) Unix client/gateway legacy: the client/gateway continues to send
a PDL and some lpr attributes. The attributes are known to the
client and don't come from the IPP printer. The lpr attributes are
translated to IPP attributes.
I think that all of this argues against the need for 'capable' attributes
because the client software that generates embedded attributes in the PDL
continues to operate as it currently does. And it doesn't use the
external attributes.
The one exception is for setting up the directory service. Then the
question is which attributes should the printer display: the ones
accessible via IPP attributes or the ones accessible via embedding?
It does seem a bit strange for a client to find printers via the IPP
mechanism and then use a legacy driver to print, but it might still
be useful.
I also wonder, how useful are IPP print servers that talk to legacy
printers if they are unable to support IPP production attributes.
In other words, why would anyone switch from a legacy driver to a UPD
for a legacy printer if they lose functionality?
Those are my thoughts.
Comments welcome.
Bob Herriot
> From walker@dazel.com Wed May 7 08:28:55 1997
>
> I was assigned the following task from the last model meeting:
>
> >> 2. Since we are getting rid of tags, it is not acceptable to live with the
> >> ambiguity as clarified by Tom in last weeks minutes. That is xxx-supported
> >> values are: 1) client desires to
> >> override the PDL (the same instruction is in the PDL) or 2) client desires
> >> action only when the information is not in the PDL. This was once being
> >> solved by the embedded and embedded-only tags. Since we have no tags, the
> >> proposal is to define a set of xxx-capable attributes to go along with the
> >> xxx-supported attributes. Jim Walker took an action item to write this up
> >> can clarify semantics of xxx-supported, xxx-capable and best-effort and
> >> embedded instructions in PDL.
>
> Here are the three alternatives as I see them:
>
> (1) The server advertises the productions that it is capable of supporting,
> assuming that the client inserts the appropriate printer- and PDL-
> specific sequence in the PDL data stream. This is the situation
> as we have today in the PC driver world, and the situation that
> most seem to think that we ought to try to get away from.
>
> (2) The server advertises the productions that it can support, assuming
> that the client sends the appropriate IPP attribute in the job (or
> document) control stream, and does not insert any conflicting
> production instructions in the PDL data stream. This is the ideal
> situation in the UPD world.
>
> (3) The server advertises the productions that it can support, whether the
> client sends the appropriate IPP attribute, and/or has the same or
> conflicting production instructions in the PDL data stream. This
> is the robust case that everybody *thinks* they want, but I would
> argue that this situation is untenable in general (e.g., I pass a
> document that is already 4-up'ed, and tell the server that I want
> it 2-up'ed, and, by the way, best-effort is do-not-substitute).
>
> I believe that IPP printers ought to *only* support option (2) above.
>
> First of all, we can do option (1) today without the IPP printer
> advertising its capabilities. In this case, the driver would use PPD
> files (or whatever other information it already has or wants today) and
> generate an appropriate PDL data stream, and forward that data stream on
> to an IPP printer with few, if any, IPP attributes. The driver would not
> need to query the capabilities of the printer, as it could just get that
> information the same way that it does today. After all, if we were going
> to modify the driver to query the IPP printer, why not go ahead and modify
> it to set the appropriate attributes in the job control stream, as in
> option (2), rather than in the data stream.
>
> Furthermore, knowing the capabilities supported in option (1) does not
> help with pre-generated files either; the user does not know (unless they
> have software to scan the file) what capabilities were utilized in
> generating the data file, so it does not help that they know what
> capabilities the printer will support.
>
> As I have already stated above, I do not believe that option (3) is
> supportable, especially if we try to tie this together with the
> best-effort attribute. If we say that the IPP printer can only advertise
> the supported attributes that it can override what is specified in the
> data file, then will any IPP printers be able to any supported attributes.
> In other words, if I am a print server that fronts a duplex printer, yet I
> am unable to guarantee that I can override a simplex/duplex capability
> specified in a PDL data stream, then I cannot advertise sides-supported.
>
> So, I believe that option (2) is the only option that we should attempt to
> specify in IPP, especially version 1.0. With this option, we can say that
> the xxx-supported attribute describes those capabilities that the IPP
> printer can support if the associated xxx attribute is specified in the
> print job. If a conflicting instruction is specified in the PDL data
> stream, then the results are undefined.
>
> comments welcome...
> ...walker
>
> --
> Jim Walker <walker@dazel.com>
> System Architect/DAZEL Wizard
> DAZEL Corporation, Austin, TX
>