Subject: RE: IPP>PRO - Print by reference

From: Stephen Holmstead <[email-masked]>
Date: Wed, 4 Jun 1997 11:00:26 -0600

Print by reference is REALLY tough for the printer to do.  Up until this 
point, the printer only had to do http server capabilities (which can be 
implemented fairly easily).  However, print by reference now would require 
the printer to implement http client capabilities (which is HUGE!!, not to 
mention how unstable the client features are and the fact that the printer 
most likely won't ever have a flash upgrade).  What about all of the 
embedded graphics files (gif, jpeg, pcx, tiff, etc.)?  Does the printer 
have to have code to convert all of these to printable output?  What about 
other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)?  Does the 
printer have to have code to handle all of these?  What about plug-ins and 
applets?  Does the printer have to have a Java Virtual Machine to run Java 
applets?  The client (i.e. Browser) is quite large and has too many 
features to be able to support by a printer.

I have to strongly protest print by reference as it causes the requirement 
load on the printer to skyrocket.
--
Stephen Holmstead
Hewlett Packard Internet Solutions Operation
[email-masked]

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 4 Jun 1997 11:26:22 PDT

>load on the printer to skyrocket.

Stephen,

an assumed restriction in the use of print-by-reference is that it would
initially only support the retrieval of documents in print ready formats,
such as Postscript or other PDL. Also, like most other features in IPP, a
particular printer does not have to support this functionality. However,
there is an increasing demand for this feature, (for example in print on
demand scenarios) so we certainly want to keep the option in the
specification, for people who may want to implement it. The most likely
protocol for the actual retrieval is more likely to be FTP rather than
HTTP, but we do not see a good reason to put any restrictions in the
standard for this.  Does this help you?

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: "Michael E. Gaines" <[email-masked]>
Date: Wed, 04 Jun 1997 15:01:26 -0400

>However, print by reference now would require
>the printer to implement http client capabilities (which is HUGE!!,
>not to mention how unstable the client features are and the fact that
>the printer most likely won't ever have a flash upgrade).

Why not? If the flash upgrade is kept to a DIFF-type of upgrade, it
could work just fine.

>What about all of the embedded graphics files (gif, jpeg, pcx, tiff,
>etc.)?  Does the printer have to have code to convert all of these to 
>printable output?

Absolutely! Having these interpreters in the printer is required if the
printer is expected to print HTML pages. Some of the lesser known image
types can be avoided. I don't think there are too many documents out
there with Atari ST Degas pictures on them :).

>What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, 
>etc.)?  Does the printer have to have code to handle all of these?  

Not unless you can watch movies on a piece of paper :)
Seriously, there are some data types that shouldn't HAVE to be printed.
That's the whole point of a PDF file (which should be handled).

>What about plug-ins and applets?  Does the printer have to have a Java 
>Virtual Machine to run Java applets?

I'm still waiting for something to show that Java is nothing more than
hype at this point anyway.

>I have to strongly protest print by reference as it causes the 
>requirement load on the printer to skyrocket.

I can't disagree with you there, but it's an unfortunate requirement at
this point. What SHOULD happen is a common data model...but we all know
what kind of a pipe dream that is. If IPP takes off, then I believe
responsible web masters will place data on pages in a format that will
be suited for IPP devices and all will be well.

Mike Gaines
Internet Imaging Manager
Pipeline Assoc. Inc.
[email-masked]

---

From: [email-masked]
Date: Thu, 5 Jun 97 14:52:08 -0600

Carl,
     
     On 6/5/97 you wrote:
     >>an assumed restriction in the use of print-by-reference is that it 
     would initially only support the retrieval of documents in print ready 
     formats, such as Postscript or other PDL.
     
     What kind of driver requirements will this place on the source?  The 
     document provider will need to provide documents in every "print 
     ready" format that may exist at that time- PostScript, PCL, PCL-XL, 
     PDF, to name a few, and it will need to do this for every printer 
     because as we know, practially every printer has a different print 
     region, orientation, color space, etc. for which the specific PDL file 
     will need to be formatted.  This is basically why every printer has 
     it's own driver or PPD file in the first place.  If the owner of the 
     document is concerned about the fidelity of the document with which 
     they are trying to communicate information, this will place the burden 
     on them for determining what and how many print drivers they will need 
     to use.  
     
     This is a somewhat exaggerated example but either way, it seems the 
     requirement load for print by reference is going to have to increase 
     (and potentially skyrocket) somewhere, either on the printer, or on 
     the document provider.
     
     Theresa Rhoades
     Hewlett-Packard, Internet Solutions Operation 
     [email-masked]

______________________________ Reply Separator _________________________________
Subject: RE: IPP>PRO - Print by reference
Author:  Non-HP-cmanros ([email-masked]) at HP-Boise,mimegw7
Date:    6/4/97 12:26 PM

Stephen,

Carl-Uno

Carl-Uno Manros

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 05 Jun 1997 17:16:35 -0400

>>>>> "TR" == Theresa Rhoades <[email-masked]> writes:

CM> an assumed restriction in the use of print-by-reference is that it
CM> would initially only support the retrieval of documents in print ready
CM> formats, such as Postscript or other PDL.

TR> What kind of driver requirements will this place on the source?  The
TR> document provider will need to provide documents in every "print
TR> ready" format that may exist at that time- PostScript, PCL, PCL-XL,
TR> PDF, to name a few, and it will need to do this for every printer
TR> because as we know, practially every printer has a different print
TR> region, orientation, color space, etc. for which the specific PDL file
TR> will need to be formatted.

  Hmmm... are we beginning to understand why IETF insists that specs
  be available as flat text?

  [Sorry, I couldn't resist...]

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

---

From: Randy Turner <[email-masked]>
Date: Thu, 05 Jun 1997 14:38:29 -0700

If someone makes a document publically available, then the author or
person responsible
for publishing this document as 'public' will make sure that it is in a
form that is generalized
in PDL (postscript, pcl, etc.) to print on the widest possible variety
of devices.

This is no different than what alot of document houses and computer
systems vendors are
doing by delivering alot of their document in postscript format on
CDROM. While its true
someone could generate a document using a printer driver with very odd
characteristics, but
if the author was truly interested in making this a public document, I
doubt whether this would
be the avenue that the author would choose for publication.

Randy