April 16, 1996
Andrew Mutz <firstname.lastname@example.org>
Ho John Lee <email@example.com>
Hewlett-Packard Laboratories, Palo Alto, California
Printing from documents on the web today (April 1996) is primitive. Web documents tend to be formatted for a color CRT output device. Browsers often only support a Postscript printing model with minimal and unpredictable formatting. The document author has little control over the final output appearance on paper, and would have to 're-author' the document for paper output if desired, perhaps using Acrobat or by sending an entire Postscript file.
Some of these shortcomings can be addressed within the browser, within HTML, or both. Style sheets, as proposed by W3C for HTML, are a good place for font information and other specific document formatting references. Browsers can and should be able to support output for printers other than Postscript, either via plug-ins, native support, or OS support (or some combination.)
This leaves one major shortcoming -- the lack of a output negotiation feature in HTML. A document on a server can and should be delivered differently if the target device is a high-resolution black-and-white printer versus a low-resolution color monitor. For example, if a multi-resolution image is inside an HTML document, a high-resolution image might be delivered for paper, while the low-resolution image is delivered for CRT display.
Two new HTTP header fields are proposed to describe the output
which extend the mechanisms described in the current HTTP content negotiation proposal.
There is a point of confusion with regard to existing "media
types" in HTTP content negotiation.
Text and image are distinct "media types", as are audio
and movie. Because the "media" tag is already taken,
we propose the "Display tag", which indicates the intended
output device. The possible values of Display would be much more
strictly limited, as only fundamental major types exist.
Maintaining the usability of caches is important for performance
across the web. This implies limiting the number of minor types
(such as paper size and resolution) too. If the number of possible
HTML documents served to represent a single resource grows, the
cache hit rate drops. The general topic of caching HTML documents
in the presence of content negotiation is a current topic of discussion
on the HTTP-WG mailing list, and will not be addressed here.
The syntax of the display tag is similar to the existing media
type tag. Major values of Display are: Video, Paper, Audio, and
VR. The browser (more generally the client) includes the Display
tag in the request to the server. (For more information on the
syntax and registry of HTTP language tags, see RFC 1766.)
More than one type of display tag may be sent (since a client
may have access to video and audio resources at the same time,
for example.) Subtags as for the Display tag are also to be specified
and limited. Subtags for visual display size (printable area),
display quality, and for color/monochrome are assigned. Not all
subtags need be specified.
Display size options are USLetter, USLegal, A4, Tabloid, and B3.
Tabloid is 11x17. A4 and B3 are European standards for letter
and tabloid. It is anticipated that USLetter and A4 will be far
and away the most commonly used, since most desktop printers support
one of these sizes. Since printable area is the critical factor,
0.25" margins on sides and top, and 0.75" on bottom
should be assumed as unwritable for consistency across printers.
The actual desired margins would be specified in the style sheet
at the HTML level, and not at the HTTP level.
Display quality options are: draft, and best. These guide the
choice of image resources served, but do NOT imply the served
resources are at a particular resolution. The object is to guide
the server to provide more information when serving image. It
is anticipated that "quality" could change over time.
At this time "draft" could optimally serve a 300 dpi
binary engine, while "best" would imply a 600 dpi binary
(or better) or a 300 dpi multilevel engine. The choice of 'quality'
also implies a willingness to accept more data and the increased
time for that data.
Display color options are: color, and monochrome.
Using content negotiation in HTTP, a session might
look something like this:
Client requesting document includes with request:
Accept-Display: paper/*; q=0.5, paper/color/USLetter/best;
This means, "I request a high quality document for a color
printer for 10"x8" printable area, but I will accept
anything I can print on paper.
Server might reply in the head of the response:
This means, "I am serving you a document designed for a color
printer, but I make no promise about the quality or the printable
Increasing bandwidth and server compute power may make server-side page rendering a common feature in many environments, requiring a method for browser clients to request a fully rendered page ready to print from the server.
This could have significant advantages for the user: no more drivers
to download, and fast printing with limited local compute power.
Compute-expensive rendering could become the norm, by sharing
a large server among many "sleek" clients, for instance,
a "network computer" with limited local resources. To
do this, a set of content types and attributes might be added
to the existing MIME-types. For example:
This might be appealing on a valuable intranet application where
powerful servers are can be shared on a fast local network, but
might require too much bandwidth for consumer applications on
the open internet.