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.50.4611.1300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<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> </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 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 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> </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. 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. -> 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> </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> </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> </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> </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> </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> </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> </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></BODY></HTML>