Some time ago I proposed five additional marketing documents, which might be added to the UPDF web site.
Candidates are:
1. The idea of UPDF.
I have a small rough document available, which is not exactly on the level I'd like to see it and has to be reviewed.
I'll bring with me to Toronto. I asking for help to do this.
2. UPDF introduction in 10 minutes.
Find a proposal below.
Except some typos I think this is my final proposal.
I am asking for comments and editor's review from the field.
3. Comparison between GPD and UPDF.
I am asking for help here.
4. Comparison between PPD and UPDF.
I am asking for help here.
5. How to build your own UPDF description from an existing sample.
Perhaps someone from the sample implementation group could do that, so that we have some different view how to do the task.
All documents are supposed to be short (like two to four pages).
We do not want to provide indepth information for every detail, but give a newcomer a chance to get the required information as compressed as possible.
All documents have to be final before the fall conference.
Regards
Norbert Schade
----- Original Message -----
From: Norbert Schade
To: Norbert Schade
Sent: Tuesday, July 24, 2001 8:00 PM
Subject: UPDF introduction in 10 minutes
UPDF (Universal Printer Description Format) is a data driven concept, which provides input parameters drivers need to render and output printer data.
Q.: Is UPDF is new idea?
A.: No, there are a other concepts, which try to accomplish a similar target.
1. There is PPD.
This is a PostScript specific concept.
In the view of many printer manufacturers and driver developers it has not evolved to nowadays needs.
PPD are not based on XML.
PPD do not support Unicode. Font handling is described outside the format.
2. GPD
This is a Microsoft specific concept, which is dedicated to Microsoft platforms.
GPD are not based on XML.
GPD do not support Unicode. Font handling is described outside the format.
3. Proprietary formats.
There are a number of company proprietary formats, which are all dedicated to a specific platform or driver system.
Q.: So why UPDF?
A.: UPDF describes all data a generic driver for enterprise printers needs.
1. The concept is based on XML.
2. It supports Unicode.
3. It is platform independent.
Q.: What makes UPDF outstanding against other concepts?
A.: It provides some core architecture, which allows the required complexity and flexibility.
1. There are the four pillars of UPDF.
1.1. The Parameter Converter.
To be able to describe text based printer data as well as binary one, it needs a special syntax.
The Parameter Converter is the solution for that, as it can describe text based and binary data, the reference to driver keywords, the reference to UPDF keywords and even conditional output.
This functionality is not only used to specify PDL data, but is used all over the place in UPDF attributes.
1.2. Interdependencies.
Interdependencies can easily be converted from other data concepts.
The UPDF functionality is exceeding, as it allows more complex conditions by support of 'AND' and 'OR' combinations. It also allows other actions than just filtering like specifying conditional user interface messages.
1.3. Event handlers.
The order of command sequences in different PDL differs.
Event handlers allow specifying a large number of print events including Job start/end, PDL start/end as well as some feature specific events like the description of a raster graphic print sequence.
1.4. Composite features.
Basic features like media size, media source, device resolution, etc. can be arbitrarily be assembled to composite features to allow the specification of high level features.
Samples include predefined settings for subdialogs or driver defaults.
2. A driver default per locale is supported.
3. Device fonts are supported.
4. Localized user interface strings as well as messages are supported.
5. Extensible configuration.
UPDF is prepared to describe devices and installable options known at the time the device is going to be launched as well as installable options, which will be launched at a later date.
The device description can grow with the availability of installable options without the need of changing the original device description.
6. User group policies.
Supervisors and system administrators are always looking for chances to specify user or user group specific descriptions on top of the device description.
This includes driver settings different from driver defaults as well as additional features (based on the composite features functionality) to determine the appearance of driver features.
This functionality allows presetting certain features or hiding certain features completely for certain users.
Q.: Where will UPDF device description be available?
A.: Because of its platform independency the description can be provide on storage media like CD or on web site and even in the device itself.
Q.: When will UPDF be available to the public?
A.: UPDF, level 1, is supposed to be introduced to the public in late fall 2001.
Q.: Where can I get information about the current level of UPDF?
A.: People interested in the current level can always look at the UPDF web site.
The UPDF standard is embraced by the PWG (Printer Working Group) and can be accessed from www.pwg.org in the Internet.
1. UPDF is currently based on DTD (Document Type Definitions). That may change to schemas in the near future.
The current level of dtd files can be accessed from
ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/DTD/
2. A UPDF reference sample with a XML description can be accessed from
ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML_Samples/
3. A functional specification documentation is growing these days.
The current level can always be accessed from the UPDF web site.
A direct link is
ftp://ftp.pwg.org/pub/pwg/www/updf/UPDF_Functional_Specification.pdf
Q.: What is the simplified architecture of UPDF?
A.: The basic architecture is determined by a small number of XML files.
1. The unit configurations.
1.1. The device unit configuration. One file per device.
This is the driver's data entry point!
A driver will find references to the device description file, the command sequence file as well as to all locale files plus a few attributes.
1.1. The optional unit configuration. One file per optional unit.
Similar structure to the device configuration.
The driver will find the references specific to an optional unit plus a few attributes.
During installation this information may be moved into the device configuration or a platform specific reference may maintain this information.
2. The device description. One file per device.
This is the core UPDF file providing the overall device description.
You will find a number of references to command sequences and localized user interface strings.
It was a learning effect for the group that it might be better to separate the real PDL command sequences from the device description as well as the localization of user interface strings and messages.
This leverages the work for PDL experts and translators, as they are not confronted with an overwhelming amount of information they are not interested in when doing there job.
3. Command sequences. One file per device description.
This XML file holds all the PDL command sequences.
A command sequence file may hold more than the command sequences used by one device description to make it reusable. This is not a problem, as the references are totally maintained by the device description.
4. Localized user interface strings. One file per locale per device description.
This XML file holds all the user interface strings for features and messages.
A locale file may hold more than the user interface strings used by one device description to make it reusable. This is not a problem, as the references are totally maintained by the device description.
Q.: Is an UPDF description supposed to be used in its original XML form?
A.: This is left to the actual implementation.
By watching the ongoing implementations it looks more that the XML information is converted into some platform specific format. That provides some significant performance advantages and seems to help with platform specific implementations.
This may happen during installation.
Q.: How would a developer create device font data?
A.: This is left to the UPDF developer.
Basically someone could do that manually by filling out the proper attributes.
But we are assuming that conversion tools will be written to convert data already available for device fonts supported in other data concepts.
We are also in touch with the major font vendors like AGFA and Bitstream to have them develop concerters for their own databases.
Q.: Are there limitations in an UPDF description?
A.: Yes, there are.
To be able to finish a the current level we have limited ourselves not to support certain features, as there are:
1. Palette handling.
It is currently discussed, whether this is required to be supported in level 1.
2. Raster compression.
This is likely not supported in level 1, but is a candidate for the next level.
3. Vector graphic.
UPDF describes raster graphic for every PDL supported.
A driver will find exact information about the PDL supported in a device description. So if a driver supports additional functionality for certain PDL, it can securely make use of it.
4. Font download format.
UPDF may support the specification of certain download command sequences, but it is not described the structure of a download format.
A driver will find exact information about the PDL supported in a device description. So if a driver supports additional functionality for certain PDL, it can securely make use of it.
5. Application flags.
As applications may work differently under different platforms, this is not considered a feature of UPDF.
Q.: Are there certain assumptions UPDF makes?
A.: Yes, there are.
The current format of UPDF includes the support of JCL (Job Control Language).
The format provides a list of keywords of a JCL like PJL, but it is not specifying the syntax of that JCL.
There is supposed to be a JCL specific library available on the platform, which converts the keywords into proper JCL language.
This concept has been chosen, as there are platform specific components available in a number of cases, which are designed to do exactly that task, and as some newer JCL (Bluetooth, JDF) are described in XML as well. And we don't want to describe that a second time.
This archive was generated by hypermail 2b29 : Tue Jul 24 2001 - 20:39:35 EDT