Meeting notes from the UPDF meeting in
Woburn, April 19th 2002.
Attendees
Richard Hart, Compaq
William Wagner, NetSilicon
Lee Farell, Canon
Harry Lewis, IBM
Jim Sommer, Granite Systems
Elliott Bradshaw, Oak Technology Inc.
Norbert Schade
While the spec design hasn't changed lately in the areas of composite features and user policies, we were able to show the host implementation of Granite Systems under Windows on their current level. Fortunately we could demonstrate progress even with nested composite features. We had prepared a Media feature in the sample with some records predefined by the IHV. The settings of these could be looked at in a subdialog for information purpose only. We could as well show the conditions when and how an end user can add, edit or remove records for a composite feature. We explained the meaning of a dominant feature as well as the reason for having non-dominant fallback records. The last and most surprising part of the demos was the fact that we could already pass the feature through to the operating system and its applications by selecting the Page Setup dialog of an applicatoin like WordPad or WinWord. It became apparent that this type of solution allows various instances of a media size like Letter to be listed with a dedicated text string for other attributes involved like media type or source. This kind of functionality is not provided by any other driver concept we know of and helps avoiding some kind of bugs with contradicting media size and source, too.
User policies - the chance for system administrators to preset or modify drivers for certain users or user groups - allow an even more elaborate application of composite features.
This kept us busy in a very active discussion after which everybody had the feeling he understood that part of the spec completely, perhaps the first time.
The proposal prepared for the conference went through with only few change requests.
The specification will support device color for monochrome and color devices with 8bpp per color plane. All entries are public including the way the driver is expected to work to support the structures - as you may expect it from an open standard. Level 1 of UPDF will not support private hooks.
We provide flexibility for different plane handling implementations. Planes can be specified per page, per band, per scanline and per pixel, which represents the most common ways a plane can be used. We had PDL like PCL and PostScript in mind, but tried to provide support for ink jet and impact printers as well. Please have the specification checked, if it fulfils your needs. Target of the spec is to provide all necessary information to create a correct output for raster graphic for common devices. We do not yet support interleaving. The current plan is to not add that to level 1.
IHV who have further needs have to step up to provide the necessary information about the required structure and tags as well as the expected driver functionality. The current design of these three features is considered the final proposal. Some attendees were asking for a bit more time for contemplation. We keep the design open and wait for input until May 10th. The current schemas and xml sample files are on the UPDF web site.
We made a few comments to events mentioning that we currently try to rebuild the output of a standard monolithic HP LaserJet 9000 driver available from their web site by using our event structure. The list of events is growing by the week.
We agreed on the request to drivers to maintain additional locale files based on the same UPDF schema for their own text strings.
This allowed us to get rid of extra mandatory and proprietary locale sections. So we went back to the original design in this area and expect drivers to work accordingly.
We had prepared a very basic sample schema for user interface issues to find out how much that would be required. This needs further investigation. At the conference there was a tendency not to do that. Concerns were the extra workload for an elaborate, but common denominator and different needs for different platform environments.
Please watch the reflector for ongoing discussions.
We were surprised about the vivid discussion of synergy between PWG standards, especially about the fact that UPDF was a central item in this discussion, while we have been reluctantly used to the image that we try to solve challenges, which exist in the day-by-day work, but are tended to be swept under the carpet.
While I was attending a number of meetings during the week - unfortunately not the first PSI meeting - I had a chance to learn that UPDF is considered a target for a cooperation with the upcoming PSI standard. We had some discussion on bidirectional communication, which is not considered part of UPDF, level 1, but acknowledged as an essential part in the printing universe by us.
This certainly needs further discussion on a wider base. At least there seem to be some challenges in the print server and web services area, which have been delt with in the UPDF group. We are open for information exchange and any level of cooperation and would like to learn more about the development environment.
We agreed that we would need at least one more face-to-face meeting, but left it open, during which PWG conference that could be. Watch the email traffic the next days and comment, please.
Norbert Schade