I want to start a little brainstorming within our group to prepare proper contribution to a new document later.
Let's just discuss some options.
I assume a communication protocol, which can tell me the size, type, color, finish and source media attributes (called the five media attributes from now on) in a collection with proper syntax - whatever that is.
I assume a device, which supports the five media attributes.
I assume a driver/client can read and understand that properly.
I assume a driver/client that can work online as well as offline. That means it can mirror (online) the device as well as show all capabilies (offline). The mode is considered switchable.
I think about some driver UI handling plus how to announce the stuff to the operating system respectively the applications.
Statement 1 (not my final belief, but a point of view to discuss)
Although some operating systems support the choice of media size and source, applications do not necessarily ask drivers/clients always the right time about constraints.
We define the request that drivers/clients announce one list of media attributes to the OS and its applications.
This would be announced as the media size attribute in the OS API.
The OS API for source - if available - would be filled with a dummy indicating that these constraints are dealt with in the driver/client. This elimites the chance of invalid combinations - a permanent threat today.
1. Online
Looks like the simplier case.
The driver UI only needs one control like a combo box to show available medias. Let's imagine the prompt 'Media' for that. It shows a combination of the five media attributes. Entries could look like 'Letter, Paper, White, Glossy, Tray 1' or similar. Forget cosmetic improvements for now.
A variation could be to show five additional controls for the five media attributes, which would be grey always, but show the proper single attribute of a selected media.
A nice feature could be to enable the user to rename 'Letter, Paper, White, Glossy, Tray 1' to 'Norbert's paper', in which case the five additional controls would really make sense.
This would basically reflect the media as the collection of attributes like it's coming in via bidi.
The user would see 'Letter, Paper, White, Glossy, Tray 1' or 'Norbert's paper' and similar entries in the media size control of the applications. A feature like showing media attributes when right-mouse-clicking the selected media in the application is something I only dream of after my second beer.
I feel that rumbling building up in my stomach when thinking of PDL's being able to send more media attributes than a communication protocol is able to tell for a specific device. but of course, that's not happening in our perfect world.
2. Offline
While I think that the Online mode might be the main mode to work with, it should be possible to create documents for a printer, which is switched off or disconnected or whatever for the moment.
Or a user specifically wants to request certain media in the device, which he/she knows it's able to work with, but may currently not be fed in the device. A print server or the device itself would react with proper messages, etc.
One main concern of mine is to keep the driver's UI and the communication with the OS and its applications as similar as possible to the Online mode.
In this case you certainly need the five controls for the five media attributes. Proper constraint handling assumed.
Now the problem is that nobody has defined any collection so far.
So the user has to do that (Some popular defaults may be there from beginning on).
Requires a media control control to show the stored collections and buttons to save a current selection of the five attributes as a collection and delete unwanted collections.
Ok, feedback, whether this is a feasible approach? Or too complex/complicated driver/client UI?
While I think the problem is very popular, there is no perfect solution of it in the market so far.
I think having a collection is one thing, but I consider it partly our (the UPDF group's) task to think about what to do with that structure on the host assuming that a communication protocol like IPP would feed us properly.
I do not think it a bad idea, if we'd provide some recommendations how a driver/client may make best use of the information it can find in a UPDF description.
Let's talk. I hope some people join me in this discussion and do not let this be a monlogue. There would still be plenty of room for any proprietary, final driver/client solution.
One little detail:
The more I think about the bidi stuff the more I am convinced that one UPDF description will be dedicated to support exactly one communication protocol - like one PDL. I am somehow sure that the specific communication protocol/job language determines important details of the driver/client functionality and UI. Agreed?
Hmmmmm... Don't think about a device supporting 5e, XL, PS and PJL, IPP, UPnP.
Norbert Schade
Principle Software Engineer
Host Software Group
Oak Technology, Inc.
10 Presidential Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Wed Apr 11 2001 - 13:07:15 EDT