I still wonder, if we are providing enough information on manual duplex to fully support it.
we certainly tell about flipping in input and output trays and I think all needed information for the page order can be pulled out of that.
sample: I think a driver should understand that the page order is fine for all pages, when it learns that the media gets flipped in the output tray. but in other cases it may have to send odd and/or even pages in reverse order.
conclusion: no additional info needed here.
however I think we should add an event 'HalfDocument', which indicates that 50% of all physical pages of a document have been sent. I've added that event to the data type.
additionally we need an element in the Sides feature indicating that some kind of user action is needed at halftime. in the description we do not care which action. this attribute would tell the driver that the device is able to help with manual duplex, but needs info about the halftime. now the driver knows it has to prerender the pages, find out halftime and be prepared to find an event 'HalfDocument'. theoretically we could have the driver check all events and learn about the 'HalfDocument' by itself. not sure the driver wants to do that. it is likely expecting that input being available easily.
it is still necessary to declare the Sides feature not a device feature, as there is likely some functionality necessary like a special page order.
I've added a boolean attribute 'HalfDocumentNotification' to the Sides feature with default = false.
without the attribute (or if set to false) the driver is supposed to take over full responsibility for the feature including a halftime dialog.
out of scope:
we are not dealing with the case of a bi-directional message being sent to the host in UPDF, version 1.0
Comments???
Regards
Norbert Schade
Norbert Schade
69 Prescott Drive
North Chelmsford
MA 01863
phone: 1-978-251-1017
email: norbertschade@comcast.net
This archive was generated by hypermail 2b29 : Mon Mar 08 2004 - 16:07:40 EST