I am talking about the standard spooler shipped with a System V UNIX
system. It assumes that all document data is of the same format and any
conversion (filtering) it performs on one file it does on all files.
You are talking, I think, about a customized interface script rather
than the standard interface script. I agree that a customized
interface script could use a different filter for each file. But that
doesn't change the fact that customers using the standard System V UNIX
spooler and standard interface script cannot do this.
Bob Herriot
> From jkm@underscore.com Mon Sep 29 13:56:59 1997
>
> Umm...beg your pardon? I'm not sure exactly what you mean when you
> say "You were just lucky to have a smart printer" below.
>
> Fact is, the printer is actually pretty dumb, since it is our
> interface/filter software that does all the work. And the examples
> I cited work for almost any kind of network printer when used with
> our software.
>
> The point is, I don't think it is at all accurate to say that "no
> Unix system does this and that" within the context of this topic.
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>
>
> Robert Herriot wrote:
> >
> > Jay,
> >
> > You were just lucky to have a smart printer in the examples you cite below.
> >
> > In both the System V and the BSD Unix examples you cite below, all of the
> > document data passed through the system as plain text data until it reached
> > the printer which auto-sensed its type: PostScript, PCL or text and then
> > printed it correctly.
> >
> > If your printer didn't accept text, for example, the System V spooler would have
> > run the text-to-PostScript filter on all three files, giving you a print out of
> > the PostScript and PCL files in their raw form.
> >
> > Bob Herriot
> >
> > > From jkm@underscore.com Fri Sep 26 19:08:57 1997
> > >
> > > (Sorry for not responding sooner, as I have been out of the office.)
> > >
> > > Unix System V spoolers allow you to configure a queue with a
> > > specified set of "content types"...where the list can be more
> > > than one type.
> > >
> > > On Solaris 2.5.1 I just printed a set of documents to a single
> > > "printer" in which each document had a different data format
> > > (text, postscript, pcl).
> > >
> > > On BSD Unix, there is no concept of "content type", so the LPD
> > > agent (ie, lpr) constructs the "cf" (control file) such that
> > > the documents are specified as having a "normal" (my term) data
> > > type.
> > >
> > > Why would someone want to do this? For *exactly* the same reasons
> > > as we wanted multiple documents for IPP: printing a number of
> > > documents from a document repository, where each document may be
> > > of a different type (postscript, pdf, text, etc).
> > >
> > > ...jay
> > >
> > >
> > > Robert Herriot wrote:
> > > >
> > > > > From jkm@underscore.com Mon Sep 22 17:03:31 1997
> > > > >
> > > > > Bob,
> > > > >
> > > > > Sorry, but there are *lots* of Unix systems that can accept jobs
> > > > > having documents with multiple data formats.
> > > >
> > > > What Unix systems offer this feature?
> > > >
> > > > In my previous email, I stated that the Solaris spooler does not. It
> > > > is based on AT&T System V and many other Unix spoolers are based on the
> > > > same code. It is possible that other vendors have removed the single
> > > > document-format restriction, though considering the required changes,
> > > > I doubt it.
> > > >
> > > > The BSD LPD spooler and LPD protocols support multiple formats per job,
> > > > so these systems accept jobs with multiple data formats. But the BSD lpr
> > > > command does not give access to this feature. It is possible that some
> > > > vendors have enhanced the lpr command, but I am not aware of such
> > > > changes.
> > > >
> > > > Bob Herriot
> > > > >
> > > > >
> > > > > ...jay
> > > > >
> > > > > ----------------------------------------------------------------------
> > > > > -- JK Martin | Email: jkm@underscore.com --
> > > > > -- Underscore, Inc. | Voice: (603) 889-7000 --
> > > > > -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> > > > > -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> > > > > ----------------------------------------------------------------------
> > > > >
> > > > >
> > > > > Robert Herriot wrote:
> > > > > >
> > > > > > This is a version 1.0 limitation. But I doubt it will cause much
> > > > > > hardship because currently:
> > > > > >
> > > > > > 1) Windows users can only send one document per job.
> > > > > > 2) Solaris users can send multiple documents per job, but they
> > > > > > must all have the same format, despite the generality of the LPD
> > > > > > protocol. I think that most if not all other Unix systems have
> > > > > > the same limitation.
> > > > > >
> > > > > > So that doesn't leave very many people with the capability that we
> > > > > > are removing from version 1.0.
> > > > > >
> > > > > > Bob Herriot
> > > > > >
> > > > > > > From rturner@sharplabs.com Mon Sep 22 16:12:02 1997
> > > > > > > From: "Turner, Randy" <rturner@sharplabs.com>
> > > > > > > To: "'ipp@pwg.org'" <ipp@pwg.org>
> > > > > > > Subject: RE: IPP> Document attributes
> > > > > > > Date: Mon, 22 Sep 1997 15:34:30 -0700
> > > > > > > X-Priority: 3
> > > > > > > MIME-Version: 1.0
> > > > > > > X-Mailer: Internet Mail Service (5.0.1458.49)
> > > > > > > Sender: ipp-owner@pwg.org
> > > > > > > X-Lines: 90
> > > > > > >
> > > > > > >
> > > > > > > Does this seem kind of limiting, to restrict all documents in a
> > > > > > > particular job to have the same document format? It doesn't
> > > > > > > seem hard to imagine a 2-document job wherein one file
> > > > > > > is PCL and another Postscript. If the document attribute
> > > > > > > says "application/vnd.pcl" then the printer would probably
> > > > > > > trash the 2nd Postscript job.
> > > > > > >
> > > > > > > Just checking to see if we haven't got a hole in this
> > > > > > > somewhere....
> > > > > > >
> > > > > > > Randy
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Robert.Herriot@Eng.Sun.COM [SMTP:Robert.Herriot@Eng.Sun.COM]
> > > > > > > > Sent: Monday, September 22, 1997 3:27 PM
> > > > > > > > To: ipp@pwg.org; rturner@sharplabs.com
> > > > > > > > Subject: Re: IPP> Document attributes
> > > > > > > >
> > > > > > > > I think that we agreed not to decide on the format of attributes that
> > > > > > > > have a separate value for each document by eliminating document-name,
> > > > > > > > and stating that all documents in a job have the same document-format,
> > > > > > > > meaning that document-format is a job-level attribute.
> > > > > > > >
> > > > > > > > Document-URI is still a problem unless either we eliminate Send-URI
> > > > > > > > (my
> > > > > > > > preference) or eliminate document-URI as a job attribute until a later
> > > > > > > > version.
> > > > > > > >
> > > > > > > > Although we previously decided not design a format for per-document
> > > > > > > > attributes until a later version, I pointed out that an attribute
> > > > > > > > 'foo'
> > > > > > > > could take on a "dictionary" value whose values might be "default=XYZ"
> > > > > > > > and "3=ABC" to indicate that the job level 'foo' attribute has a value
> > > > > > > > of "XYZ" and document-3 has a value of "ABC". Such a solution is not
> > > > > > > > precluded by the current design.
> > > > > > > >
> > > > > > > > Bob Herriot
> > > > > > > >
> > > > > > > > > From rturner@sharplabs.com Sun Sep 21 09:49:57 1997
> > > > > > > > >
> > > > > > > > > Ok, so we have these actual document attributes that we could
> > > > > > > > admittedly move
> > > > > > > > > into "job document attributes" just to save us the work this time of
> > > > > > > > actually doing
> > > > > > > > > the work to support document attributes. This might be
> > > > > > > > > problematic for future implementations that actually *DO* the
> > > > > > > > > document attribute model correctly, having to be backward-compatible
> > > > > > > > > with our "hacked" version of document attributes of IPP 1.0.
> > > > > > > > >
> > > > > > > > > I thought maybe we could allow a placeholder in the model/protocol
> > > > > > > > for
> > > > > > > > > V 1.0 for document attributes, so that we could easily integrate
> > > > > > > > this in
> > > > > > > > > the future with very little work.
> > > > > > > > >
> > > > > > > > > Concerning the "job-document-attribute" proposal...
> > > > > > > > > I'm assuming that the send-document operation allows these
> > > > > > > > "job-document"
> > > > > > > > > attributes to be included (I can't remember the send-document
> > > > > > > > specifics from the
> > > > > > > > > model document...).
> > > > > > > > >
> > > > > > > > > Randy
> > > > > > > > >
> > > > > > > > > Ira Mcdonald x10962 wrote:
> > > > > > > > >
> > > > > > > > > > Hi Randy,
> > > > > > > > > >
> > > > > > > > > > I think we agreed that JOBs could have descriptive attributes
> > > > > > > > > > (either single- or multi-valued??) about the associated
> > > > > > > > > > document(s), which apply unless (in a future version of IPP)
> > > > > > > > > > they are overridden at the (future) DOCUMENT object level.
> > > > > > > > > >
> > > > > > > > > > I speculate that the following JOB level attributes are
> > > > > > > > > > necessary or desirable in IPP 1.0:
> > > > > > > > > >
> > > > > > > > > > [job]document-name
> > > > > > > > > > [job]document-URI (to support Send-URI)
> > > > > > > > > > [job]document-format
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > - Ira McDonald (outside consultant at Xerox)
> > > > > > > > > > High North In
> > > > > > > > > > 906-494-2434
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>