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>&nbsp;</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>