A client can deal with three basic types of documents and submit them
in two ways each. The six cases are:
1. documents associated with some application (e.g. MS Word, PDF)
a) submitted with Print menu: The client displays a dialog box whose
values come from the IPP Printer. The driver translates the document to
a PDL, embedding some attributes. Non- embedded attributes, such as
retention-time are sent separately, The client specifies which
attributes are embedded so that they dont get defaulted in the
printer.
b) drag and drop: same as above, except the client uses the same
defaults the user would have seen in the above case.
2. non-paginated documents (e.g. text, HTML)
a) submitted with Print menu: The client displays a dialog box whose
values come from the IPP Printer, but there are additional values to
help with formatting, e.g. width, top margin, footer and font. Such
values are implicit within the document in the previous case. The
client may translate the document and submit the PDL as in 1a or it may
submit the document to the Printer which uses the formatting attributes
in the pagination process. The server should be prepared for the latter
more likely case, but nothing prevents a client from doing the work.
b) drag and drop: if the client does the translation, it uses the
defaults obtained from the printer and submits the job as in 2a. If
the client doesnt translate the document, it submits the job with no
attributes and the printer handles the defaulting and translation.
3. documents in a printer’s PDL (e.g. PostScript, PCL)
a) submitted with Print menu: The client displays a dialog box whose
values come from the IPP Printer, but some attributes may have a
special value as is and that may be the only supported value, depending
on the capability of the Printer to modify the PDL. The client may
modify the PDL document and submit it as in 1a or it may submit the PDL
document to the Printer which uses the attributes to modify it. There
must be some way for the Printer to know whether the accompanying
attributes have already been embedded. The server should be prepared
for the latter more likely case, but nothing prevents a client from
doing the work.
b) drag and drop: if the client does the translation, it uses the
defaults obtained from the printer and submits the job as in 3a. If
the client doesnt translate the document, it submits the job with no
attributes and the printer handles the defaulting and translation.
Note, the defaulting may be different for a PDL document because some
attributes default values may be as is.
Many of the issues discussed above seem to be more related to GUI and
client issues, but they affect what concepts the protocol needs to
support. Issues that affect the protocol are:
o the client needs to display or not display some attributes based on
the type of the document. Either the server needs to receive the
document type, or it needs to send information to the client about
attributes that are restricted to certain document types. I favor the
later approach.
o the client needs to display or not display some attribute values
based on the type of the document.
o the protocol needs to be able to specify whether an accompanying
attribute has been embedded in the document and is just there to
indicate the needed resources if it is present.
o the server needs to be able to tell the client whether it prefers an
attribute to be supplied as a resource needed. Such a resource would be
optional, but it improves reliability.
o it may be useful for a printer to indicate that it only understands
an attribute if it is embedded in the document so that a client knows
whether to embed it. This concept is probably most useful in a ppdfile
context which describes either the PDL string to embed or the attribute
to set.