This paper will raise more questions than it will provide suggestions or solutions. We are facing the necessity of providing high-quality printing of (initially) scanned page images, and (eventually) other forms such as SGML and PDF.
Established in August 1995, JSTOR is an independent not-for-profit organization created with the assistance of The Andrew W. Mellon Foundation to help the scholarly community take advantage of advances in information technology. In pursuing this mission, JSTOR has adopted a system-wide perspective, taking into account the sometimes conflicting needs of scholars, libraries and publishers. With an initial focus on core scholarly journals, the primary objectives of JSTOR are:
The current focus of JSTOR is on "digitizing the back files". We have digitized the complete run of several journals, from Volume 1, Number 1, up to a "moving wall" (5 years for most of the journals). The digital form includes high-resolution (600DPI) black-and-white scans of the pages, an electronic table of contents for each issue, and searchable OCR text of each issue.
The on-line interface consists of a browser and a set of search forms. Once the user has selected an article, the scanned pages are reduced to 75-100DPI gray-scale GIF images for on-screen viewing. The user may also print the article at the full 600DPI resolution. Our initial printing strategy requires a "helper application", which downloads the scanned pages from the server, converts them to PostScript, and sends them to a selected printer.
We are currently investigating other printing methods, including CUPID, downloading PostScript files, and downloading PDF files.
The basic requirement for printing from JSTOR is that the user be able to get the highest-quality representation that we can provide. A second requirement is to be able to print an entire article with "one click." Neither of these are satisfied by the "Print" command in the web browser. The on-screen representation is at reduced resolution from the original, and includes only a single page at a time.
The page images are currently stored as G4 FAX-compressed TIFF images; a format that is not directly supported by stock web browsers, nor by printers. Thus, some translation is necessary. The TIFF format is relatively well compressed, an important factor in minimizing download time (it still runs an average of 120Kb per page). Compression methods exist that can reduce the page size by another factor of 10 or more (e.g., Cartesian Products) but are even more non-standard.
Our current "print helper" application supports only PostScript printers (preferably PostScript level 2). With the current limited test community, this is marginally acceptable. As the user community grows, it will become increasingly unacceptable, and further application development will be required. An advantage of direct PS level 2 translation is that the body of the page image can be passed through uninterpreted. This advantage is lost when using a generic printer driver interface (thus, printing will take longer). To reduce or eliminate the need for a helper application, we may decide to provide directly printable downloadable representations such as PostScript or (HP)PCL. We will then be in the unenviable position of having to generate any number of different printer languages.To summarize, our printing requirements are:
As we move into "current file" deployment, the printing situation will only get more complex, because we will have several source representations. It seems certain that we will begin deploying SGML-based documents in the near future. Most of the issues identified above will apply to printing these documents, as well, although a minimal solution is to translate the SGML to HTML for both display and printing. However, crucial structural and formatting information can be lost in this translation.