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 5.50.4611.1300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>We are discussing in the UPDF group about chances not to
increase the global list of paper sizes artificially.</FONT></DIV>
<DIV><FONT size=2>Ideas are:</FONT></DIV>
<DIV><FONT size=2>1. not to list 'Small' sizes under a separate ID, as they
have the same physical size as the normal size. A different printable area is
anyhow realized by settings values for margins. Additionally it does not seem to
be 100% clear what the exact decrease of the printable area would be in every
case. If the values for the size are not written in stone (like an RFC and/or a
header file together with the ID), it is worthless for a driver
developer.</FONT></DIV>
<DIV><FONT size=2>2. not to list 'Extra' sizes under a separate ID, as it is not
100% clear what the exact physical size would be in every case. If the values
for the size are not written in stone (like an RFC and/or a header file together
with the ID), it is worthless for a driver developer.</FONT></DIV>
<DIV><FONT size=2>3. not to list 'Transverse' sizes under a separate ID, as a
any GDI would not know and not be interested - as far as I know - in the feeding
method. In UPDF we may treat that as an additional attribute perhaps for later
use in previews. But when it comes to announcing settings to the OS or creating
a print file, this would not require a change in functionality.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>We are discussing that right now in our group.</FONT></DIV>
<DIV><FONT size=2>This is my personal opinion, until we reach further
agreement.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Regards</FONT></DIV>
<DIV><FONT size=2>Norbert Schade</FONT></DIV></BODY></HTML>