att1-0001.htm

<!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.00.2919.6307" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=972130523-27042001>Norbert,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=972130523-27042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001>So 
your proposal is to always use one set of units, namely 1000ths of a mm (i.e., a 
micrometer); never use inches for any media sizes.&nbsp; It certainly is 
simple.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=972130523-27042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001>1000th 
of a mm is precise enough so that the English sizes can be represented in 
1000ths of a mm without round off error (which would create differences in 
names, if some rounded and others truncated).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=972130523-27042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001>We 
used the same strategy of using only a single unit system in the IPP Production 
Printing Attributes - Set1 extension, instead of having both metric and 
English.&nbsp; The only minor difference was that we used&nbsp;100th of a mm, 
instead of 1000th of a mm for use in the "media-size" member attribute of the 
"media-col" attribute.&nbsp; We felt that was precise enough.&nbsp; See section 
3.13.8 in:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001><SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf, 
.doc, .rtf</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=972130523-27042001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001>The 
1000th of a mm is&nbsp;one of the two units used in the Printer MIB (the other 
being <SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">10000th 
of an inch).</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001><SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001><SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">We 
did agree at the meeting that the client&nbsp;shouldn't simply display the Media 
Size name to the user if it doesn't have it in its localization data base 
(thought there will always be simple minded clients that will).&nbsp;&nbsp;The 
client should do some parsing and possible converting of units to the one that 
the user prefers.&nbsp; So there is no real advantage to the client to have the 
units be in inches for English sizes and metric for metric sizes (except for the 
really simple clients that never convert units).</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001><SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001><SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">What 
do others think of just always using micrometers for the size dimensions for our 
Media Size Self Describing Names?</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001><SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=972130523-27042001><SPAN 
style="FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Tom</SPAN></SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Norbert Schade 
  [mailto:norbertschade@oaktech.com]<BR><B>Sent:</B> Thursday, April 26, 2001 
  13:50<BR><B>To:</B> IPP Group<BR><B>Subject:</B> IPP&gt; global media; comment 
  on yesterday's proposal<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>I have my problems with the new 
  proposal.</FONT></DIV>
  <DIV><FONT face=Arial size=2>I am going to rephrase my previous statements 
  commenting that proposal.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Splitting the media size name into three 
  components (unit, name, dimensions) is a very new idea.</FONT></DIV>
  <DIV><FONT face=Arial size=2>My main problem with this proposal is the first 
  component.</FONT></DIV>
  <DIV><FONT face=Arial size=2>In Ron's current version of the spec we have two 
  units: inch/1000 and mm/10. We have implemented that version to learn 
  about&nbsp;problems.</FONT></DIV>
  <DIV><FONT face=Arial size=2>With the new proposal there is the danger to have 
  an even bigger number of units.</FONT></DIV>
  <DIV><FONT face=Arial size=2>Supporting more than one unit is a serious 
  problem for any driver. Ask any driver developer. It's not about what unit I 
  want to show in the UI. It's about necessary conversions&nbsp;when dealing 
  with applications. Please study Mark's feedback from 4/20. I repeat it in easy 
  words (I hope).</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Scenario excerpt</FONT></DIV>
  <DIV><FONT face=Arial size=2>1. Workstation 1 with driver 1</FONT></DIV>
  <DIV><FONT face=Arial size=2>Driver 1 is supporting a media size 
  'Letter.2159-2794' (the developer of the driver has chosen the metric way). 
  You could do the sample with any other size.</FONT></DIV>
  <DIV><FONT face=Arial size=2>2.&nbsp;User 1 sitting at workstation 1 writes 
  one page of text with application xyz and saves the document.</FONT></DIV>
  <DIV><FONT face=Arial size=2>this means that the size information 
  'Letter.2159-2794' is saved in the document file as well in many, many 
  applications.</FONT></DIV>
  <DIV><FONT face=Arial size=2>3. User 1 sends his document to user 
  2.</FONT></DIV>
  <DIV><FONT face=Arial size=2>4. User 2 sitting at workstation 2 with driver 2 
  (different from driver 1) opens the document. This second the driver 2 is 
  already involved.</FONT></DIV>
  <DIV><FONT face=Arial size=2>5. Imagine driver 2 is not supporting 
  'Letter.2159-2794', but 'na-Letter.8500-1100' instead, which in fact is the 
  same size with a different name.</FONT></DIV>
  <DIV><FONT face=Arial size=2>Now it's the question what is driver 2 
  doing.</FONT></DIV>
  <DIV><FONT face=Arial size=2>It could start some investigation to match or 
  emulate the required size. -&gt; bad performance.</FONT></DIV>
  <DIV><FONT face=Arial size=2>The same situation will happen again when 
  printing. It will happen very often, repeatedly.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>So we already have a problem with two units. If 
  we now open a gate to be able to define even more units, it will be aweful 
  code and a terrible performance. Every driver developer should be able to 
  prove that.</FONT></DIV>
  <DIV><FONT face=Arial size=2>However everything would be fine, if there'd be 
  one and one only unit.</FONT></DIV>
  <DIV><FONT face=Arial size=2>Make it small enough that any rounding for a UI 
  string or whatever is needed, can be done properly. Our proposal within UPDF 
  was mm/1000, which is certainly small enough (and used in the industry 
  anyhow).</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I treated strings like 'jis' or 'iso' just as 
  parts of the name to make it more apparent. 'na' was the only exception so 
  far.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>If all names are unique (I think they are in 
  Ron's current concept), I don't have a problem splitting the name and the 
  dimensions into two components. In that case we may even work with the name 
  only and handle the dimensions with an include file.</FONT></DIV>
  <DIV><FONT face=Arial size=2>I thought the idea of combining the name and the 
  dimensions is ok, as we need it for custom size anyhow.</FONT></DIV>
  <DIV><FONT face=Arial size=2>BTW: I am happy to have proper keywords, but my 
  drivers certainly will never, never, never show them in the UI. Be also sure 
  that in UPDF we are providing the chance to assign a proper human readable UI 
  string to it.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>So from a driver's point of view the easiest case 
  is to work with 1 unit (mm/1000), remove the prefix 'na-' and convert all the 
  dimensions.</FONT></DIV>
  <DIV><FONT face=Arial size=2>This ensures a good performance, consistent 
  routines and readability.</FONT></DIV>
  <DIV><FONT face=Arial size=2>Whatever the internal unit of a driver is, it 
  most probably has all converting routines available to work with 1 unit, but 
  not all necessary functions to match between different units.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I would be very surprised if Mark does not feel 
  very, very similarly, although I have been told differently today. 
  Unfortunately I couldn't get hold of him on his trip today.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I call this proposal '1unit mm/1000, unchanged 
  naming', where unchanged naming means no separate components, but converted 
  dimensions into that 1 unit. I do not insist on unchanged naming, but I 
  haven't seen the big advantage of it so far.</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Regards<BR>Norbert Schade<BR>Principle Software 
  Engineer<BR>Host Software Group<BR>Oak Technology, Inc.<BR>10 Presidential 
  Way<BR>Woburn, MA 01801<BR>USA<BR>Phone: 1-781-638-7614<BR>Fax: 
  1-781-638-7555<BR>email: <A 
  href="mailto:norbertschade@oaktech.com">norbertschade@oaktech.com</A></FONT></DIV></BLOCKQUOTE></BODY></HTML>