Hi,
+1 to Mike's comments.
And I like the symmetry of "media-sheets-supported" for
"finishings-col" with "job-media-sheets-supported" for
Printer.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
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
Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
On Sat, Oct 15, 2016 at 11:22 AM, Michael Sweet <msweet at apple.com> wrote:
> Smith,
>> > On Oct 14, 2016, at 5:06 PM, Kennedy, Smith (Wireless Architect) <
>smith.kennedy at hp.com> wrote:
> >>> ...
> >>> 2. Eliminate "maxsetsheets" and implement "baling-max-sheets",
> "folding-max-sheets", etc.
> >>
> >> I don't like this as much because it conjoins an abstract finishing
> process to a physical finisher subunit limit. Since printer-finisher is
> where we are exposing the finisher subunits, that is where the limit should
> be reported.
> >
> > I'm not quite sure I agree. Yes, we are describing a physical finisher
> subunit limit. But different limits may pertain to different abstract
> finishing process.
>> Perhaps - I guess the question is whether this is a practical issue that
> has affected users? For example, the booklet finishers I've used could
> fold a partial set and "stack" the folded output such that it didn't matter
> that the folding mechanism could only handle (for example) 10 sheets at a
> time. The only time it became an issue was when you wanted to staple
> (saddle stitch in the case of booklet printing) since the staple had to be
> done before the fold.
>> > Let's discuss user experience / expectations:
> >
> > Jane has a 5 page document that she would like to print and be folded.
> She chooses folding, and chooses "fold-half". The printer has expressed
> that it has a maximum number of 5 sheets for 'fold-half', 3 for
> 'fold-letter', and 2 for 'fold-accordion'. If she chooses 'fold-letter',
> what would Jane expect to happen?
> >
> > A. Warning that there are too many pages for 'fold-letter' and offer to
> do a 'fold-half'
> > B. Allow Jane to submit the Job and have the Printer present an error
> > C. Allow Jane to submit the Job and have the Printer simply not fold the
> pages
> >
> > I think B and C are less than optimal. With A, if we use
> "printer-finisher" and 'maxsetsheets' keyword, then there is only one
> 'maxsetsheets' value possible for the finisher device. Do we set that to 2
> to be on the safe side to be sure to avoid B or C? Or do we express the
> limit on the number of sheets based on the abstract finishing type, using
> the "Option 2" like above?**
>> I agree that A is the best outcome, with B or C being the fallback for
> Clients that don't consult the member attribute in
> "finishings-col-{database,ready}".
>> > We could get into some awkward weirdness where we have multiple "virtual
> finisher devices" each of which can only do one of the finishing
> operations. But that would be less than optimal.
> >
> >
> > ** (We could probably simplify #2 by adding a new "max-sheets" member to
> "finishings-col" that would only be allowed when it is in
> "finishings-col-database" and "finishings-col-ready", rather than creating
> "folding-max-sheets", etc.)
>> I like this idea better rather than separate sub-member attributes in each
> finishing process collection.
>> As for naming, how about "media-sheets-supported (rangeOfInteger(0:MAX))"
> to mirror the "job-media-sheets-supported" Printer Description attribute?
>> >
> >
> > Smith
> >
> >> On Oct 14, 2016, at 1:51 PM, Michael Sweet <msweet at apple.com> wrote:
> >>
> >>> So we have 3 alternatives:
> >>>
> >>> 1. Keep the new "printer-finisher" keyword "maxsetsheets"
> >>
> >> That would be consistent with the Finisher MIB.
> >
> >
> >>
> >>> 2. Eliminate "maxsetsheets" and implement "baling-max-sheets",
> "folding-max-sheets", etc.
> >>
> >> I don't like this as much because it conjoins an abstract finishing
> process to a physical finisher subunit limit. Since printer-finisher is
> where we are exposing the finisher subunits, that is where the limit should
> be reported.
> >>
> >>> 3. Eliminate "maxsetsheets" and implement "baling-max-thickness",
> "folding-max-thickness", etc.
> >>
> >> That way lies madness. Most printers don't implement media-thickness
> support, even LFPs that would have a genuine need for it. And what Client
> is going to pre-process the document and job ticket to determine the final
> set thickness for finishing? And what printer provides this information via
> other protocols (SNMP, etc.)?
> >>
> >>> 4. Encourage vendors to use constraints between media type and
> finishing type to limit the range of thicknesses and ignore the thickness
> issue
> >>
> >> I think if a vendor knows that certain media types can't be used with a
> finisher, then those should be exposed as constraints. But otherwise I
> think we just rely on the "best effort" principle.
> >>
> >>> Which way(s) should we go with this? We want something that Clients
> can and will implement, but we also want the limitations of the Printer to
> be clearly articulated so that the Client implementation can help the User
> make informed choices, either automatically or manually.
> >>
> >> I think the most useful information for the Client is to know the
> maximum number of sheets a finisher can handle for typical media, with
> specific constraints for media as needed. That handles the 99% use cases
> without requiring a significant amount of intelligence in the Client along
> with major changes in how Printers track and report finisher capacity.
> >>
> >
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161015/3d383c05/attachment.html>