Re: Minutes from today's meeting
Michael Sweet via ipp <[email protected]>
| Newsgroups | gmane.ietf.ipp |
|---|---|
| Message-ID | <[email protected]> |
Smith, > On Jul 30, 2021, at 11:59 PM, Kennedy, Smith (Wireless & IPP Standards) <[email protected]> wrote: > > Hi Mike, > > (CC'ing the IPP Workgroup reflector back in...) > >> On Jul 28, 2021, at 3:01 PM, Michael Sweet <[email protected]> wrote: >> >> Smith, >> >> > On Jul 28, 2021, at 4:53 PM, Kennedy, Smith (Wireless & IPP Standards) <[email protected]> wrote: >> > >> > Hi Mike, >> > >> > Starting work on the next draft of Finishings 3.0. In the minutes it says: >> > >> > ⁃ Section 5.1.2: >> > ⁃ Add reference to 5100.2, should use "output-bin" to specify a 'stacker' value to get this behavior >> > >> > What does this mean? Does this pertain to the 'jog-offset' keyword? >> >> Yes. The 'jog-offset' value should be deprecated, with a note to say that the 'stacker' values for "output-bin" should be used instead. > > I remember us deciding on that. Here's what I have so far: > > • ‘jog-offset’ (14): (DEPRECATED) Shift each Set from the previous one by a small amount which is device dependent. This value has no effect on the “job-sheet”. This value SHOULD NOT have an effect if each Set of the Job consists of one sheet. The "output-bin" Job Template attribute should be used instead, specifying one of the 'stacker-NN' keywords (e.g. 'stacker-1'). > > But I wonder about the lack of a keyword like 'jog-offset-1' that more specifically identifies an output tray that is capable of jogging? I've not looked at that in a long time. FWIW, PWG 5100.2-2001 says: ‘stacker-N’: The output-bin that is best identified as the stacker with values ‘stacker-1’, ‘stacker- 2’, .... A stacker is typically used to collate sheets within a single document (not to be confused with collated copies in which document copies are collated within a job - see the description of the ‘separate-documents-collated-copies’ value of the “multiple-document- handling” attribute in [RFC2911] section 4.2.4). The correspondence between the ‘stacker- N’ keyword and the actual stacker in the device is implementation-dependent, as is the number of stackers. If this group of values is supported, at least the ‘stacker-1’ value MUST be supported, unless the system administrator has assigned names. For client implementations that require distinct keywords for each possible value, say, for localization purposes, it is recommended for interoperability with other vendor’s Printer implementations that ‘stacker-1’ to ‘stacker-10’ keywords be represented. So basically this is one big "implementation-dependent" can-o-worms that doesn't use the words "jog" or "offset" but really means that, because how else are you going to "collate sheets" in a single output bin? :/ The "printer-output=tray" attribute (PWG 5100.13) includes the optional RFC 3805 prtOutputOffsetStacking (offsetstacking) element which will tell you whether a particular output tray provides a jog offset for each Set. That might be something to update in NODRIVER to make it conditionally required or recommended (at least) for trays that support offset stacking - the possible values are 'other', 'on', 'off', or 'notPresent'. ________________________ Michael Sweet _______________________________________________ ipp mailing list [email protected] https://www.pwg.org/mailman/listinfo/ipp
signature.asc
(application/pgp-signature, 874 B)
-----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmEFUyAACgkQvmfHXsgf MkQPGxAApVJYpHovpqkan0Zg4VZRZcFgc6j+oqzvItFIILmHYk7a88HBu7zz9EXj lZRQqRZ8q8c6gvIbZJyLTfa5RIk44atmp5wnyQOKKtrO0rlJhHDYRB+2PjtDf49P 9+Vr70eJCtuFMAFW1BTCTPT9NPOXyXQcEFranaGceB0CBZz7eaSyyhuxmsXJRuX+ nwxwYZfM9KTKuA9belayD7fr4iwAcPt/p0T59LnMqTVyuKHhr+sycqZLqNxKE3e3 ZiG8MxEUFFmeca5/Z1FBsy84z5MWDROJe7+R6/fcMxkncMcyINPQFsnqtnH0fyJl qZvCwG/olo2VaAK0M3AUXDX88PUE58oauejGJFpzBNt+CKX5WZ3xc+XQSN8J3Zlx HCZjDvdAw2G6F/3JGVY/J3P8IPCJuqg9x4XnoygEKpL1KvVJ9gPWxOyZ9j06KCjP 11GJsnN1OtKnnLwekt3vuNoV7iyz2ugFJieguAfzvAQuAv79G46u6KwLN9r99BZp u6Aik8bMkV8KCZmyzBdMebSJRXCSL8L3fbL/zPV/FM4NVO36mmrO9WbOVUwINLtf 5kN2GpXVuxfmyHmS3aS/Hu7deTlV34L0UXxThEqmRfjuuqTRJN1Ge8ZYau/1ww8P 5n8fGBNBD9Gr/sUXME5kaSkHor7rcpk/iK9r4wNi2bO7G98Ayn4= =AUj9 -----END PGP SIGNATURE-----