Subject: [IPP] Finishings 2.0 and "trimming-offset" / "trimming-offset-supported"?

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 2 Apr 2015 03:54:08 +0000

Greetings,

In Finishings 2.0, I’ve been puzzling over the “trimming-offset” / “trimming-offset-supported” attribute definitions and their respective type declarations.  I see this on page 38:

   5.2.13.1 trimming-offset (1setOf integer(0:MAX))

but on page 49 in the IANA registrations and on the IANA ipp-registrations page, I find:

  trimming-offset (integer(0:MAX))    [PWG5100.1]

I am assuming from the attribute definition that (integer (0:MAX) ) is the correct one?  If a Printer supported a set of values like “0,3-5, 8-15, 22”,  for “trimming-offset-supported”, then the definition of “trimming-offset-supported” on page 47 seems reasonable:

   6.26 trimming-offset-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX)))

Was this attribute definition’s type declaration done in this way to allow just such a range of values to be expressed?  Or is there something wrong with this type declaration as well?

Are there any others that don’t match?  (I didn’t check myself beyond these attributes.)

Smith

/**
    Smith Kennedy
    Hewlett-Packard Co.
*/

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 06 Apr 2015 13:04:57 -0400

Smith,

I'll need to dig a bit to see which was intended, however the -supported syntax is designed to allow the printer to return both ranges and discrete values that might be supported.

The 1setOf syntax for trimming-offset would allow for multiple cuts from a single finishings-col value - useful for cutting business cards, for example - however I'm not sure how that would work for a printer.  Most of the cutters I've used on printers have been cross-cut (perpendicular to the feed direction, so top/bottom reference edge), with some providing a pair of cutters for the left/right (as the media exited the marking engine)...

> On Apr 1, 2015, at 11:54 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Mon, 6 Apr 2015 13:37:33 -0400

Hi,

FWIW - the TrimmingOffset mapping in JDFMAP is definitely single-valued
(in JDF) - I really dislike adding multi-valued XxxOffset elements in IPP
Finishings 2.0 - the meaning would be very implementation-specific.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Apr 6, 2015 at 1:04 PM, Michael Sweet <[email-masked]> wrote:

> Smith,
>
> I'll need to dig a bit to see which was intended, however the -supported
> syntax is designed to allow the printer to return both ranges and discrete
> values that might be supported.
>
> The 1setOf syntax for trimming-offset would allow for multiple cuts from a
> single finishings-col value - useful for cutting business cards, for
> example - however I'm not sure how that would work for a printer.  Most of
> the cutters I've used on printers have been cross-cut (perpendicular to the
> feed direction, so top/bottom reference edge), with some providing a pair
> of cutters for the left/right (as the media exited the marking engine)...
>
>
> > In Finishings 2.0, I’ve been puzzling over the “trimming-offset” /
> “trimming-offset-supported” attribute definitions and their respective type
> declarations.  I see this on page 38:
> >
> > I am assuming from the attribute definition that (integer (0:MAX) ) is
> the correct one?  If a Printer supported a set of values like “0,3-5, 8-15,
> 22”,  for “trimming-offset-supported”, then the definition of
> “trimming-offset-supported” on page 47 seems reasonable:
> >
> > Was this attribute definition’s type declaration done in this way to
> allow just such a range of values to be expressed?  Or is there something
> wrong with this type declaration as well?
> >