Mark,
I know where you are coming from.
But in this case I disagree with you.
I think it's the job of the global media spec to provide lists of keywords
for size, type, coating (if media source would be added, I'd be the first to
take it over in UPDF).
Any semantic level, where keywords are combined to information about a
device status, is the task of a communication protocol like IPP (or even a
MIB), a device description like UPDF or a driver.
So I'd expect IPP to tell me that there is a media present with four
attributes 'Letter,Stationary,Glossy,ManualTray' and two other media with
other attribute parameters.
In UPDF we want to provide a chance to declare these four attributes a unit.
And the driver hopefully has some functionality to create an appropriate UI
for that.
This would result in the required behavior of the whole environment.
The two keywords for min/max custom sizes may as well come as attributes of
media sources or duplex settings or any other section within the
communication protocol.
It's only about relying on a certain syntax on keywords.
If the communication protocol or the UPDF use it wrong in their context,
then that's there fault.
Regards
Norbert Schade
----- Original Message -----
From: "Mark VanderWiele" <markv@us.ibm.com>
To: "Norbert Schade" <norbertschade@oaktech.com>
Cc: "UPD group" <upd@pwg.org>; "IPP Group" <ipp@pwg.org>; "Pete Zannucci"
<pzaan@us.ibm.com>; "Mark_Hamzy/Austin/IBM%IBMUS" <hamzy@us.ibm.com>
Sent: Friday, March 30, 2001 10:44 AM
Subject: Re: UPD> Re: IPP> min/max custom size values
> Careful, we may be making the same mistake we made in IPP where the form
> size, media type, and tray are returned separately causing user interface
> nightmare since all three of these really must be selected together and
> represent the actual configuration of the printer. Therefore, I would
> propose that when we have settled in on a syntax for the form size, media
> type, and tray we go one step further and define a way to join the fields
> so that the proper constraints can be represented. Perhaps a simple "+"
> character. Again, form size by itself is meaningless.
>
> Regards,
> Mark VanderWiele
> IBM, Linux Tecnology Center
> 512-838-4779, t/l 678-4779
> MARKV@IBMUS
> email: markv@us.ibm.com
>
>
This archive was generated by hypermail 2b29 : Fri Mar 30 2001 - 12:49:07 EST