Chris,
> On Jun 20, 2018, at 12:55 PM, Rizzo, Christopher <Christopher.Rizzo at xerox.com> wrote:
>> Michael,
>> It is taking me a while to digest this (as happens to me with most IPP specs d:o) ).
>> 1. finishings-col-supported specifies the which finishings-col member attributes (keywords) are supported from Table 1 of section 5.2 of PWG 5100.1 - IPP Finishings 2.1
Correct.
> 2. finishing-template (name(MAX)) is a member of finishings-col. The fact that it is of type name(MAX) implies that any vendor proprietary name can be added to finishing-template-supported. But by convention it would probably be a good idea for the vendor to use names associated with existing finishings enum values.
It's actually "type2 keyword | name(MAX)", as of IPP Finishings 2.0, and we have registered all of the keyword values corresponding to the "finishings" enum values.
> 3. finishing-template-supported is a standalone Printer Description attribute that specifies all possible values that can be used for finishing-template member attribute in finishings-col.
Correct.
> 4. If a printer supports both wire and crimp staples concurrently, then finishing-template-supported can (for example) include 'staple-top-left,staple-bottom-left,...,staple-dual-left,staple-dual-top,...,crimp-top-left,crimp-bottom-left,...,crimp-dual-left,crimp-dual-top,...' etc. (Your example seemed to imply wire and crimp stapling as mutually exclusive).
They aren't, and you could absolutely provide separate templates for crimp and wire stapling (although that might not provide the best user experience).
As I mentioned previously, wire vs crimp is often a site preference, so we expect that the defaults (as applied by the finishings enums or base finishing-template keywords) will reflect that site preference. But the flexibility offered by the finishing-template keyword allows you do more.
> 5. Given this reported Printer Description, there is no need for the printer to include exact finishing intent in the optional finishings-col-database, other than to provide a semantic understanding for a user (or possibly even a client) as to what (for example) crimp-top-left actually does? Of course, any new finishing that a vendor adds could be so unique such that there is no real way to specify a semantic meaning for a finishing value.
There isn't a hard requirement, no. But we strongly recommend it so that the Client UI can provide a reasonable preview of the results (vs. just providing localized strings in a pull-down with potentially hundreds of templates...)
>> Thanks,
> Chris
>> From: "msweet at apple.com" <msweet at apple.com> on behalf of "msweet at apple.com" <msweet at apple.com>
> Date: Monday, June 18, 2018 at 1:06 PM
> To: Christopher Rizzo <Christopher.Rizzo at xerox.com>
> Cc: PWG Workgroup <ipp at pwg.org>
> Subject: Re: [IPP] IPP Finishings 2.1 February 17, 2017 question
>> Chris,
>> The "finishings" enum values are a simplified way of specifying the finishing intent and map to the "finishing-template" member attribute (a keyword) in the "finishings-col" collection. Unless overridden in a "finishings-col" value, the enum or keyword value represents the same intent, for example to put a single staple at the top left corner of the page you could specify either of the following Job Template attributes:
>> finishings=20
> finishings-col={finishing-template='staple-top-left'}
>> A Printer reports the exact finishing intent for each of the standard enum keywords in the "finishings-col-database" and "finishings-col-ready" attributes, for example:
>> finishings-col-database=...,{finishing-template='staple-top-left' stitching={stitching-method='crimp' ...}},...
>> Conceptually a Printer's web page could offer UI for the "default stapling method", and that default would be reflected in the Printer's "finishings-col-database" and "finishings-col-ready" attributes in the "stitching-method" member attribute. Similarly, a Printer might support Set-Printer-Attributes or other means of updating the finishing defaults.
>> The advantage of this approach is that Client software does not need to support or even know about new enum values to take advantage of "eco stapling" (aka crimping). And with the formal definition of "finishing-template" as a superset of the existing "finishings" enum keyword names, the Client can easily support new finishing processes (including vendor/site-defined composite processes) by getting the list of supported "finishing-template" values and their localized strings.
>> Moreover, the choice to use physical staples or crimping is often a site decision/policy, so reusing the existing staple enums and keywords ensures that existing Client software complies with that policy without changes.
>> Had we added additional enums (24 by my count), we would be waiting for Clients to adopt them (years).
>>>>>> On Jun 18, 2018, at 3:38 PM, Rizzo, Christopher <Christopher.Rizzo at xerox.com <mailto:Christopher.Rizzo at xerox.com>> wrote:
>>>> This question is in regard to section 5.2.13.3 stitching-method member attribute of stitching collection on finishings-col collection:
>>>> There is a 'crimp' keyword value for stitching-method. But there is no corresponding enum values for 'crimp' on the finishings attribute (i.e -
>>>> crimp-top-left
>> crimp-bottom-left
>> crimp-top-right
>> crimp-bottom-right
>> crimp-dual-left
>> crimp-dual-top
>> crimp-dual-right
>> crimp-dual-bottom
>> crimp-triple-left
>> etc...
>>>> Is this because expectation is that to support 'crimp' it can only be supported via finishings-col (and therefore finishings-col must be supported in order to support 'crimp') (i.e. - at some point finishings attribute will be deprecated so at this point nothing new is being added to it)?
>>>> Or was the addition of enums for crimp on the finishings attribute an oversight?
>>>> Thanks,
>> Chris
>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org <mailto:ipp at pwg.org>
>>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
_________________________________________________________
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20180620/1ef9ea71/attachment.html>