We have activated the latest color handling design after last Friday's meeting in Boston.
the group agreed to the design as it was with only few comments.
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 Plane element either. A driver should ignore it anyhow in this case.
we have added an entry (PerPixel) to the data type plane-implementation-enum.
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.
The spec expects device color handling for the remaining functionality.
The spec expects the device to understand 8bpp per plane.
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.
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.
Some MS Windows stuff, which can pop up in a similar way under other platforms as well:
the dmColor setting is provided by the color-mono-enum attribute.
the dmBitsPerPel setting is supposed to be 24 for all color modes.
The dmICMMethod setting needs a minute. Check if you agree with the following description, which would become valid if nobody complains the next days.
We assume there is an ICC profile tag in configuration schemas (see previous email today).
In this sample we do not assume the driver has its own color correction functionality.
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.
1. There is no device halftoning nor ICC profiles.
The only entry is NONE.
2. There is device halftoning, but no ICC profiles.
Entries NONE and DEVICE (default).
3. There is no device halftoning, but ICC profiles.
Entries NONE and SYSTEM (default).
4. There are device halftoning and ICC profiles.
I'm not sure if I'd do that. But if, my driver would treat the ICC profiles with a higher priority.
Under Windows that may result in entries NONE, SYSTEM (default) and DEVICE. same under platforms with the same environment.
If the platform does not support ICC profiles, the driver should use the device halftoning.
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.
Please comment if you have any preference for dmICMIntent. Otherwise we leave that to the driver and treat it as a driver feature.
Do we want a Predefined_ID for dmDitherType? this could turn out to be quite tricky, as we have three different halftoning elements, in which case we could concentrate on the RasterHalftoning.
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.
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.
Norbert Schade
69 Prescott Drive
North Chelmsford, MA 01863
978-251-1017
norbertschade@attbi.com
This archive was generated by hypermail 2b29 : Mon Apr 22 2002 - 19:21:19 EDT