After some discussions I implemented a number of new features and made some changes. Please find the new files on our web sites
ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/DTD/
ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML_Samples/
The major change is the specification of connectors. I have to change the 'UPDF Functional Specification' for that, but these are some notes upfront for those, who want to check the files.
The way we can support installable options is a significant differentiation feature of UPDF against other concepts.
I will continue to expose the 'Extensible Configurations' as something unique to our concept.
That's why we spent some more time on it to ensure it fulfils the level we intend.
The easiest way to understand it is to check the UPDF.dtd and the corresponding device description for the HP LaserJet 9000. The 'TBD_' prefix has been removed from the connectors feature, as we feel it is final now.
See Device_Header, Connectors. You find an optional list for connectors to other units (childs) and another list for connectors, where the current unit can be connected to (this is not possible for the master unit = the printer itself).
Each can have one or more connectors. While we stay consistent with providing a Master_ID the unit has to provide a technical description for every connector. In my sample I called it just 'Input_Underneath'. In reality this might be much more technical like a serial number. I recommend to stay with the exact technical term, as developers may look for that term later.
The Master_Name_ID is referencing to the locale to tell what UI string has to be used for the label. This represents the label on a typical Configure tab like the title for all the optional input trays 'Optional Input Trays:' next to the corresponding combo box.
The attribute Connector_Unused_Name_ID references to the locale as well. This shows the UI string in case a connector is unused. It represents the FALSE case for booleans as well (if somebody wants to use check boxes). Watch that this attribute is optional. If you do not use it, it will tell the driver that there is no entry for 'Unused'. That means this connector needs one assignment in any case (some devices may have no permanent input trays and exactly one connector for input trays, but the input trays can be replaced. When you remove the old one, but do not attach a new one, you do not have a complete device any more = no input tray at all).
To connect to a parent we mainly need the Connector_Technical_ID. As we want to be safe, we added a reference to the corresponding unit description as well to avoid problems when connectors have the same technical identification by accident, but are technically different.
The configuration files do not need a category any more. Removed.
The configuration file for optional units has become extremely simple now. Fine with me.
The configuration file for the device unit (the printer) is as simple for the device unit itself.
When it comes to listing optional units we have to be more careful.
We still go with an attribute for a shipping unit (optional, default=FALSE) to indicate that an option is shipped with the device, but can be replaced. Shipping units should never be removed from the device configuration, but can be disconnected (clear the ConnectorUnit_Description_Reference and Connector_Technical_ID attributes). Shipping units are shown in the driver as selected by default always right after first installation.
Other optional units may be added to the initial device configuration as well even if they are not shipping units, but as the developer simply knows about them when creating the device description. He/she may or may not fill out the ConnectorUnit_Description_Reference and Connector_Technical_ID attributes (I would, especially when they can only be connected to one parent connector).
A driver may write its own configuration file after first installation and from then on. So it may update the device configuration XML file or not, if it saves that information somewhere else like in a registry.
In case a driver wants to save it properly in the device configuration XML file, I seriously recommend to fill out the ConnectorUnit_Description_Reference and Connector_Technical_ID attributes.
For new optional units the driver may check for optional units in the device configuration XML file with the two attributes not filled out or for an optional configuration XML file at another place (directory, web site, etc).
If some optional units can connect to more than one connector of the it might be necessary to remove an optional unit first and then add it to another connector - as you have to do it with the physical unit.
I feel this is a pretty good design, not accomplished anywhere else. Feel free to publish it.
In case you should like it, it is allowed to announce that publically, as some people have put some effort into it. Next to our four pillars of UPDF I consider this one of the most interesting features.
I am still searching for a proper contact to a third party developer.
The little extra task I have for you is to think about how a developer of an installable option would fill out the event handlers for JCL start, PDL start and perhaps some others, as he/she does not see the events already specified in the device description of the master unit nor of any other installable option.
Will we offer reverved places in some events for them, which will result in predefined keywords like 'at JCL start' or 'at PDL start' and the developer of the master unit description will specify the proper place, or will we create these keywords, but the driver would enter them to a place it considers correct?
This will keep us thinking when we decide on the event handlers.
See that we have added another feature under Print_Features: TBD_GenericPDLOutputList.
This is meant for some features, which have no UI representation (that differenciates them from a GenericFeature, as there is nothing to be selected, but we want to place them properly in the print file.
You see eight features prepared. I am using one in my sample to specify the PDL init (esc E in PCL5).
These features will be available in the event handlers.
I limited this to PDL, not extending it to JCL. Feedback? If I don't hear complaints, it will be considered accepted by next week Friday and the 'TBD_' prefix will be removed.
Another change in case you follow the development in detail:
I did not feel comfortable with a global and a proprietary ID for N-Up. I did not want to go with predefined values and a certain syntax for proprietary ones.
We replaced these two attributes with MediaNUp_HorizontalPages and MediaNUp_VerticalPages, two integer attributes, where the developer is freed from predefined values and the parser would detect it anyhow.
Regards
Norbert Schade
Principle Software Engineer
Host Software Group
Oak Technology, Inc.
10 Presidential Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Thu Jun 28 2001 - 13:54:43 EDT