SM> RE: [printing-cap] Capabilities API: Device Object [How about a M edia Object]

SM> RE: [printing-cap] Capabilities API: Device Object [How about a M edia Object]

SM> RE: [printing-cap] Capabilities API: Device Object [How about a M edia Object]

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Sep 23 22:50:02 EDT 2002


Michael wrote:

" > ...
 > So I think that Pete Zannucci is suggesting that we just invent some
 > simple IPP extension attributes to get us the imaging width for the
 > various media sizes.  Couldn't that extension be a member attribute
 > of the "media-col" attribute somehow?

We already have the media dimensions, but we need the printable
margins, which *could* be enumerated as part of the media-col
attribute but which also often depend on the resolution, color
mode, input source, etc., and not just the media size."

For UPnPv1 in the Enhanced Printing Service we added a GetMargins operation.
It has input of the media specification and the output was four integers
which were the width of each margin that couldn't be imaged in: Top, Right,
Bottom, and Left.  This is the beginning of the Media object with an
operation to Get-Media-Attributes.  In UPnPv1, only the four margins could
be queried.

Handling the interactions of margin size with resolution, color mode, input
source, etc. could be taken care of if the Get-Media-Attributes allowed the
job context attributes to be supplied as well.  

How about adding a member attribute to the "media-col":

"media-margin-sizes" (1setOf integer)

Four integers specifying the size of the top, right, bottom, and left
margins measured in hundredths of a millimeter from the nearest edge of the
medium.  From these numbers the size of the printable area can be
determined.  A zero value indicates that the printable area coincides with
the edge of the physical medium.  All four values MUST be present.

I think it is simpler to make it a sequence of 4 integers.  Alternatively,
we could make the member attribute a collection with 4 member attributes.
But UPnP did it with four integers.

For the PWG Semantic Model, we'd have MediaMarginSize.

Then we'd need to add the Media object along with query operations, like
Get-Media-Attributes and Get-Media which return requested member attributes
of the Media objects supported.  Get-Media-Attributes takes a media name and
job context attributes.  Get-Media would also take job context attributes.

Comments?

Tom





-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Monday, September 23, 2002 11:33
To: printing-cap at freestandards.org
Subject: Re: [printing-cap] Capabilities API: Device Object


Hastings, Tom N wrote:
 > ...
 > However, the real question is: Does the Printer MIB provide the
 > device imaging parameters that Drivers need in order to produce a PDL
 > page that Pete Zannucci is after?

IIRC, the Printer MIB is missing the needed imageable area
information (margins).

 > ...
 > So I think that Pete Zannucci is suggesting that we just invent some
 > simple IPP extension attributes to get us the imaging width for the
 > various media sizes.  Couldn't that extension be a member attribute
 > of the "media-col" attribute somehow?

We already have the media dimensions, but we need the printable
margins, which *could* be enumerated as part of the media-col
attribute but which also often depend on the resolution, color
mode, input source, etc., and not just the media size.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com


_______________________________________________
printing-cap mailing list
printing-cap at freestandards.org
http://freestandards.org/mailman/listinfo/printing-cap



More information about the Sm mailing list