| UPDF Minutes New Orleans |
| Sandra Matts | Hewlett-Packard |
| William Zhang | Canon |
| Rick Yardumian | Xerox |
| Ben Brezinski | Hewlett-Packard |
| Don Criscione | Xionics |
| Michael Wu | Kodak |
| Sandra Matts | Hewlett-Packard |
| William Zhang | Canon |
| Rick Yardumian | Xerox |
| Ben Brezinski | Hewlett-Packard |
| Don Criscione | Xionics |
| Michael Wu | Kodak |
| Sandra Matts | Hewlett-Packard |
| Harry Lewis | IBM |
| Brian Batchelder | Hewlett-Packard |
| Bill Wagner | DPI |
| Ben Brezinski | Hewlett-Packard |
| Don Criscione | Xionics |
| Rick Yardumian | Xerox |
| Don Wright | Lexmark |
| Ron Bergman | Hitachi-Koki |
| Stuart Rowley | Kyocere |
| Michael Wu | Kodak |
| William Zhang | Canon |
| Richard Hart | Compaq |
| Hugo Parra | Novell |
| Yuji Sasaki | JCI |
| Mabry Dozier | QMS |
| Lee Farrell | Canon |
During the last meeting in Miami on March it was decided to
concentrate on certain categories to speed definition of the UPDF specification. The
categories for the User Interface are:
These consist of the actual tags needed to specify a user interface that a UPDF driver will use to display options to the user. A way to allow UPDFs to be localized in an easy manner that is efficient. And a way to specify resources for UPDF that is not dependent on any operating system. A generic constraint mechanism that can specify dependencies between multiple paper handling devices. A way for printer vendors to customize portions of the user interface. User Interface components, localization, and resources It was decided that all of the user interface tags will be optional. There are low end printers that may not want to present any user interface at all. And there may be devices such as a digital camera where it doesn’t make sense to specify a user interface. The digital camera could pull the UPDF from the printer and send the rendered data directly to the printer device. Rather than trying to mandate user interface tags, the UPDF XML syntax will allow for any number of user defined UI tags. The general syntax will be a user defined tag, an attribute to show how it should be displayed, and a command to select the option if needed. The attribute to show how the tag should be displayed will be a list of ui controls that are generic across multiple operating systems. An example is a list control or an edit field. The spec will also allow for vendors to create user defined ui controls in the UPDF file. A standard driver will parse the ui tags and display the controls it understands. The driver would parse and probably throw away the vendor defined ui controls since it doesn’t understand how to display them. A vendor’s monolithic driver would be able to parse the same UPDF file and would understand how to display the unique vendor defined ui controls. UIList := UIElement+ A list of user interface tags consist of one or more ui elements. Each ui element can be a tag with the corresponding attributes or another ui element. Eventually all ui elements will be parsed down to a ui tag and attributes for that tag. Each UI element shall (must) always have a default element defined. Examples: DefaultResolution and DefaultPaperSize. It was noted that the tags in the UPDF DTD file were not consistent. Most of the tags followed the convention of first letter capitalized and the rest of the word lower case. For example: PaperSize and PaperMedia. There are currently some tags that are all CAPS. Unless there is a reason those that are in Caps will be converted to the standard notation of only first letter of word capitalized. Tags TonerSaves and Resolution is Laser specific. Not all printers have a need for those tags. Suggestion that we have a Print Quality tag with attributes tied to the tag that allow for the vendor to decide what should be included in the PQ tag. The Laser printers can include TonerSaves and Resolution in the attribute list for PQ. Current PQ tag lists Draft, Low, Medium, and High. The DTD will have to be changed to allow for the attribute list. Localization and resources Localized strings can be put into a separate file or they can also be inserted into a section of the UPDF file. It’s up to the vendor to decide which is better for them. The UPDF driver could parse the beginning of the UPDF file and then based on the language retrieve the strings either from the string file or from the local section of the UPDF file. The localized strings should be in an XML based format and not in a resource based format. This way we are not tied to any particular operating system. There may have to be tools created to be able to localize in an XML based format. All tools today generally localize strings in a string table that is compiled into a resource file. There was some discussion on whether localization tools can be used on a non-resource type file. The UI tags should have three methods for localized strings to be added. The first is for the string itself to be added as an attribute to the UI tag. This could be used for simple UPDFs that do not support more than one language. The second method is to have the localized strings in a separate XML based file. If a UPDF file is localized into 20 languages then there would be 20 separate files. The third method is to add the localized strings into an identified section of the UPDF file. There is one UPDF file for all languages that contains a section listing the 20 languages and their corresponding strings. This creates a much larger file but there would not be the 20 auxiliary files needed in the second method. A UPDF file embedded in the printer may choose the third method. Need to make sure the local section allows for a priority list of tags such as PaperSize. Have to be able to list DefaultPaperSizes: "letter", "A4". Doesn’t have to be in this exact syntax. ISO document already lists a set of locals and a three letter acronym to identify the local. We have to find it and use it. Possibly look into grouping locals together. This way we can list DefaultPaperSize = Letter for US and UK. Constraints PPD allows the specification of only two UI constraints. We need to generalize to make it n-way instead of 2-way. An example is if duplexer is installed and printer memory > 36 Mg and PaperSize = letter, then duplex can be enabled. Probably not acceptable to decide constraints when the user hits the OK button. It has to be in real time. The user should get immediate feedback that an option is invalid. Constraints have to be listed as a set of rules. Each set of rules has an action associated with it and a message. For example: Duplexer = installed and Or Duplexer = not installed and We may want more than an enumerated list. Can we add expressions that are evaluated by the UPDF driver. Have to allow for UI grouping. If treeview then subnodes. If tab pages then each grouping can be in a separate tab page. MacOS print subsystem will be shown this May at the developers conference called the kitchen. See how it will look. Unix uses filters for printing. There is currently a PPD filter. Don’t know how the UI looks. A filter for UPDF will have to be written for UDPF support in Unix. How much of an effort is this? Embedded systems generally will not display any UI at all. |
The categories for the Imaging portion of UPDF are:
Paper handling In UPDF.dtd the enumerated PaperSize is windows specific. Look at ISO definition of PaperSize and use that. Look to see if there is a definition for Input / Output Bins also. Use that terminology instead of Windows. Paper.Area.ptAreaPixel - how does this map to ImageableArea, PaperDimension and other PPD keywords. Find the mapping document and see how I interpreted the XML tags for PaperMedia. DefaultPaper is set up to be a list of paper sizes. List implies a priority of paper sizes. Add our definition for Locals for localization to be consistent with the UI. Local tag has list of locals which implies an order. Ordered list. Paper Handling tag. Extend to allow for user -defined types not just the enumerated pre-defined input / output types. DefaultPaperSource and DefaultPaperDestination. We should use the local mechanism for Default to be consistent with our other defaults. Add Banner paper size for DeskJets. Low end printers do this frequently. Finishings. Need to add a user defined tag for Finishings. All of the fields are pre-defined currently. PDL Must be able to use multiple languages in one UPDF. Three aspects. 1. List high level languages ie PCL5 and PS level 3. 2. Be able to specify the language strings. 3. Raster mode. Language translator can be a plug-in that does the translation. Shared library with an API for each language. This way one module can provide support for PS and another module provides support for PCL. <Languages supported> with an attribute list. Class of modules that target high end, mid, and low end. Look at what Jini does. How does the API look for Unix, MacOS, and Windows. MacOS already has the plug-in concept. See what they are doing. How do we define an OS independent API? The different OSs have about 75%-80% commonality. See what the differences are. Also we have to version the API since new versions of OSs will add new features. Fonts Device fonts. Windows uses the IFIMETRICS data structure. We have to see what MacOS and Linux do. Make sure the FontEncoding and FontCharset is a complete list. How do we specify font metrics in an OS independent manner. Do we use resources or can we embed binary in an XML file. XML doc is limited. Only allowed in an entity. XML black book pg. Can be in a separate xml file. This may be better than specifying a resource file since they are Windows specific. Somehow tie the Localization to the Character set that is active. A default list. Is it strictly based on Locale or are there other ways. Grouping of char sets. Xionics found convienent. char set applies to several locales. default char set. Turkish char set document shows up in US PC. The driver is responsible for deciding if the char set is supported. If it is then a conversion is done by the driver to the char set. If not then the driver can rasterize the characters so they still print. DeskJets would say FontCharset: none or leave it empty. Empty implies no character support. Imaging / Graphics DeskJets is wrapped raster. Simple needs for raster. Once the whole page is rasterized they want a plug-in to halftone and color correct to pen format. Particular to printer model. Then the data needs to be compressed and sent to printer in bands. More general. The device specific stuff is the plug-in. Page level plug-in. How do we specify a general enough plug-in. PCL3 has different commands - PCL5 does also. Difference between DeskJet 1600C and Color LaserJet. API multiple sets low, mid, high. API 1, 2 or 3. COM way is to define an interface and extend the interface for new versions of the language. PCL-XL v1, v1.1, v2 is an example. If a simple printer does not support fonts, it returns E_NOTIMPL for the font APIs. We also want to have a simple API for just raster blasters. Color Color - see what more we need. Color Management system and ICC profiles. Must be able to associate a profile with the UPDF file similiar to how we do with PPDs and GPDs. Be able to have user defined color spaces?? |
| User Interface: look at providing a core set of well known tags such as
Paper Size and Duplex for the UPDF creator to use. All user interface tags
will be optional. This is to support low level devices that may not want to display any UI
at all. Also embedded systems such as a digital camera don't display UI. Tags should
follow a format similiar to this: <Duplex Control and Command are required attributes. Names and HelpText are optional attributes. For controls we define the look or type of widget. Do we allow for parameters. Parameters would include the x,y position or width and length of a widget. All strings that are localized can be specified in three ways. 1. Embed the actual string in the attribute 2. Put all the strings in a separate section in the same UPDF file. 3. Put all of the strings into a separate file. This file can be local to the system or it can be on a web site. Use SHALL and MAY in the spec, test doument should recommend limits to testing parameters. Make it part of implementor's guide. Make sure there is a crash test - maximum config. B-di implementor's guide: mapping guide, fields from IPP to UPDF. Make sure all fields are covered. IPP provides richest set. Paper Sizes: need to extend to include user defined. <PaperSize enumerated list or pre-defined types user defined> </PaperSize> user defined should be an empty tag or an optional attribute. Attributes may have to be added for mmSize and allow for variable sizes. Banner paper is special case of variable size. <PrintQuality> There are three different desired results with the PrintQuality tag for a typical
printer driver. PQ doesn't mean the same for all kinds of devices. Good, Better, Best is good enough for 80% of the market. Localization and resources: Use XML method for designating location of localized string file. Local file is NOT file system independent. We should use care in specifying. Put examples in implementor's guide and make sure testing covers.Assumption is that Default Language and Locale becomes default for all aspects if other defaults are not specified. Not just the UI defaults. Don Criscione presented a possible constraint specification. General opinion is to make constraints n-way not just 2-way. It was noted there are two levels of optional. An optional keyword in the specification and that a driver may optionally support all required keywords. A UPDF compliant and conformant driver has to support all required keywords. A monolithic driver may choose to not support all required keywords but then it is not compliant.
|
| Specification is at www.w3.org/xml XML FAQ is at www.ucc.ie./xml Tim Bray’s annotated XML spec: www.xml.com/xml/pub/axml/axmlinto.html Robin Cover’s XML site: www.sil.org/sgml/xml.html Contains a large number of links to every XML resource XML info: www.xmlinfo.com Seybold site: www.xml.com XML Software: www.xmlsoftware.com |
| UPDF Chairperson: Sandra Matts - Hewlett-Packard Email: sandram@boi.hp.com Mail list is upd@pwg.org FTP archive is ftp://ftp.pwg.org/pub/pwg PWG web site is www.pwg.org Meetings schedule for 1999 is at www.pwg.org/chair/meet99.html |
General Discussion: upd@pwg.org
Archive: ftp://ftp.pwg.org/pub/upd