this one didn't make it over the pwg-announce reflector.
so I send to the UPD reflector.
Norbert
A Q&A file is attached with this one. This one may grow over the next days.
This is the first of three notes intended to provide additional background information on the UPDF architecture.
As a base I always recommend page 11 of the UPDF specification: the high level overview. That is a PowerPoint picture demonstrating the key components of the UPDF configuration for one model.
Then it's worth thinking about the conceptional intention of how the instances are supposed to be used, while different parties may have different implementations.
As you can see in the attached document with the simple question & answer pairs, the UPDF standard is not based on one single schema.
Why?
- It is meant to be used by large IHVs, who want to re-use their work where possible.
- UPDF is extensible. That means you can add instances like an additional language without changing the actual instances.
How would somebody design that?
That's basically left to you, but below's some hint how I might do it.
Sample architecture
Imagine an IHV with a laser and an ink jet division.
That company may decide on some proprietary rules:
Rule 1: Everybody uses the same text strings per language.
Action 1a: Both divisions share over 95% of the text strings, but both need some special ones.
A UPDF locale instance handles one language. It can hold more strings than needed for one special model. So all strings of both divisions can be merged into one locale instance per language. The UPDF device description instance decides on which strings are used for a special model.
Conclusion: the whole company could use the same UPDF locale instance per language.
Action 1b: The company currently supports their models in 15 languages. They would like to add three new languages. The idea is that the three new languages can be added to new drivers as separate instances. It also means that drivers in the field could be extended without changing any of the existing files nor do these drivers have to be replaced or even re-installed. A language could also be switched without re-installation of the whole driver. One model may use 6 languages out of the pool, another may use 10 (a partly overlapping list of languages is fine).
Rule 2: We create a UPDF command sequence instance per PDL.
Background: Let's assume all lasers of the IHV speak PostScript and PCL 6, all ink jets are raster devices.
At some point the UPDF group decided that it's better to split the higher level feature lists and the PDL stuff to allow the various specialists to work on their part.
A UPDF device description instance for the laser devices speaking PostScript may look surprisingly similar to the one speaking PCL 6, while the command sequence instances are completely different.
All of the 15 laser models the IHV speak PCL 6, but some are a bit different. The command sequence instance can hold more commands than needed for one special model (see the language stuff above). You could use the same PCL 6 command sequence instance for various models, while the UPDF device description is always unique.
Quintessence: with that basic architecture and a number of models being described you can create a set of UPDF instances for a new model almost like going shopping.
The likelyhood of finding all text strings and command sequences you need is pretty high. So you pick the locale and command sequences instances you need.
You take a device description instance of a similar model and make your modifications - likely a few only.
Now you combine the instances for your new model with a unique device configuration.
Done.
This concept will be a time saver once you have built a default set of instances.
It may help to think of the different instances as plug-ins to the heart of the description: the device description instance.
So the basic set of UPDF instances per model includes one unique device configuration instance (not much more than a list of instance references), one unique device description instance, one common command sequence instance (might be shared with other models) and one or more locale instances (very likely shared with other models).
Please let me know, if you'd like to know further details.
Regards
Norbert Schade
Norbert Schade
Software Manager
Oasis Semiconductor, Inc.
201 Jones Road
Waltham, MA 02451
USA
tel. 1-781-370-8929
fax. 1-781-370-8990
email: norbert.schade@oasissemi.com
This archive was generated by hypermail 2b29 : Fri Jun 11 2004 - 08:13:09 EDT