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

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

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

Ira McDonald blueroofmusic at gmail.com
Tue May 21 16:49:41 UTC 2013


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/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****
>
> *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 *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 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/2e3cfdfc/attachment-0001.html>


More information about the ipp mailing list