Subject: Re: IPP> Document attributes

From: [email-masked] (Robert Herriot)
Date: Mon, 29 Sep 1997 13:27:13 -0700

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 [email-masked] 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 [email-masked] 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:   [email-masked]          --
> > > --  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 [email-masked] Mon Sep 22 16:12:02 1997
> > > > > From: "Turner, Randy" <[email-masked]>
> > > > > To: "[email-masked]'" <[email-masked]>
> > > > > 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: [email-masked]
> > > > > 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:       [email-masked] [SMTP:[email-masked]]
> > > > > > Sent:       Monday, September 22, 1997 3:27 PM
> > > > > > To: [email-masked]; [email-masked]
> > > > > > 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 [email-masked] 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>

---

From: Jay Martin <[email-masked]>
Date: Mon, 29 Sep 1997 16:57:27 -0400

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