attachment

<!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 have activated the latest color handling design after last 
Friday's meeting in Boston.</FONT></DIV>
<DIV><FONT size=2>the group agreed to the design as it was with only few 
comments.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>we moved the PlaneImplementation attribute up one level from 
the Plane element to ColorMode, as this has to be consistent per ColorMode. the 
attribute is now mandatory to avoid consistency problems of a device 
description, although the entry is redundant in case of Predefined_ID=monochrome 
(Predefined_ID is the attribute with the higher priority). Don't create a Plane 
element for monochrome either. if PlaneImplementation=PerPixel, don't create 
a&nbsp;Plane element either. A driver should ignore it anyhow in this 
case.</FONT></DIV>
<DIV><FONT size=2>we have added an entry (PerPixel) to the data type 
plane-implementation-enum.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>The UPDF spec assumes that the driver will get a RGB (not 
necessarily sRGB) input and can create color output for R, G, B, C, M, Y, K, W 
planes. you may comment on the white plane.</FONT></DIV>
<DIV><FONT size=2>The spec expects device color handling for the remaining 
functionality.</FONT></DIV>
<DIV><FONT size=2>The spec expects the device to understand 8bpp per 
plane.<BR></FONT></DIV>
<DIV><FONT size=2>By limiting the spec to 8bpp, we want to make it easy for all 
host implementations, as all drivers must support all implementations. 
Additionally we think that many devices support 8bpp.</FONT></DIV>
<DIV><FONT size=2>We know there are other solutions out there. In case an IHV 
wants to develop a host implementation for different bits per pixel or would 
provide a huge number of device descriptions plus detailed information how to 
manage it, so that we can create a proper schema and drivers can properly handle 
it with short-term development time, please step up and contact us 
now.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Some MS Windows stuff, which can pop up in a similar way under 
other platforms as well:</FONT></DIV>
<DIV><FONT size=2>the dmColor setting is provided by the color-mono-enum 
attribute.</DIV></FONT>
<DIV><FONT size=2>the <STRONG>dmBitsPerPel</STRONG> setting is supposed to be 24 
for all color modes.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>The <STRONG>dmICMMethod</STRONG> setting needs a minute. Check 
if you agree with the following description, which would become valid if nobody 
complains the next days.</FONT></DIV>
<DIV><FONT size=2>We assume there is an ICC profile tag in configuration schemas 
(see previous email today).</FONT></DIV>
<DIV><FONT size=2>In this sample we do not assume the driver has its own color 
correction functionality.</FONT></DIV>
<DIV><FONT size=2>A driver may want to show an ICM control in the UI with 
possible entries of SYSTEM, NONE and/or DEVICE. This is supposed to be a driver 
feature. UI strings should be provided in the driver's locale xml 
file.</FONT></DIV>
<DIV><FONT size=2>1. There is no device halftoning nor ICC 
profiles.</FONT></DIV>
<DIV><FONT size=2>The only entry is NONE.</FONT></DIV>
<DIV><FONT size=2>2. There is&nbsp;device halftoning, but&nbsp;no ICC 
profiles.</FONT></DIV>
<DIV><FONT size=2>Entries NONE and DEVICE (default).</FONT></DIV>
<DIV><FONT size=2>3. There is no device halftoning, but ICC 
profiles.</FONT></DIV>
<DIV><FONT size=2>Entries NONE and SYSTEM (default).</FONT></DIV>
<DIV><FONT size=2>4. There&nbsp;are device halftoning and ICC 
profiles.</FONT></DIV>
<DIV><FONT size=2>I'm not sure if I'd do that. But if, my driver would treat the 
ICC profiles with a higher priority.</FONT></DIV>
<DIV><FONT size=2>Under Windows that may result in entries NONE, SYSTEM 
(default) and DEVICE. same under platforms with the same 
environment.</FONT></DIV>
<DIV><FONT size=2>If the platform does not support ICC profiles, the driver 
should use the device halftoning.</FONT></DIV>
<DIV><FONT size=2>If the platform supports ICC profiles, but no flag to 
communicate any related driver setting to the OS API, the driver should announce 
the ICC profiles, but ignore the device halftoning.</FONT></DIV>
<DIV><FONT size=2>Please comment if you have any preference for 
<STRONG>dmICMIntent</STRONG>. Otherwise we leave that to the driver and treat it 
as a driver feature.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Do we want a Predefined_ID for <STRONG>dmDitherType</STRONG>? 
this could turn out to be quite tricky, as we have three different halftoning 
elements, in which case we could concentrate on the 
RasterHalftoning.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Some said during the meeting they have to think more about the 
whole block of raster graphic, color hanlding and halftoning, which I 
understand. however this is the time to comment.</FONT></DIV>
<DIV><FONT size=2>We are quite confident that the current design (perhaps with 
some adjustments due to dmICMIntent or dmDitherType) can very well work as a 
generic description of color and graphic related device 
capabilities.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</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>