Meeting notes from the UPDF meeting in Tampa, March 5th 2001.

We will meet face-to-face in Toronto end of July and at the fall conference in Texas.

The first is proposed to be April, 20th, at noon EST. Please indicate your availability in the week before. I will provide an agenda for that one.

Depending on progress there are one or two more planned before Toronto.

Proposal of first sample model with a full description based on UPDF, level 1, until end of April. It will be a 'HP LaserJet 8150' description for PCL 5e, provided by Oak Technology, editor Norbert Schade. The description will be frozen April, 30th, on the level of that day, called 'UPDF Sample 1'.

This shall be the base for all sample implementations in drivers/clients.

Job attributes like PJL/IPP are not an issue for that version as well as device resident fonts. We hope to get the rest done quite completely.

The only human language supported will be US English. German will be supported in few selected cases for demonstration purpose.

Proposal of at least four more sample models from four more IHV. We are in contact with Lexmark and Hitachi and are confident to come to an agreement with them. Candidates are Xerox and QMS/Minolta. Others are welcome. Pleas contact me the next two weeks to make proper preparations.

For sample device implementations we expect at least one driver developer per IHV to dedicate two working days minimum per month. The developers have to understand the complete structure of a UPDF description and have a tool for XML editing ready for the job.

Depending on the effort and the corporate identity people want to put into the job, the samples will stay more or less closely to 'UPDF Sample 1'.

The first target date for those samples is the Toronto conference end of July. Samples will be presented there the first time to the whole UPDF group. Work on these samples will continue the rest of the year.

As the main goal for these samples is to give different groups of driver developers the chance to get some expertise, we hope as well to get some feedback during that time about problematic issues.

I will lead this development effort myself during the whole process.

Independent from sample model implementations I will work on two sample device fonts. This is for demonstration purpose only. I am looking for some help here.

Target date is about four weeks before Toronto. We want to simulate the situation that a font vendor prepares font data for further implementation into a full model implementation.

Sample implementations on the host side are intended as well. Mark VanderWiele from IBM will work on a Linux implementation. Jim Sommer from Granite Systems will work on a MS Windows implementation.

The fall conference in Texas is our target date for a first presentation of the full UPDF format, level 1, to the public including some sample implementations.

We need to work more on the marketing side of our spec. Although Mark VanderWiele and Jim Sommer are engaged in that area, we are looking for some further help here.

This includes editing of our documents on the web page for better understanding of the overall idea and easier implementation as well as working out differences between other device descriptions and UPDF.

It is every unit, which can be removed from the main unit or replaced by another unit.

There will be a new XML file "UPDF Model Configuration - xxx.xml".

This short file will be the real data entry point for the driver. It is more an organizational file.

It will reference to the full UPDF description for this model, a "UPDF Model Description - xxx.xml" file. That's the file we know from the past and is our current sample.

It references as well to the full UPDF descriptions of all shipping installable options. Options that come with a model at shipping time are listed from beginning on and have a shipping flag. These options should never be deleted from the configuration file.

Every option has a selection flag indicating whether it currently is selected or not. Shipping options should have the selection flag set by default.

Every option has a category element. Categories can be input, ouput, fonts, RAM, other, etc. (has to be worked out in detail). This can be used by the driver to show an option in a certain control in the UI. It can of course be ignored as well.

During installation a UPDF model configuration file will be copied and renamed to a "UPDF Device Configuration - xxx.xml", as it is now a device specific configuration. A company may buy five devices of one model.

Installable options can be added to UPDF device configuration even after the first installation of the main device.

The original UPDF model configuration is no more needed after installation.

There will be a "UPDF Option Configuration - xxx.xml" file per installable option.

It will reference to the full UPDF description for this installable option, a "UPDF Option Description - xxx.xml" file based on the same dtd as the UPDF model description.

A UPDF option configuration has all the entries necessary to be copied to the UPDF device configuration like the shipping flag (set to off) and the selection flag (set to off). These entries will be copied to the target UPDF device configuration.

There is no UPDF option configuration for shipping options. A driver should never remove entries about UPDF option descriptions of shipping installable options from UPDF device configurations.

A UPDF option configuration also has information with which UPDF model configurations it can be used.

A UPDF option configuration is no more needed after installation.

We haven't specified anything so far, that certain installable options can not go with certain others the same time.

'xxx' in all above sample will be replaced by a meaningful name for each file by the developer. A dash ('-') is the separator of the fixed part of the file name and the flexible part.

I will work on this stuff the next days. So feedback is welcome. I will ship samples soon over the Internet and store it on the weg page as well. As you can see we have modified the naming conventions for files. I will refer to that in a separate document.

We partly have implemented the global media spec (Ron Bergman's spec) into UPDF already. We will finish that.

As a consequence of that we will no more use width and height attributes for media size.

We have agreed that a FeedingMethod may keep some nice information for the paper path, but is not necessary information for the driver to create a print file.

There will be a media size attribute RotatedFormat. Values are boolean. If set to True it indicates the driver must rotate the page.

Media source has to be reviewed. I will need some help here, as my notes are pure. Watch the next days.

This subject has been opened in San Diego, but we did not have time to continue to work on it.

The spec of this section has to be completed in email traffic the next weeks.