1996, Gutenberg, And the Revenge of Movable Type

B.C. Krishna
FutureTense, Inc.
33 Nagog Park
Acton, MA 01720
bc@futuretense.com

The Issues

Ever since the advent of desktop publishing systems in the early 1980s, it seems that every document written about new publishing technologies and processes has made a reference to Johann Gutenberg, and his invention of movable type. And so must this.

Cross Media Publishing

In the same way that Gutenberg's invention enabled the widespread creation, production and distribution of printed documents some 400 years ago, the World Wide Web has enabled the creation, production and distribution of electronic documents. In addition, the Web has triggered the creation of a new class of electronic document that is designed to be read on screen.

And while it is most often the case that documents are indeed read this way, two points must be noted: i) the electronic document is often "repurposed" by its publisher from its original, print-oriented design, and ii) the electronic document is often repurposed by its reader to a new, print-oriented design. We argue that this evolution of the electronic document and its transtion across multiple media types leads to a new set of issues in the creation of high-quality printed documents.

The Font Problem

Typography and layout (and in particluar, variations in typography and layout) have long been devices used by graphic designers to convey an additional sense of meaning, or enhance the semantics of discourse. On the Web today, discourse is widespread and dynamic, but variations in typography and layout are almost completely absent. The Web gives new meaning to the term "movable type": fonts used by the designer in the creation of an electronic publication must be dynamically downloaded on demand in a seamless manner.

Dynamic font downloading leads to several issues: i) intellectual property and licensing, ii) font encoding and distribution in a platform-independent manner, iii) font-hinting to enhance onscreen reading, and iv) font-encoding to enable high-quality printing (no bitmaps!). We argue that solving the font problem is fundamentally important to enable the creation of high-quality printed documents.

The Pitch

At FutureTense, Inc., we have been developing a Web publishing tool called FutureTense Texture. Texture has two parts: a Win32 (Mac to follow) authoring tool and a Java-based viewer.

The Texture authoring tool has an interface that feels very much like high-end desktop-publishing tools like QuarkXPressTM and PageMakerTM and enables graphic designers to express themselves more creatively than is possible with the current crop of HTML editing tools.

In designing Texture, we had a number of goals in mind:

The documents that are created with Texture must be viewable within the main window of a Web browser (like plug-ins, and unlike helper-apps)

Documents must be viewable on all the most important browsers (Navigator, Mosaic, Explorer)

Documents must be viewable on all platforms (Windows, Macintosh, UNIX)

The authoring tool must feel familiar to graphic designers currently using tools like QuarkXPress and PageMaker

Texture should solve the font problem

Texture should enable the selective printing of document content.

The documents that are created using the tool are designed specifically for online reading. To this end, we felt that there were four aspects of a document that needed to be designed:

Specification of content (all content is specified as a set URLs)
Presentation of that content (font, leading, justification for text; tiling, scaling for images)
Interactive behavior (actions triggered when a reader interacts with a content element)
Time-based behavior (how does an element change over time)

Texture is a result of the above design goals. While the existence of Java is transparent to both author and reader, Java was necessary for us to be able to meet the goals described above.