[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