Just closing the loop on this thread and today's teleconference. I don't think we need "max-sheets" since "media-sheets-supported" already fills this need.
Smith
> On Aug 5, 2021, at 9:48 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>> Hi Mike,
>> I don't know why this didn't occur to me earlier, but I think this issue is already covered by the "media-sheets-supported" additional member of "finishings-col" defined in section 7.9. 😊 I think we are good with what we have already - no additional attributes needed.
>> Smith
>>>>> On Aug 5, 2021, at 4:39 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>>>> Hi again,
>>>> I guess one other way this might be conveyed is to add a "job-max-pages-per-set-supported" member to "finishings-col" and add that as an additional member of "finishings-col-ready: / "finishings-col-database" collections, so that it can be used by all finishings operations?
>> finishings-col-database=
>>>> {
>>>> finishing-template='fold-accordion'
>>>> media-size-name="iso_a4_210x297mm"
>>>> job-max-pages-per-set-supported=1
>>>> folding=
>>>> {
>>>> folding-direction='inward'
>>>> folding-location=7425
>>>> folding-reference-edge='top'
>>>> },
>>>> {
>>>> folding-direction='inward'
>>>> folding-location=22275
>>>> folding-reference-edge='top'
>>>> },
>>>> {
>>>> folding-direction='outward'
>>>> folding-location=14850
>>>> folding-reference-edge='top'
>>>> }
>>>> }
>>>>>> Smith
>>>>>>>>> On Aug 3, 2021, at 10:26 AM, Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
>>>>>> Hi Mike,
>>>>>>> On Aug 3, 2021, at 8:20 AM, Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>> wrote:
>>>>>>>> Smith,
>>>>>>>>> On Aug 2, 2021, at 5:53 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>>>>>>>>>> Hi Mike,
>>>>>>>>>> You have in these minutes this statement about section 5.2.6 "folding (1setOf collection)":
>>>>>>>>>> ⁃ Add something to talk about folding applying to the set, except as noted (e.g. poster fold is normally done to individual sheets)
>>>>>>>>>> I'm not sure what to do about this because the . Are you saying that the size of the Set or how many Media Sheets should be folded may depend on the type of the fold? So if the Client sends a 4 page document and supplies "finishing" = 'fold-poster', the Printer might fold every Media Sheet, but if the Client instead supplies "finishing" = 'fold-half' the Printer may instead fold all 4 pages together?
>>>>>>>>>> Maybe we need to add a "folding-when"?
>>>>>>>>>>>> So the issue here is that some kinds of folds can be applied per-sheet or per-set, but some can *only* be applied per set (fold-double-gate, fold-parallel), others can *only* be applied per sheet (fold-half-z, fold-poster), and the rest can be applied either way depending on the amount of folding done and output bin/tray.
>>>>>>>> Look at figure 1's fold images to get a visual sense of this - folds along both axis need to be applied per-sheet, while overlapping folds need to be applied per-set. So this is definitely implementation/process-specific, but we want folding to only express the intent.
>>>>>> As you know well, we have two needs: describing a folding operation to a Client, and describing a custom folding operation to the Printer.
>>>>>> In both cases, a “folding-when” would be useful. The Client needs to know the range of options it could use (1 or more than 1 option). And if there is the possibility of a choice, the Client needs a member to convey that choice to the Printer.
>>>>>> Expressing this via the current finishings-col is going to be a little bit awkward because folding is expressed as an ordered sequence of folding collections. Maybe a”folding-when” as a member of the first “folding” collection? Or as a separate peer to “folding”?
>>>>>> _______________________________________________
>>> 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>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210902/6a887546/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20210902/6a887546/attachment.sig>