Latest_Meeting_Minutes-0001.htm

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html;charset=iso-8859-1"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <meta name=ProgId content=FrontPage.Editor.Document> <meta name=Generator content="Microsoft FrontPage 4.0"> <meta name=Originator content="Microsoft Word 9"> <link rel=File-List href="./Latest_Meeting_Minutes_files/filelist.xml"> <title>Meeting notes from the UPDF meeting in Toronto, July 30th 2001</title>  <style>  </style>  </head> <body bgcolor=silver background="cid:002501c0b3d4$b6a9e4c0$500714ac@NSCHADEW1" lang=EN-US style='tab-interval:.5in'>  <div class=Section1> Meeting notes from the UPDF meeting in Los Angeles, February 4th 2002.<o:p></o:p> <![if !supportEmptyParas]> <![endif]><o:p></o:p> Attendees<o:p></o:p> Ted Tronson, Novell Lee Farell, Canon Mark Hamzy, IBM Harry Lewis, IBM Jim Sommer, Granite Systems Steve Schwartz, Peerless Fumio Nagazaka, EPSON Norbert Schade, Oak Technology, Inc.  <![if !supportEmptyParas]> <![endif]><o:p></o:p> <h2>Composite features</h2> We discussed a slightly modified version of the implementation of composite features. These are the new attributes: As intended at the last conference we add a boolean UserExtensible attribute to the CompositeFeature element. If set the driver may offer functionality to allow the end user to create and manage his/her own records of a specific composite feature. We assume this would require some extra buttons in a graphic UI (New/Delete, etc.) and the calling of a subdialog in most cases. But eventually it depends on the implementation of the driver. If not set, the subdialog may still be called for information purpose, but the single features are not supposed to be changed. We added an attribute DominantFeature to the CompositeFeature element. If not set, the composite feature is expected to be used within the driver's UI only and not to affect communication with the OS kernel. The single features, composed to the composite feature, may stay active in the driver's UI. This depends on the driver's implementation. If the attribute refers to another single feature, this one becomes the dominant feature. The Proprietary_ID of the ComponentSet may overwrite the original one of the corresponding single feature. All single features are not supposed to appear in the standard dialog of the driver, only in the subdialog entered by the Edit/New button next to the composite features. It is possible to deal with command sequences like in single features, though this is not expected to be the normal case. If there is a dominant feature, all other single features have to be announced as something 'AutoSelect' to the OS kernel. Therefore we need some functionality in the single features to do that. Watch the email traffic the next days for details. The composite features in the new design were agreed on by the developers attending the meeting. Please check whether the design is sufficient for every challenge you are facing. <![endif]><o:p></o:p> <h2>User policies</h2> We also could agree on the latest implementation of user policies. A system administrator is not allowed to change the original device description of the printer manufacturer. But he will be enabled to create his/her own user policy description additionally. The reference is made from the device configuration file. There is an optional reference to a user policy reference and optional, multiple references to new locales. There can be just one locale to kind of extend the original. Or all of them can be extended. Even new ones can be added, but I would not expect that to be the standard case. User policies allow an administrator to specify new interdependencies, new composite features, new UI strings because of the new composite features, substitute original UI strings, set new defaults. Please check whether the design is sufficient for every challenge you are facing.  <![endif]><o:p></o:p> <h2>Events</h2> Further we worked out some redesign for events. Events are still considered a powerful tool to help defining a proper print stream. Instead of listing different event elements we now allow the developer to specify as many EventElement elements as necessary. An Event_ID (e.g. Job, Page, Graphic, Band, etc.) and an Event_IDRelation (Start or End) attribute tells the driver about the meaning of the event. Every EventElement can refer to a command sequence. This will be described more in detail in subsequent emails, as this is very important. Watch the reflector. As previously proposed we implemented an optional element OptionalUnitRelation with Relation (Before or After) and ID attributes. This allows a developer like of a third party to specify the position within the print stream of an original device description. We think that provides all the required power to developers of optional units.   Raster graphic We spent the remaining time on raster graphic and related features like color and halftoning. While this was mainly brainstorming, it will be our major item at the next conference. We will try to prepare it more in detail the next weeks. <![endif]><o:p></o:p> Norbert Schade </div> </body> </html>