Ok, Ok. Don't shoot me.
I should have been more specific. I considered it common knowledge that a
predefined parameter ID is only used additionally to numeric values for
width, height and some other necessary parameters. I never questioned that
and the current version of UPDF has that incorporated.
I just want to set clear how far a UPDF format would take predefined
parameters into consideration.
Hoping to interpret Michael's and other comments right there is another
option.
3. Do not specify any predefined parameter for any paper size.
Leave that to the OS specific driver/client relying that it knows about
width and height of predefined OS specific print media sizes (to stay with
the sample) and assign them by interpreting the printer's values for width
and height. So the driver would discover the proper predefined parameter for
such an OS. It needs some rounding functionality. Probably this would be
done once during installation or so.
This puts some more burden to the driver developer of such an OS, but it is
a clear statement.
This could work well for this specific sample print media size.
We'll have to see whether we'll find clear technical parameters for any
feature.
I put this option for vote.
Regards
Norbert Schade
-----Original Message-----
From: Michael Sweet <mike@easysw.com>
To: Norbert Schade <norbertschade@oaktech.com>
Cc: UPD group <upd@pwg.org>; IPP Group <ipp@pwg.org>
Date: Friday, November 10, 2000 12:31 PM
Subject: Re: IPP> registered parameters
>Norbert Schade wrote:
>> ...
>> 2a. In the last UPDF conference we were talking about using
>> registered IPP values as a common reference.
>> ...
>> As far as I know the list includes the following features:
>> Print media size
>> Page orientation
>> Print media source
>> Duplex
>> Print media type
>>
>> There some more when it comes to Print quality or Font handling like
>> download formats.
>> ...
>
>First, please *do not* rely solely on a keyword-based media size
>attribute. Such things are nice for the standard sizes but
>completely ignore variable sizes. You should allow keywords *and*
>measurements, which allows the driver/printing system to do any
>necessary mapping to the "native" value(s).
>
>Along with variable size support you'll need to communicate the
>minimum and maximum media sizes supported.
>
>FWIW, if you haven't done so already, please look at Adobe's
>PostScript Printer Description specification. It has its
>limitations (no "range of values" type of options, only supports
>PostScript directly, can only provide a single UI language in each
>file, etc.), but it *does* address most of the issues that you are
>looking at now for describing printer options.
>
>For example, PPD files provide named sizes plus the page dimensions
>and imageable area for the printer. Variable size support includes
>orientation, min/max width/height, etc. This all allows you to map
>Windows/MacOS/UNIX/IPP media sizes to PPD sizes and visa-versa, and
>to support variable sizes as needed.
>
>FWIW, CUPS (http://www.cups.org) uses PPD files and maps the IPP
>attributes to PPDs and visa-versa. We've added additional CUPS-
>specific attributes to PPDs for non-PS printers to support extra
>printer drivers, etc. It works quite well.
>
>--
>______________________________________________________________________
>Michael Sweet, Easy Software Products mike@easysw.com
>Printing Software for UNIX http://www.easysw.com
>
This archive was generated by hypermail 2b29 : Fri Nov 10 2000 - 13:36:56 EST