attached mail follows:
Tom,
I have added the following:
5.2.5 The size-name "max" shall be reserved to indicate an upper
size limit of either a device or application. Also, the size-name
"min" shall be reserved to indicate a lower size limit. Example:
For a device that can process forms as small as 2 x 3 inches to
18 x 36 inches:
na-custom-max.18000-36000 and na-custom-min.2000-3000
This is part of the custom size section (5.2). My original concern
was how this was to be presented. This paragraph keeps within my
guidelines as more applicable to media and not a device.
I am quite sensitive to the issue of expansion of the scope of this
project. Keep in mind that this started out as a simple compilation
of all known media sizes. We have since added color, type, finish,
and now there is a proposal for an all-in-one format. There also
have been rejected proposals for media feed direction, printing
orientation, and others that I have already forgotten.
Not that what has been added is bad, we just have to be somewhat
selective as to what is included. On the one hand, I am hearing
that the UPnP project needs this completed before the meeting
this month and then I see all the additions everyone wants. When
sonething is added, it may add a nice feature, but it also pushes
out the completion date.
Ron
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, April 03, 2001 5:05 PM
To: Michael Sweet; Bergman, Ron
Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
(E-mail)
Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4
down- loaded
I agree with Michael that we should add the maximum and minimum size name
pattern for custom media. I don't share Ron's concern that adding the name
pattern for custom minimum and maximum size will lead to anything further
being needed in the Media Standard (if it did, then I might change my mind).
I also believe that we have to add the min and max custom size if we want
the UPnP WG to reference our standard from the UPnP BasicPrint Template for
syntax and names for use in their MediaSize variables. Their current
Template, which we hope to replace for Media Size and Media Type already
have the custom min and max syntax. Satisfying the UPnP WG BasicPrint
Template was one of the reasons to get this PWG Media standard done in the
first place.
I wrote on 3/28 as the syntax for adding custom max and minimum size names:
3. Request to represent minimum and maximum size for use with the custom
mechanism. Interestingly, UPnP Print template has a way to represent the
minimum and maximum sizes that a Printer supports using the custom syntax.
Translating the UPnP syntax to our ABNF would become:
custom-media-size-max-self-describing-name =
[prefix] "custom-max" "." short-dim "-" long-dim
custom-media-size-min-self-describing-name =
[prefix] "custom-min" "." short-dim "-" long-dim
A Printer that supports a minimum custom size of, say, 3 inches by 5 inches,
and a maximum of, say, 8.5 inches by 14, would have the following two
values:
na-custom-max.8500-1400
na-custom-min.300-500
Any disagreements?
I also believe that this meets Michael's needs for custom sizes, whether for
the 'roll' Media Type or any of the other Media Type values.
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Thursday, March 29, 2001 12:09
To: Bergman, Ron
Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail);
'RonBergman@aol.com'; Norbert Schade (E-mail)
Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4
down-loaded
"Bergman, Ron" wrote:
> ...
> I disagee with your proposal for adding printer size restrictions
> to the document. So far this specification has only involved
> attributes related to media. Now you are proposing that we add
> an attribute that is related to printers. This belongs in the
> appropriate UPnP or IPP or other document that defines how to
> describe a printer. If we add this then it will be necessary
> ...
I'm not sure I agree with this (or maybe I just not understanding
your objection right); the purpose of this standard/spec is to
define the names used for media sizes, types, finishes, etc. so
that other protocols can then use those names uniformly.
From an implementation standpoint, it may be desireable to have
media size names that are reserved for representing 1) whether
custom media sizes are supported, and 2) what the size limits are
for the device being queried. This allows all protocols to use
a common method for conveying the custom media size information,
while the exact values used in the custom size names are determined
by the device and not the protocols or this spec.
IPP contains no explicit support for custom media sizes; CUPS
works around this limitation by supporting a "custom" media size
keyword and relies on the to know that they can request a custom
media size using the name "custom.WWWxLLL", where "WWW" and "LLL"
are the width and length of the media in points (works well for
a PS-based printing system... :) This only works for CUPS, and
I have no idea what Microsoft does, for example, with their
media support under Windows 2000...
So, I guess what I'm saying is this:
1. Describe "custom-min" and "custom-max" media size names
and the format they use. Specify that these names will
only be present for devices that support custom sizes, and
that both must appear if they are used at all.
2. Explicitly state that the values used in the custom-min/max
names are defined by the device and not the spec.
3. Explicitly state that the units for media sizes in the
size names are set by the media spec and not by the
protocol spec. Units outside the size name can obviously
be anything the protocol wants...
#1 will make sure that any client can determine if a device supports
custom sizes, no matter what protocol is being used.
#2 will remove any requirement for additional info in the media spec
on how to manage custom sizes.
#3 will ensure that the dimensions in size names are consistent no
matter what protocol is being used.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Tue Apr 03 2001 - 20:33:07 EDT