Subject: Re: IPP> REQ - Last minute scenario comments

From: [email-masked] (Robert Herriot)
Date: Tue, 28 Jan 1997 20:02:15 -0800

There is another dimension to the scenarios that has not been covered.
I will first cover 6 cases and then address how it affects the protocol.

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.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 30 Jan 1997 21:37:40 PST

# 2. non-paginated documents  (e.g. text, HTML)

In this case, "text + formatting" or "html + formatting" is just
another kind of "PDL".

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

I don't think those are the only two cases. There's also:
 - the client knows which attributes are appropriate for a given
   document type (how printing works now)
 - the server informs the clients of additional required parameters
   after the document has been submitted.

I favor doing the first and the second when necessary.

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

I think generally that job attributes could to be marked as either
overriding or subordinate to attributes embedded in the document,
although "always override" would work.

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

This may be useful but not very.  By the time you add the code to the
printer to tell the client that "this printer doesn't understand that
attribute if it isn't embedded", you might as well have fixed it to
actually understand it.

---

From: "Gail Songer" <[email-masked]>
Date: Fri, 31 Jan 1997 09:50:06 -0800

Larry,

On Jan 30,  9:37pm, Larry Masinter wrote:
>In-reply-to: <[email-masked]> ([email-masked])

> attribute if it isn't embedded", you might as well have fixed it to

Let me describe a little about how EFI works, as I beleive it relevent to the
above discussion.  We create one external network rip that sits next to copier,
where the copier can be one of any number of models from a number of companies.
 We "customize" for each copier by loading a video driver that is specific to
the copier.  Engine specific commands are fed to the video driver from a host
driver by including commands in the data stream that are retreived from a host
PPD and sent to the printer. The PDL will feed the device specific commands to
the video driver without knowing what the commands specifically do.

So, there is some code in the machine that understands the commands but if the
commands are not fed through the data stream, then the feature will not be
used.

Gail

-- 

Gail Songer                                             Electronics For Imaging
[email-masked]                                 2855 Campus Drive
(415) 286-7235                                          San Mateo, CA 94403

---

From: Larry Masinter <[email-masked]>
Date: Fri, 31 Jan 1997 10:30:43 PST

If you have:
   client sends PDL + parameters to gateway
   gateway sends PDL to real printer without parameters

and the PDL is capable of expressing some attributes ("paper size",
for example), then why not have the gateway just add the parameters to
the PDL? I know that it's extra implementation work on the part of
your gateway, but the alternative is to require the same work to be
done in all clients that want to set paper size; they will need to
either "always send paper size in the PDL" or else "negotiate over
where to set paper size and be prepared to send it in the PDL".

Is it really so much harder to take envelope parameters and embed them
in the data stream?

Larry