Re: Minutes posted from today's meeting

Michael Sweet via ipp <[email protected]> Thu, 5 Aug 2021 18:59:35 -0400
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Smith,

I'm not sure it matches the semantics, but if we were to do something like this (to indicate the maximum number of sheets that can be stapled, folded, punched, etc.) I would not use a member attribute name with "pages", maybe "max-sheets" or something like that.

The Printer Finisher MIB (RFC 3806) has an element named "maximumSheets", and we already expose that in the printer-finisher attribute. If this is important we can also expose it as a member attribute (but there will be a lot of duplication per finisher...)

> On Aug 5, 2021, at 6:39 PM, Kennedy, Smith (Wireless & IPP Standards) <[email protected]> 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 <[email protected]> wrote:
>> 
>> Hi Mike,
>> 
>>> On Aug 3, 2021, at 8:20 AM, Michael Sweet <[email protected]> wrote:
>>> 
>>>  Smith,
>>> 
>>>> On Aug 2, 2021, at 5:53 PM, Kennedy, Smith (Wireless & IPP Standards) <[email protected]> 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
>> [email protected]
>> https://www.pwg.org/mailman/listinfo/ipp
> 

________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 874 B)