[IPP] RFC: Proposed errata for PWG 5100.3 (Production Printing)

[IPP] RFC: Proposed errata for PWG 5100.3 (Production Printing)

Paul Tykodi ptykodi at tykodi.com
Tue May 21 16:56:10 UTC 2013


Hi Ira,

 

What I was thinking about in mentioning the other organizations was to
review the elements we want to map (stapling, folding, punching, trimming)
to see what values the specifications from these organizations support for
these limited items.

 

Best Regards,

 

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  ptykodi at tykodi.com
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

From: Ira McDonald [mailto:blueroofmusic at gmail.com] 
Sent: Tuesday, May 21, 2013 12:50 PM
To: Paul Tykodi
Cc: Michael Sweet; ipp at pwg.org
Subject: Re: [IPP] RFC: Proposed errata for PWG 5100.3 (Production Printing)

 

Hi Paul,

Looking at PODI et al would open endless possibilities.

I agree with Mike that defining the low-hanging fruit for finishing that 
specifically map to the most commonly used JDF and MSPS finishing

should be our limited and practical scope.

BTW - the Open Printing JTAPI spec specifically chose a small subset

of finishing types to standardize in the JTAPI abstract Job model - these
are already harmonized with JDF.

Cheers,

- Ira

 




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

 

On Tue, May 21, 2013 at 12:25 PM, Paul Tykodi <ptykodi at tykodi.com> wrote:

Hi Mike,

 

For this particular specification, I think we should consult information
from the UP³I and potentially PODi organizations as well.

 

Best Regards,

 

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  ptykodi at tykodi.com
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael
Sweet
Sent: Tuesday, May 21, 2013 10:45 AM
To: ipp at pwg.org
Subject: [IPP] RFC: Proposed errata for PWG 5100.3 (Production Printing)

 

All,

 

As discussed in last week's session, there is no easy migration from the
finishings attribute (1setOf type2 enum) to the finishings-col attribute
(1setOf collection).

 

The primary issue is that the finishing-template member attribute is defined
as a name value and does not support well-known keyword values.  I propose
that we amend the definition of the finishing-template member attribute and
finishing-template-supported Printer attribute to include type2 keywords,
e.g.:

 

    "finishings-col (1setOf collection)"

        "finishing-template (name(MAX) | type2 keyword)"  <--- NEW

        "stitching (collection)"

            "stitching-locations (1setOf integer(0:MAX))"

            "stitching-offset (integer(0:MAX))"

            "stitching-reference-edge (type2 keyword)"

 

    "finishing-template-supported (1setOf (name(MAX) | type2 keyword))"
<--- NEW

    "finishings-col-supported (1setOf type2 keyword)"

    "stitching-locations-supported (1setOf (integer(0:MAX) |
rangeOfInteger(0:MAX)))"

    "stitching-offset-supported (1setOf (integer(0:MAX) |
rangeOfInteger(0:MAX)))"

    "stitching-reference-edge-supported (1setOf type2 keyword)"

 

The keyword values would correspond to the finishings enum names (staple,
punch, bale, etc.).

 

Longer term we should also probably extend the finishings-col Job Template
attribute to include fold, punch, and trim member attributes, which would
make use of the same kinds of values as as the current "stitching" member
attribute (which IIRC handles bind, edge stitch, and staple, although that
too could be made explicit), for example:

 

    "finishings-col (1setOf collection)"

        "fold (1setOf collection)" (list of folds)

            "fold-direction (type2 keyword)" (in/out or up/down)

            "fold-location (integer(0:MAX))"

            "fold-reference-edge (type2 keyword)"

        "punch (collection)"

            "punch-locations (1setOf integer(0:MAX))"

            "punch-offset (integer(0:MAX))"

            "punch-reference-edge (type2 keyword)"

        "trim (1setOf collection)" (list of cuts)

            "trim-location (1setOf integer(0:MAX))"

            "trim-reference-edge (type2 keyword)"

 

    "fold-direction-supported (1setOf type2 keyword)"

    "fold-location-supported (1setOf (integer(0:MAX) |
rangeOfInteger(0:MAX)))"

    "fold-reference-edge-supported (1setOf type2 keyword)"

 

    "punch-locations-supported (1setOf (integer(0:MAX) |
rangeOfInteger(0:MAX)))"

    "punch-offset-supported (1setOf (integer(0:MAX) |
rangeOfInteger(0:MAX)))"

    "punch-reference-edge-supported (1setOf type2 keyword)"

 

    "trim-location-supported (1setOf (integer(0:MAX) |
rangeOfInteger(0:MAX)))"

    "trim-reference-edge-supported (1setOf type2 keyword)"

 

That said, I think extending finishings-col needs to happen in a separate
(small) spec, and we should look to other specs (e.g. JDF and MSPS) to make
sure we aren't defining something completely out in left field.

 

Thoughts?

 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


_______________________________________________
ipp mailing list
ipp at pwg.org
https://www.pwg.org/mailman/listinfo/ipp

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130521/419f3a8d/attachment-0001.html>


More information about the ipp mailing list