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/blueroofmusichttp://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>