attachment-0001
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Haven't written that up this way.</FONT></DIV>
<DIV><FONT size=2>As David and Bob asked similar questions from different angles
I thought this might be a good opportunity.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>
<P>How to define a print file</P>
<P>The request to be able to provide parameters for features to be used in print
files evolved into support of command sequences and events over time.</P>
<P>Binary terms had to be supported as well as plain text. It was required to
specify where in the print file a certain command sequence should appear.</P>
<P>Later another decision was made: The real command sequences as used in PDL
and probably job language was separated from the higher level device
description, which is supposed to be more human readable. Therefore we created a
separate schema for command sequences so that PDL experts could convert one PDL
specification to another while keeping the device description almost aside. We
did not want to work with gigantic switch definitions. So we attached parameter
references to the features.</P>
<P>To be able to do all this in XML we needed a tool we call Parameter
Converter. This allows for the definition of binary terms in ASCII, references
to keywords and attributes as well as simpel IF/ELSE statements.</P>
<P>A high level description of the envisioned process may look like the
following:</P>
<P>1. The driver holds a structure with the non-ambiguous setting of each
attribute (means feature in many cases), but is prepared being overruled by the
user's application.</P>
<P>2. The driver holds a structure with the non-ambiguous setting of all DRV_
keys.</P>
<P>3. Prepare a Parameter Converter function.</P>
<P>4. Any UPDF core driver is expected to understand all possible events, on
start as well as on end of it.</P>
<P>5. When an event occurs for the driver, it checks the event list in the
device description and checks all event records with that specific event. It may
well find more than one record. They should be listed nicely, but I wouldn't
rely on that. The order of records for the same event determine the order of
command seqences.</P>
<P>6. For all records of this event: Feed the Parameter Converter with the
command sequence of the corresponding XML file identified by the command
sequence reference in the event. The other two parameter for the function are
the pointer to the two structures of 1. and 2. (that's how I might do, feel free
to do it a different way).</P>
<P>Within the Parameter Converter</P>
<P>7. The command sequence may show references to unique attributes (dot works
as separator, reference to Parameter is wrong as that's an element but no
attribute, reference to ID is wrong as that's an attribute but ambiguous,
reference to Parameter.ID is better but still ambiguous, reference to
MediaSize_Record.Parameter.ID is fine) or DRV_ keys. The ID attribute will show
another parameter reference for a special feature setting, which can then be
finally resolved in the command sequence XML file (ResolvedParameters
section).</P>
<P>Check next event and start with 6. until done with all events.</P>
<P>Some background info on the Parameter Converter:</P>
<P>It started out as reverse Polish notation, but the request was a more human
readable syntax. It should understand either ASCII characters or terms of
certain syntax. These terms start with a two-byte format string, which tell
about the expected output format. IF/ELSE structures are supported, but I
wouldn't rely too much on nesting when developing the XML for a device.</P>
<P>That's what I think. Did I forget something or wasn't clear enough? Ask in
detail!</P>
<P>Regards</P>
<P>Norbert</FONT></P></DIV>
<DIV><FONT size=2>Norbert Schade<BR>69 Prescott Drive<BR>North Chelmsford, MA
01863<BR>978-251-1017<BR><A
href="mailto:norbertschade@attbi.com">norbertschade@attbi.com</A></FONT></DIV></BODY></HTML>