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 5.50.4611.1300" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV>I second Michael Sweet's request for a "finish" (or whatever the name will be) attribute.</DIV> <DIV>In UPDF we have to have some solution for that anyhow. See below my view from a driver's point of view. </DIV> Why is a driver/client interested in getting information about media types from the device?  <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p> <OL style="MARGIN-TOP: 0in" type=1> <LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">Simply showing it in the client’s user interface for further selection. This would not require any different functionality of the client. It would mainly be marketing information that the device is able to feed a number of print media.</LI> <LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">Temperature related issues. In this case it is useful to know, which is the current media type. This requires a different print file to be sent. In the simpliest case this requires just one additional job command.</LI> <LI class=MsoNormal style="mso-list: l0 level1 lfo1; tab-stops: list .5in">Constraints The print file (not only the job settings, but the binary part) has to be seriously changed depending on the current media type. There are two areas:</LI></OL> 3.1.  Mechanical issues This can affect driver functionality at page start/end. Means sending different or additional command sequences at page start/end or even staying away from printing in certain areas e.g. at the top of the page (media type specific minimum or at least recommended margins). A special case of this issue can be to stay away from certain areas, as the media is prepared a certain way like preprinted or prepunched. It could also have tray related constraints. Certain media types may not be fed from some trays, as they need a straight paper path. Other constraints like transparency -> no duplex is another issue. 3.2.   Color conversion including grey scale. When the color conversion is done in the device, e.g. you have an sRGB device, it is enough for the client to send a simple job setting like in issue 2. If the device is not capable of doing that the client may want to do the conversion itself, which means serious changes in the binary section of the print file. Sometimes device objects (fonts, rectangles and other graphical objects, etc.) are handled by the device, while raster graphics are handled by the driver. This typically is surface or finish related. Sometimes this attribute is called coating.  <o:p></o:p> Unfortunately it is reality that all these media type attributes are thrown into one list, more or less big and often very model and PDL specific. My private golden rule so far is, that I become suspicious, when a media seems to be two media types the same time, e.g. glossy and prepunched. To serve reality my proposal for the UPDF is that we keep one list of media types in our description. We will use the keywords of the global media standard (Ron’s spec), but add at least one more attribute to each media type, called Coating. This coating seems to be the attribute a Windows 2000 devmode is interested in – more than the rather physical attributes of Ron’s spec, which have more to do with the overall shape (outside the size) or stiffiness of the media. So even if two media would have the same spec keyword, we’d have a chance to differenciate between them. I wonder whether other attributes like Pre-handled (prepunched, preprinted, etc.) or opacity would be of further help. Glad we have color now. I do not see the need for other attributes. An indication whether there are enough attributes with enough variations in Ron’s spec might be: Do we expect that most of the media types we know today playing a role in the game of printing are covered? Norbert Schade</BODY></HTML>