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.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>We could define a syntax for Predefined_ID/Proprietary_ID in
two-dimensional features like 'keyword' + '_' + horizontal value + 'x' +
vertical value (leans heavily on the standardized media names
spec).</FONT></DIV>
<DIV><FONT size=2>This could be used for</FONT></DIV>
<DIV><FONT size=2>virtual units:
units_7200x7200</FONT></DIV>
<DIV><FONT size=2>raster
resolution resolution_600x600</FONT></DIV>
<DIV><FONT size=2>
<DIV><FONT size=2>positioning
positioning_300x300</FONT></DIV></FONT></DIV>
<DIV><FONT size=2>As a matter of fact we already use it for nup:</FONT></DIV>
<DIV><FONT size=2>nup
nup_1x1 (new due to a
change discussed in Portland, will be on the web within next days)</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>would that solve everything so we could work with
Predefined_ID/Proprietary_ID in all these features?</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>General requirement for that kind of syntax: </FONT></DIV>
<DIV><FONT size=2>1. The entry in the Predefined_ID follows the same syntax as
the entry in the Proprietary_ID.</FONT></DIV>
<DIV><FONT size=2>2. For positioning we cannot generally expect that a
positioning command specifies both the horizontal and vertical dimension. So we
have to tell about omissions. The simplest rule might be that the 'x' must be
there, the value not necessarily. That would allow 'positioning_300x300',
'positioning_300x' as well as 'positioning_x300'.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Another thought:</FONT></DIV>
<DIV><FONT size=2>We might remove the feature device resolution completely from
our standard, as we consider it a generic feature. Drivers really don't use it
for rendering, only for sending a JCL command to the device. Drivers don't even
really save it in any kind of device capabilities structure other than just
storing the last UI setting. And we could as well do some calculation in the
command sequences, if the device resolution is 1200dpi and the raster resolution
is 600dpi so that the positioning parameter has be multiplied by 2, as any value
coming from the application/system will be based on the raster
resolution.</FONT></DIV>
<DIV><FONT size=2>The fact that some raster resolutions only go with certain
device resolutions, is a matter of dependencies and simple.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Comments???</FONT></DIV>
<DIV><FONT size=2></FONT> </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>