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 at 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 at 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 at 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 at sharplabs.com Mon Sep 22 16:12:02 1997
> > > > > From: "Turner, Randy" <rturner at sharplabs.com>
> > > > > To: "'ipp at pwg.org'" <ipp at 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 at 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 at Eng.Sun.COM [SMTP:Robert.Herriot at Eng.Sun.COM]
> > > > > > Sent: Monday, September 22, 1997 3:27 PM
> > > > > > To: ipp at pwg.org; rturner at 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 at 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>