I think you are looking at things in a different way. I will try to
explain two issues you raised in greater detail below.
Bob Herriot
--------------------------------
> From masinter@parc.xerox.com Thu Jan 30 22:36:07 1997
>
> # 2. non-paginated documents (e.g. text, HTML)
>
> In this case, "text + formatting" or "html + formatting" is just
> another kind of "PDL".
Yes, "text + formatting" is another kind of PDL, but the formatting part
needs to be specified separately from the text, either via defaults or
via some parameters that a user can specify. In a PostScript file and
in an application file, such as MS Word, formatting
is alreay embedded in the file.
So from the client software point of view, the user needs to be allowed
to specify formatting parameters that make no sense in the PostScript
or MS Word case. If all client parameters come from the Printer, then it
is the printer that holds formatting defaults and supported values.
-----------------------------
> # 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.
I was saying something different. In IPP, we have specifically eliminated
attributes that are subordinate to attributes embedded in a document because
we didn't think that they are useful for most people. Such an attribute
leaves a user not knowing what he will actually get.
The attribute concept that I am dealing with is that an attribute, e.g.
sides when it accompanies the document may have one of two meanings:
the client has requested some feature which:
1) has not yet been embedded in the document data, but overrides
whatever is in the document.
2) is currently embedded in the document but exists as an external
attribute to tell the Printer about a needed resource. Some
program that produced the PDL has set the attribute in this case.
----------------------------------------
> 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?
I think that Harry did a good job of explaining the problems of merging
attributes into a PDL. This why I have the three cases that I
presented and why a Printer must give a user access to a set features
that are dependenton the type of document data.