Optimizing Printing Output For the Web

Version 1.0
April 16, 1996
Andrew Mutz <mutz@hpl.hp.com>
Ho John Lee <hjl@hpl.hp.com>
Hewlett-Packard Laboratories, Palo Alto, California

Introduction - New Content Negotiation Tags

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 environment: Accept-Display and Content-Display, 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 Display Tag

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 the Display Tag

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:

Content-Display: paper/color;

This means, "I am serving you a document designed for a color printer, but I make no promise about the quality or the printable area."

Opportunities for Content Negotiation for Output Devices

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:

Accept: printerlang/PCL3/HP_Deskjet600;

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.