September 8, 1993 -- IN RECENT MEMORY, few software applications have evoked as much pre-market interest and speculation as Adobe Acrobat. Adobe Systems founder John Warnock sparked people's imagination two years ago by demonstrating on stage at Seybold San Francisco an application that could display the same image of a page on PC, Mac and Unix workstations, regardless of the application used to create the page. Page turners had been seen before, but never ones that were independent of all applications you could run on a variety of machines. The audience was enthralled; the media speculated as to how it would change business communication; and the market began to wait with baited breath for the "technology demonstration" to turn into a real product.
Since then, we have followed the progress of the technology, from its inception as Carousel, through the announcement of joint developments this spring, to its launch as Acrobat in June. We've described the basic underlying technology; we've noted some potential uses and limitations; and we've reported on its competition.
But until now, we haven't had a chance actually to try the product ourselves. We received beta copies this spring and shrink-wrapped copies of Acrobat Exchange and Acrobat Distiller shortly after the official launch on June 15 in New York. The product is now available from Adobe, and is in the process of making its way through the distribution chain to your local retailer.
Because it is based on PostScript -- which has become such a widely used standard -- there is great potential for Acrobat and its Portable Document Format (PDF) to establish themselves as market leaders in the emerging software application segment we'll call electronic document delivery. Indeed, the conventional wisdom is that Adobe is the odds-on favorite to win dominant market share among shrink-wrapped applications of this type. Adobe is one of the few firms that has been very successful in selling system-level publishing applications that operate across platforms (Adobe ATM); it has a proven track record in developing application-independent document-description languages (PostScript); and it also has strong name recognition in applications (Photoshop, Illustrator).
There are three products in the Acrobat suite. We covered their basic purposes this past spring in the Special Report from Seybold Seminars, but it is worth reviewing their purposes before assessing how well they measure up to our expectations.
Exchange. The core product, Acrobat Exchange, is intended for the general-purpose business market as a tool for distributing documents directly from Mac or Windows applications. With it, you can both create and view PDF documents. You can annotate, add hyperlinks or bookmarks to the PDF files and copy text to the clipboard. In addition to viewing files created on your desktop, Exchange will view PostScript files that were created outside of Mac or Windows and run through the Distiller.
Exchange carries a list price of $195 for a single copy. Adobe then offers more than a dozen packages ranging from five copies to 100. The 5-pack costs $780; the 25-pack costs $3,750; the 100-pack costs $14,625. In packages with more than 10 copies, Adobe includes both Mac and Windows binaries and you decide how to split up the licenses.
Reader. The basic viewing software, intended for commercial publishers and organizations that want to distribute key documents widely but do not want to pay for Exchange, lacks the ability to create and modify PDF files. Its view, search and copy/paste functions are the same as Exchange, and it is also available for both Mac and Windows.
The Reader is sold only in volumes starting at 50 copies for $2,500 ($50 a copy); a 100-pack costs $3,750; and the price drops to $35 per copy at 500. Adobe is trying to push all of its copies through distribution channels, so site licenses should be arranged with resellers, rather than directly with Adobe. For individuals, a single license carries a list price of $50.
In August, Adobe distributed Acrobat Exchange to all Compuserve system operators and began offering the Reader through Compuserve for $24.95. Later, Adobe began offering the Acrobat Reader free on ZiffNet, but the download time for several megabytes was so horrendous there was little savings to be gained. Information providers (professional publishers) are handled differently. Adobe sells directly to those who publish in large quantities. For this audience, the Reader prices range between $1 and $5, depending on the volume.
The Acrobat Reader is not free, but it is not as light-weight as those of Common Ground or Replica, either. On the PC, the Reader itself takes two floppies. Unlike Common Ground and Replica, which can embed the viewer with the document so that you can send it to someone who doesn't already have a viewer, Adobe distributes its Reader as a separate application.
Distiller. An application that converts PostScript files into PDF, the Acrobat Distiller is a companion to both Exchange and the Reader. It provides a way to create PDF files from systems that output PostScript but do not run on the Mac or Windows. It also is a way to make PDF files from files converted to PostScript from other output languages (e.g., AFP) and a way to create electronic viewfiles of archived PostScript files you may have been lucky enough to keep.
For documents that contain graphics, the Distiller does a much better job than Exchange of compression, it automatically creates thumbnails, and the network version runs unattended, so it may be used even for jobs that originate on the Mac or Windows. Unlike Exchange, the Distiller contains a full PostScript interpreter, which means it will render Encapsulated PostScript files that lack TIFF headers and therefore do not display on the screen.
The Distiller is available in personal and network versions, priced at $695 and $2,495 respectively. We highly recommend the network version for all but the smallest organizations. It includes two licenses, which may be for two Windows PCs, two Macintoshes or one of each, and just those two copies should be sufficient for organizations of several hundred, even 1,000, employees. In contrast with the personal version, which requires someone to distill each document, the network version runs in batch mode, distilling files that hit its directory without operator intervention. The network version will run on a 386 with 8 MB of RAM or a 68020 Mac with at least 6 MB of RAM, but it will be slow. We recommend taking Adobe's advice and running all Acrobat products on fast machines.
Support options. Adobe offers several levels of support to its registered users: on-going free support from Compuserve and Adobe's bulletin board; phone support paid in advance or by the minute or hour; or a corporate support program.
Developer assistance. Adobe actively works with other developers in linking its applications to other software. It has a group of about a dozen engineers devoted to working with third-party developers, and a good portion of their time right now is devoted to Acrobat. Among the third-party vendors that have already stated their intention to develop Acrobat support are Lotus, Quark and Ventura. Those committed to developing Acrobat-related products and services are AlphaGraphics (service bureaus), Knight-Ridder (Acrobat offerings within PressLink), Lotus (Acrobat support within Lotus Notes), Dataware (CD-ROM development tools), Elixir (AFP to PostScript), and R.R. Donnelley (online magazine pages, potentially other applications).
PDF: the Underlying Technology
Adobe's Portable Document Format is based on PostScript technology, but it is not at all the same as the PostScript language. An experienced PostScript programmer will find many familiar concepts in PDF, but the commands have been stripped down for efficiency. At the same time, the data format has been expanded to handle annotations, hypertext links, thumbnails and bookmarks.
Similarities. PDF uses the PostScript imaging model. An initially blank page (a screen, a sheet of paper, etc.) is indelibly marked with opaque paint. Areas of the page are defined by letterforms defined in a font, by paths (which are connected segments of lines and Bézier curves) or by sampled images. Paths may be ?stroked? with lines of various thicknesses and end-caps. Closed paths may be filled with paint, and if a path intersects itself, the filling process can obey either the even-odd rule or the winding-number rule, just as in a PostScript program. In addition, paths are used to establish clipping boundaries, thereby using one object to define how much of another object is allowed to appear on the page.
Like PostScript Level 2, PDF supports JPEG, LZW, run-length and CCITT group 3 and group 4 data compression algorithms. It can use standard Type 1, Type 3 and TrueType fonts. PDF also keeps the concepts of the coordinate transformation matrix that governs how objects, which are defined in a device-independent "user space" are rendered on physical devices at a specific resolution. Data structures such as arrays and dictionaries are exactly the same as in PostScript.
Differences. In devising PDF, Adobe Systems had several goals, only one of which was to represent the pages of a document. Among these goals were speedy random access to widely separated pages via the links and bookmarks, the ability to update the PDF file with new annotations without destroying old versions, and the ability to add new features such as sound and video to future versions of the PDF format. As a result, PDF has many differences from PostScript:
- Short words. To gain speed and efficiency, PDF's page-description operators are short: most are one letter, a few are two. Several operators combine more than one PostScript operation. For example the b operator in PDF does the work of PostScript's closepath, fill and stroke verbs. Other operators are omitted, such as the ability to set halftone screen angles.
- No loops. To make page-building a predictable process, PDF does not have any programming language constructions for branching (e.g., if... else) or looping. Within any given page, a PDF interpreter runs straight through the code whenever it displays or prints.
- Page catalog. However, the pages of a file do not follow each other in linear sequence. Rather, the page descriptions are accessed through a catalog and balanced-tree data structure that is analogous to the directory system on a hard disk. The physical ordering of page data within the file is not prescribed; everything is accessed indirectly through the catalog.
- Indirect objects. PDF defines several basic types of objects, such as numbers, names, arrays, dictionaries and streams. The page descriptions, outlines, annotations and thumbnails are all built from these objects, just as in PostScript. However, in PDF, the objects have two identifying numbers:
an object number and a generation number, which allows multiple versions of an object to exist within a document.
In many cases, it is desirable to refer to an object before it has been defined, which is verboten in PostScript. PDF, however, allows this to happen; the object can be referenced indirectly by its object number. One advantage is that a large object, such as a compressed image, can be constructed before its final size is known, even though the size of an image is required for the construction.
- Cross-reference table. What makes indirect objects possible is that at the very end of a PDF file is a cross-reference table of objects. Through this table, a PDF reader application can quickly find all the data it needs to display any page. The table also makes it easy for different pages to share data. And as annotations are created and erased, the cross-ref table is easily updated in the computer's memory.
- Appended updates. When a new version of the file is saved, PDF specifies that instead of replacing the old cross-ref table, a new table will be appended to the end of the file. The appended data also contain a pointer to the previous cross-ref table, so it is possible to trace back through all the earlier versions.
Extensibility. Version 1.0 of PDF is print-oriented: its data objects support text and still images, but not sound or video. It won't be long, though, before voice annotation and QuickTime movies are routinely attached to files. In addition, the current scheme doesn't permit graphics within annotations; with the advent of pen computers, graphics and "ink" data will obviously be desirable. PDF has therefore been designed to be extended.
For example, most objects in PDF are defined by various dictionaries. In each dictionary, the parameters are tagged with names; specifying new parameters is a matter of supplying additional names and giving their values. A PDF interpreter that does not know what a name means is supposed to ignore the corresponding value. A PDF creator that doesn't care about a parameter is supposed simply to omit its name and value, allowing the reader to supply defaults. Within limits, this means that today's Acrobat applications (and Acrobat's PDF competitors) will continue to work in the future.
The header of a PDF file begins with the version of the PDF spec that it adheres to. In principle, a PDF-reading application could use the version number to determine whether it is capable of understanding the contents of the file. We believe that Adobe, through the Adobe Developers Association, will try to maintain an orderly sequence of upgrades to the PDF specification, so that higher versions will always be backward-compatible with earlier versions and older applications can work with newer files, albeit with limited functionality.
One direction in which Adobe is extending the product is support for SGML and document structure. This does not mean that the Distiller will magically add SGML to raw PostScript files. What it means is that SGML-tagging or some other tagging scheme (such as style sheets) could be mapped to PDF objects, using the pointer tables and object IDs we just discussed. If you had both the SGML source file and a PDF description of the pages, you could marry the two and create a PDF file that would carry the SGML information along with the pages. This capability would enable structured searches, generated tables of contents and other lists, and potentially other navigational features. It also would be a useful way to archive a document, complete with both source information necessary for revisions and the formatted version useful for printing. Working with Avalanche, which has technology for generating SGML from word processors, and Mastersoft, which specializes in filters, Adobe hopes to bring its SGML and structure support to market in 1994. (Ironically, Adobe will be getting its SGML support from Interleaf, now that Interleaf has acquired Avalanche.)
The gray book. More information on PDF is available in the Portable Document Format Reference Manual, published by Addison-Wesley. It is a 214-page paperback with a list price of $24.95. In addition to defining the operators of PDF, the Manual has an extensive section on optimizing PDF files for speed and size. And although it is written by and for programmers, it is nowhere as intimidating as typical computer-industry standards documents. There is some BNF notation, but it's not oppressive. However, many of the chapters presume a solid familiarity with PostScript.
Making PDF Documents
In examining Acrobat, we ran several tests, making documents in both Distiller and Exchange. With Exchange, the process is very straightforward, as with Common Ground and Replica -- you install the printer driver and thereafter simply choose that printer to create PDF files.
Batch is best. We also tested the Distiller, which is equally simple to run. You feed it PostScript files, and it spits out PDF files. If you feed it non-PostScript files, it rejects the file once it discovers an offending command.
The Distiller is highly recommended for graphic documents that you want to compress. It also will render EPS files, whereas Exchange will put in only screen-resolution bitmaps. The network distiller offers the distinct advantage of batch operation compared to the personal Distiller. You specify one or more directories for it to look at on the file server (the in-box), and whenever a file appears there it distills it and drops it into the out-box. Unfortunately, it lacks a reject box that collects files flushed by the Distiller. The program does create a log file, however. Because it is tied to the file system, not to any network protocols or software, the Distiller runs on any network in which a Windows or Mac application can recognize a file server. The process of making PDF files through the Distiller is very easy compared to most CD-ROM authoring/build products, which has been the model for mass distribution electronically. It is no harder than putting text files up online, and certainly much richer.
Against Replica and Common Ground, Exchange offers no advantage in ease of making documents. We did not find it more efficient in compacting the files, nor is it faster in making the files, and its lack of integration with E-mail was a drawback when compared to Replica.
In contrast, the Distiller is a distinct competitive advantage, because it accommodates organizations that have people who work on more than just Macs and PCs. Not only can the general office workers make PDF documents, but the graphic services department running a Magna, Miles, Datalogics or Xyvision system can too. Two companies (Elixir and SysPrint) have already written AFP-to-PostScript converters expressly for running mainframe files through the Distiller.
Adobe has made font handling one if its trump cards in touting Acrobat as a cross-platform, application-independent method of exchanging documents. Its key technology for doing so is Super ATM, which uses Multiple Master fonts to create a close substitute for any font called for in the document but not embedded in the document or resident in the system. The ATM font database is a list of font descriptors. Exchange and the Reader come with a database for Helvetica, Times, Courier, Symbol and Zapf dingbats -- type families that are typically built into the ROM of PostScript printers. The Distiller will extract dynamically metric information from other font files available to it as the file is being distilled.
Making documents. In general, each font is handled in one of the following ways by the PDF Writer:
- A font descriptor is placed in the PDF file. This method is used for Type 1 fonts that use the ISO Latin 1 character set. The viewing programs then rely on the font resident in their system to render the font. If the font is not available to the viewer, it creates a Multiple Master equivalent.
- A font is embedded in the file. This is the default for Type 3 fonts and Type 1 fonts that do not use the ISO Latin 1 character set. This ensures that the recipient will receive the font, but it also adds about 40K to the size of the file.
- Macintosh bitmapped fonts are converted to bitmapped Type 3 fonts. The resulting fonts are embedded in the file and therefore always available to the viewer.
- Characters are converted to graphics. Certain bitmapped and outline fonts are treated as images. When this happens, the fonts will display as graphics in the viewer but they cannot be searched as text.
Distiller. The Distiller expects to see PostScript data, so all non-PostScript fonts must first be converted to PostScript fonts or graphics before they can be run through the Distiller. Apple's LaserWriter 7.x and 8.0 and Adobe's PSPrinter 8.0.1 driver create synthetic Type 1 fonts out of TrueType fonts. The Windows version is supposed to do this as well, but it is still buggy, so Adobe offers two other options: substitute a Type 1 font or create a synthetic bitmapped Type 3 font.
Like the PDF Writer, the Distiller defaults to embed Type 3 and non-ISO Latin 1 fonts in PDF files.
The Distiller handles Type 1 fonts in different ways, depending on whether the font is available to the Distiller, whether it is an Adobe font, whether it uses the ISO Latin 1 character set and whether the Distiller has been reconfigured to embed a certain font.
Handling odd cases. If the file contains a decorative font or one that is beyond what Multiple Master can handle, then Acrobat will either embed the font or render the characters as graphics. If a character is repeated many, many times, the most compact method is to embed the font.
The Distiller does not do this automatically, but the default for any one font or all fonts can be changed by changing one of the lines in the Distiller's startup file.
Navigating in Exchange and Reader
Acrobat is what might be called an electronic page turner. The document is presented a page at a time, and what is shown is what would be imaged on paper or film. Aside from notes, annotations and links, which we?ll discuss in the next section, what you see on the screen is electronic paper.
As with other page turners (WorldView, FrameViewer, Replica, Common Ground, Helmsman, EDDARS), you can navigate through the document simply by turning a page at a time. This may be accomplished by menu, slider or pop-up dialog box. If you know the page ahead of time, you can also open up the page dialog and tell it to go to a certain page directly.
If you are accustomed to using WYSIWYG applications, viewing Acrobat pages may appear much like your source file. What you see on the screen is a representation of what you would see on the page, and, because most Windows and Macintosh programs are WYSIWYG, the differences in screen display in many cases are not that different. But users of electronic delivery software, accustomed to retrieving information on CDROMs, may have expectations beyond just turning pages.
Text searches. In most page turners designed for CD-ROM, users can find out where they want to go by conducting a full-text query. Such a capability is essential if the document is large or if multiple documents in a collection are to be searched. The initial release of Acrobat that is available now contains a rudimentary search tool, but it does not contain the Verity-based full-text retrieval that is slated for release as an option in the first half of 1994.
The current Acrobat search tool is much like the one in Common Ground, Replica and word processors: you can search for letters or a word within the open document. You can ask that the search be case sensitive or restricted to a whole word, but you cannot search on a phrase or apply any other restrictions, such as formatting attributes, tag/style names, boolean operators, proximity, and so forth. You also cannot search across multiple documents.
In short, the search tool is adequate for locating references to a word within a document, but it is not the sort of tool one would use to locate phrases on a CD-ROM.
This shortcoming is not as bad as it initially seems. First, Acrobat's searching is on a par with Common Ground and Replica, its current competitors for ad-hoc distribution. But Adobe has a clear advantage when considering distribution of documents that get archived. Adobe has already made provisions for a variety of full-text engines by planning an API for indexing and retrieval. This means that vendors other than Verity will be able to integrate their indexing and retrieval engines to Acrobat, making it possible to create in-house electronic libraries of formatted, published documents that can still be retrieved by full-text searches.
Thus, the full-text integration capability could be a strategic advantage and one way to differentiate Adobe, which will focus on documents worth saving, and Farallon and No Hands, which are focused on documents that don't hang around. Organizations that already have an investment in full-text retrieval may not have to sacrifice those investments in order to make use of Acrobat, and won't have to. And for those who do not have a full-text system in place, Adobe will have Verity Topic, which is a robust solution that is already well proven in heterogeneous networked settings.
The full-text API will also play a role in Adobe's plans in the professional market, which we'll discuss a bit later.
Browsing. After searching for specific words or phrases, browsing is the next method of navigation commonly used in electronic publications. Browsing is effective when the software creates a dynamic outline of the material, letting the user delve deeper according to interest. Unfortunately, Acrobat has no dynamic outlining capability other than turning page by page. (There is a named bookmark feature, which is discussed in the next section.)
What Acrobat does have is thumbnails -- miniature versions of each page. Thumbnails are optional when printing from Exchange and are automatically created by the Distiller. Even if thumbnails have not been created before you receive the document, as long as you have Exchange you can make the thumbnails at any time.
Thumbnails are most effective for highly designed documents, such as ads, brochures, catalogs and other sales and marketing literature. Documents that are mostly body copy do not work as well. Most body copy is shown as greeked text in thumbnails; for example, we found that pages of our Reports were not sufficiently different for thumbnails to be effective as a navigational aid. Thumbnails are also not practical for long publications.
Hyperlinks. Hyperlinks are also a common means of navigation in electronic documents.* Readers of print are accustomed to following links -- cross-references in longer documents or jumps in newspaper stories -- but the electronic medium is particularly well suited to this convention, because the computer can take the user directly to the destination, rather than simply providing a signpost telling the reader which direction to go. Acrobat offers a basic hyperlink facility that, while primitive, is still much more than Common Ground or Replica offers. However, it is not yet competitive with electronic delivery products aimed at professional publishers.
The Acrobat Exchange user may manually insert a hyperlink anywhere in a document. The link is tied to an x/y coordinate on the page. The user draws a bounding box around the link starting point, and the system then prompts the user to go to the destination page and point, and then to click OK, which creates a link.
Links may be visible or invisible.
When you follow a link, Acrobat replaces the page you were on with the destination page. This is in contrast with some systems, such as WorldView, that pop open a new window for every link followed. Part of the reason for the distinction is that in Acrobat, links are restricted to within a document. Following a link is analogous to turning to a different page. Since you can't view different spreads at the same time with a conventional book, why do it here?
In fact, there are times when you might want to view two different spreads, or even two different documents, at the same time. In WorldView and other electronic viewers, links may be across documents and even to non-document objects, such as a movie, animation sequence or a diagnostic software application. In such programs, you usually have the capability to backtrack your way along the links to your point of departure. More advanced systems have named paths of links or even "directed" paths that take cues from your logon or context of activating the link to take you on a series of linked items.
Links tied to physical position on a page work if the document is not revised, or, if it is, if the location of elements does not change. If they do, then links must be manually updated as well. This kind of manual updating is tedious if the material contains many cross-references. Adobe may get some help here from third parties, such as Ventura, which plans to write cross-references out as PDF markers.
In general, a rich implementation of hyperlinking technology would open up a whole range of possibilities for Acrobat, especially for professional publishers who might want to use the technology for document collections.
At this point, such possibilities are not likely to be realized before next year.
Enriching the Document in Exchange
Acrobat supports three "editing" functions, which enable an Exchange user to modify an Acrobat document. The first is the "append" command, with which multiple PDF files can be joined into a single document. The other two are bookmarks and notes. As a culture, we are accustomed to inserting bookmarks to keep our places and writing annotations or notes in the margins. Most vendors of electronic document products have included these features to help extend the book metaphor to the screen.
Adobe's implementation of these features is characteristic of a first product release -- Acrobat provides a basic, no-frills capability that will no doubt be fleshed out more fully in the future. In the ad-hoc market, though, Adobe is already ahead of Common Ground and Replica in this area.
Appending files. With this feature, a single document can be created from multiple source files, each of which may have been created in a different application. This is especially handy in the ad-hoc market, where users may not be adept at designing compound documents but may want to mix graphics, images, charts, spreadsheets, presentations and text all in one package, even if they use different applications to create the individual components.
Another reason to append files is to be able to use links, which in Acrobat do not reach outside of a single document. If and when Adobe supports links to external objects, append will not be needed for this purpose.
Annotations. In Acrobat, text notes, like links, are attached to an x/y coordinate on the page. You make a new note by menu, button bar or keyboard shortcut, and the program pops open a typing box. As you type, text wraps to the size of the box. The box is its own window; in the preferences dialog you can adjust the default size to whatever size box you prefer. The upper limit on the number of characters that may be in a note is 65,000. You can at any time move the box anywhere on the page or resize it. When you close the note, a note icon becomes part of the file.
The text within the note is a generic, sans-serif screen font. Text may be cut and pasted to or from the Mac or Windows clipboard, but there are no special editing keys, and there are no typographical attributes, such as boldface, italic or underline. There are no author attributes or titles for notes. Also, although you can ask the system to locate the next note in the document, there is no way to search on text in notes, unless you use the "Create Notes File" feature to dump the annotations out to a separate file.
We have mixed opinions on whether Adobe's annotation features will be sufficiently robust for review and approval cycles within corporate offices. In general, the annotations are easy to make and easy to remove. As long as documents are single column and use a reasonably large point size, people may be willing to switch from reviewing on paper to reviewing on the screen. For example, Adobe employees regularly use Exchange to review FrameMaker documents dozens of pages long. Adobe also has a phone directory and company floor plan as one of its sample documents. Annotations would be a way for employees to update the master phone directory in between publishings (assuming it is kept on the network) and at the same time provide the person who does the updates with a convenient way to find changes.
Should annotations move from one version of a document to another? (Do you move post-it notes from one set of pages to another? Do you rewrite annotations from one draft to another?) Adobe has provisions in its file format for preserving notes over document revisions, but it has not had its product in the field long enough to answer these questions for itself. However, we see some limitations. Once you begin working with public electronic documents, it isn't long before you wish there were a way to make some notes private and others public. Interleaf, Northern Telecom and EBT all support both public and private notes. Frame even has a departmental level. No Hands offers password protection.
But even if Adobe were to add that feature, some people would want other attributes, such as priority level, color-coding to indicate reviewer level, author names, date stamps, etc. As we mentioned in the introduction, for this type of work-in-process, we prefer a program that has attributes on the notes, or a robust editor, such as that from ArborText, which treats notes as sub-documents in which the full editing capabilities of the document processor are available to the reviewer. Persistent annotations, those that can be kept with a document even when it is updated, require an indexing scheme that places unique identifiers on each element. This will not be possible at least until SGML support is introduced, and even then will require much more than what Avalanche demonstrated in April. In the meantime, EBT has this now and Interleaf and Frame will have it before Adobe.
So we are unsure just how much Adobe will have to do in this area. It seems as though there is much need for improvement, but we are an editorial organization; people who do not view themselves as publishers may be less demanding.
Bookmarks. Acrobat bookmarks operate very much like ones for printed books -- they mark a page to return to. In a book, a bookmark brings you to a page spread; in Acrobat, it brings you to a specific page. (Acrobat does not support a spread view, as Replica does.) As with conventional bookmarks, Acrobat does not pinpoint a section of the page with the bookmark. However, it does remember the view associated with the bookmark. You could, for example, have it remember that the page was scrolled to a particular place and zoomed to a particular size (see photo).
You also name bookmarks, putting them on a palette on the left-hand side of the screen. In this palette, bookmarks may be rearranged into an outline, with some bookmarks subservient to others. Until Adobe or other vendors add support for automatic generation of tables of contents within Acrobat, Adobe suggests users create bookmarks at the pages of major headings in order to simulate a table of contents. We tried this for one of our back issues, archived in Microsoft Word. Even though our list of headings was not very extensive, manually creating each bookmark was a tedious task that we would want automated if we were to do it on a regular basis. Adobe hopes to have third parties (Ventura, Aldus, Quark, et al.) make table of contents bookmarks directly from their applications, but this is not likely to happen before the end of this year. In the meantime, professional publishers of reference material may want to consider other products that already do create contents pages automatically.
Assessing Its Potential
As we pointed out in our coverage of electronic delivery from the Seybold Seminars in April, the expectations and requirements of ad-hoc and professional publishers overlap but are distinct. The Acrobat suite has potential for both segments of the market, but the initial version is clearly better suited to ad-hoc distribution.
Potential for Ad-hoc Publishing
We still believe that Acrobat Exchange's biggest potential is a shrink-wrapped, mass market application for delivering documents electronically within an organization. This segment of the market, characterized by many people communicating with many other people, demands convenience and an application-independent file format. Adobe delivers on both counts.
The fact that Exchange is easy to use, that it works not only with any Mac or Windows application as a printer driver but also via a batch distiller of PostScript, that it gives users a familiar metaphor -- an on-screen facsimile of printed pages -- and that it enables users to print any Acrobat document they receive are all in its favor.
Compared to Common Ground and Replica, which also offer most of those things, Adobe offers an open, extensible file format that is resolution independent and gaining third-party support, and it is developing a full-text retrieval API.
Easy to distribute; easy to read? It is important to note that the ease of reading Acrobat files on the screen depends on the way the document was formatted in the first place. If you stick to one column and large type, it's not too bad. Even long documents can be read on the screen, much as you would within a word processor. But if you have multiple-column documents with type smaller than 12 points, our experience is that Exchange is no substitute for paper. Too many documents are simply too hard to read on small, low-resolution screens.
Instead, many people may use Exchange as a more convenient way to deliver documents that ultimately the recipients will print rather than receiving documents printed by the sender. The sender can send five copies of a document to five people via E-mail much more quickly than printing five copies (or printing one copy and photocopying it) and then routing them through intercompany mail. In a corporate environment, where most users are connected to a printer, it strikes us that it is a reasonable request to ask recipients to print the document if they find it hard to read on the screen.
A strategy for page archives. For documents that are more important and become part of the corporate library, Acrobat's indexing API will enable a corporation to blend PDF with files of other types in a single full-text database. Because of Adobe's relationship with Verity, this scenario will most likely be feasible first with Verity's Topic software. Adobe now says its Verity offering will probably not be available until early in 1994. The API should be available about the same time.
Areas for improvement. Acrobat does have great potential in the corporate market, but there are still minor problems with the initial version of Exchange:
- Although Exchange does handle most of the things business users will put into their documents, it does not currently support all of the features they might put into them. Sound, video and animation clips are not recognized. (Replica and Common Ground share this limitation.) Because the PDF file format is public, developers or in-house programmers can modify drivers or applications to make the proper PDF marks for these data types. Unfortunately, at this point only Adobe has a PDF viewer, and it cannot be modified, so the marks are ignored by Exchange (and hidden from the user) when the document is viewed.
- Exchange is not customizable. We just mentioned the limitation of not being able to modify the viewer. This is a distinct weakness, and one that leaves an opening for a competing PDF viewer. For electronic delivery to be transparent, Adobe needs to make it easier for developers, system integrators and in-house MIS staff to integrate Exchange or the Reader with their applications.
For example, if you want to E-mail a PDF document, right now you print to a PDF file, or print to a PostScript file and run it through the Distiller. You then attach the resulting file to your E-mail message. But with E-mail programs becoming integrated with other applications (such as CC:mail as a menu within Word), what you'd like is to be able to E-mail the document from within Word and have it automatically converted to PDF as it is sent. Or, even better, integrate the PDF viewer into E-mail directly, as Farallon has done, or into the operating system, as GO intends to do with Common Ground.
There are several approaches to making the program programmable: interpreted scripts (e.g., Bestinfo, Aldus, Interleaf), plug-ins (e.g., Quark, Photoshop) or an API. Adobe has had such success with its plug-in approach for Photoshop that it is considering a similar approach for Acrobat. Acrobat is a little different, in that it is both a module that might be plugged into something else and the main application into which something else is plugged. Whatever the approach, Adobe eventually will have to support some sort of customization in order for corporate sites to tweak the program to their needs, and the company clearly sees this as an important direction to take the product in the near future.
Looking Ahead: Potential for Professional Publishing
Adobe faces much stiffer competition in the professional segment of the electronic delivery market. There are already more than 20 suppliers of CD-ROM authoring systems; and there are upwards of a dozen established providers of document viewers that have technology that is further refined, especially in the areas of indexing and hyperlink capabilities.
Even more of a concern is that in nearly every segment of the professional publishing market, several suppliers already offer tools designed for that application. Voyager has a toolkit just for novels; Comptons has one designed for encyclopedias; Dataware has one for directories; Donnelley offers custom ones for children's works; Ntergaid has one for hyperlinked collections; and EBT, Frame, IBM, Interleaf, Owl and Westinghouse are all pursuing corporate information providers. Add to those the many other options that are available -- Kodak Photo CD is being used to supplement coffee table books; media conglomerates and telecommunications companies eye cable and wireless computing for home shopping and other services -- and pretty soon you discover that the professional information-provider tool market is very competitive.
Who needs pages? Because it follows a page model, Acrobat is most appealing to publishers of information that must contain page citations, or whose customers prefer pages that can be printed as they look on the screen. In the former category are legal publishers; in the latter are libraries (which want the customer to look up the reference, print the pages and get off the machine) and organizations, such as insurance companies, that provide documents on paper to customers but want their in-house customer service representatives to be able to call up the policy on the screen. An Acrobat beta site, Liberty Mutual, is testing Acrobat for this application. Other insurance companies use imaging systems to achieve a similar result.
Pages online. One area receiving much attention is the capability to put newsletters or other publications online in Acrobat form and then have subscribers buy their own readers to download the files and read them. To the subscriber, the lure is being able to get timely information even faster than before. To the publisher, being able to distribute without the overhead of printing has obvious appeal.
One area of concern is that for some publications this distribution method amounts to a site license to customers to print and distribute their own paper copies of a newsletter. Restricting the number of times a customer can download a file does not prevent thousands of copies being sent via E-mail or printed and distributed conventionally by the subscriber, all from a single download. Few newsletter publishers rely heavily on site licenses, so this problem is one they will most likely resolve happily in order to increase their subscription base.
Publication archives. We view Acrobat as a natural application for archiving documents that are electronically composed. As magazines and newspapers migrate to complete electronic pagination on systems that support PostScript, it makes sense to consider building an archive of pages ready for faxing, reprinting or viewing on the screen. If connected to a full-text retrieval system, the same archive could be used for research purposes.
Time Warner is investigating this possibility for its news magazines that are in the process of migrating their production system from Atex to Quark Xpress. The editorial offices currently feed their text to VuText, Nexis and Lexis and then subscribe to those services for research purposes. With an Acrobat-based approach, they could retrieve whole pages, with graphics in place, not just text.
Reference publishers who need to keep an archive of revisable text might also want an Acrobat archive for reprints, but they would probably maintain that archive alongside their editorial database, not in place of it.
Remote printing. Until recently, being able to transmit a publication for printing somewhere else has been an expensive proposition that only large news publications could afford. High-resolution facsimile devices were required because pages were pasted up by hand, not on the screen.
News organizations that are doing electronic pasteup have begun transmitting PostScript files to remote printing sites, thereby saving themselves the time of outputting pages and scanning them at the sending site. Acrobat may make this process even faster by introducing better compression, thereby saving time in transmission of the files.
Acrobat might also help organizations that send unrasterized files to remote sites. For example, the Times Fax, published by the New York Times, sends electronic files to its customers, who print the documents locally. On cruise ships, Ventura Publisher is usually used. In other markets, other software may be used, or the publication may be faxed to the customer. In some instances, the printing software does not support the fonts Times Fax uses. The Times is investigating Acrobat to see if it will help alleviate this problem.
Donnelley is investigating the use of Acrobat for magazines that want to offer customers the ability to retrieve and reprint articles on demand. What they are testing today is the ability to send out or put onto a bulletin board a file that could be downloaded to be read on the screen or printed locally. Most of the time, the material will be time-sensitive. Donnelley expects that many people will read the material by printing out a hard copy on their own printers.
Fax publications. Another page-based application is the fax publication. It would be very easy to offer not only the publication itself but also faxes of articles, back issues, order forms, and so forth.
Advertising. Advertising is one publishing genre that has yet to be addressed adequately by any electronic delivery product on the market. Does Acrobat, because it conveys the full richness of a PostScript file, address this area?
The first issue to be dealt with is electronic transmission of ads destined for film and print. Newspaper publishers would like to encourage advertisers to make up their own ads, and advertisers and agencies would like to avoid sending duplicate films to all of their publishers. But the lack of a single industry standard has hindered efforts to adopt electronic transmission. Acrobat is the first product that looks viable for transmitting newspaper ads, especially black-and-white ads. Several newspapers are experimenting with this concept, but none are yet using Acrobat to receive real ads.
If it works for newspapers, no doubt magazines will try it as well.
For this crowd, there is one reservation: Adobe itself cautions against using Acrobat for high-resolution applications. Acrobat does not carry any special screening you might put into the file, and compression is not recommended for material intended for high-quality film separations.
The second issue is electronic advertising. Pages that contain ads could have hyperlinks to additional information about the advertiser. This is interesting, but it would be far more interesting if the link were programmable, so that it could fire off a communication session directly with the advertiser's online ordering or customer support system. Such developments will not be in the product for at least a year.
Catalogs. Catalogs would appear at first glance to be an obvious application of Acrobat, since many catalogs feature complex typography. But most catalogs are selling tools derived from a database, and at this point it is not clear how well Acrobat might mesh with a publisher's expectations.
If the catalog follows a model of building the screen display of pages on the fly, then Acrobat might work. In addition to showing pages, the software would need to offer some mechanism by which customers could act on their impulses to buy the products displayed in the pages. Greg Phipps a marketing manager at R.R. Donnelley, noted that an electronic link to an ordering system is a "logical requirement" for most catalog publishers. Although such a link is not yet supported, Phipps' engineers have assured him that one could be built.
What is harder to imagine is how Acrobat fits a model in which pages are built on the fly from a database, such as you might want if you could customize the "catalog" to each customer, perhaps through a login in an online product. Catalog publishers are keen on the concept of narrow-casting; whether they will be able to achieve it with a technology based on PDF will take some time to figure out.
CD-ROM. The initial release of Acrobat is not well suited, in our opinion, to document collections, which are by and large what publishers would put on CD-ROMs. Adobe plans to offer full-text indexing and retrieval based on Verity's Topic to help with retrieval in collections. Verity has yet to prove itself in the CDROM marketplace, so at this point it is hard to tell how well it might compare to the competition. We expect it may be on a par with some, but doubt it will be better than many. What is more important is that Adobe does have an API for indexing and retrieval, which will enable other indexing mechanisms to be substituted for Verity, and it is actively working with third parties to develop complementary products.
As an example, Dataware, the leading supplier of CD-ROM authoring tools, is working on a joint product with Adobe. Dataware has indexing software that is optimized for field-based searches on a CD-ROM. It also has tools for creating customized retrieval user interfaces based on user-defined index fields. We can imagine that combining Dataware indexing with the Acrobat viewer would be an appealing combination for reference works that have page citations. It might also be nice for libraries because the user could easily print pages after finding the hits.
The downside for Adobe in the professional market is that many professionally printed documents are hard to read in Acrobat. This is clearly a problem for a publisher trying to create an electronic product meant to be read on the screen -- a CD-ROM encyclopedia, software manual or mystery novel. Adobe suggests that the documents can be redesigned for the screen, but, as we pointed out in July, the tools for creating typography on the screen are not what they should be, and redesigning them kind of defeats the whole page model metaphor anyway.
Other features needed. For Acrobat to work for collections, Adobe will have to beef up more than just its retrieval:
- Structural navigation. Thumbnails are fine for short, highly graphical documents. Bookmarks are OK for short documents of a variety of types. But meaningful navigation of long documents will not come until next year, as an outgrowth of SGML and Mastersoft support.
- Generation of PDF marks. At this point, there are no applications that automatically generate hyperlinks, annotations or bookmarks in PDF format. For example, if you use PageMaker, you would like indexes and tables of contents generated from markers automatically to create Acrobat hypertext links when you make the PDF file. Frame and Interleaf support this automation when loading their own file formats into their own viewers. Most other vendors that have automated this process in a commercial product rely on SGML encoding to specify the type and location of tokens. Many publishers still rely on conversion houses to write custom routines for automating this process.
- Adobe plans to support SGML. Aldus and Ventura have said they would like to support PDF, but neither is yet willing to say when such support might materialize.
- Better links. The links are going to have to be improved to support professional publishing. Many suppliers have programmable links (Owl, Interleaf, EBT, Westinghouse, etc.). Programmable links are a virtual necessity for many applications, ranging from nuclear reactor alarms to parts catalogs.
Essentially, you need to be able to launch an application and/or run a script as part of following a hyperlink. We expect that to stay competitive, Adobe will have to add link attributes, a backtrack facility and support for multiple destinations from a single link reference.
- Customization. Acrobat by itself does not yet offer customization. How well Adobe succeeds in facilitating the integration of Acrobat with other tools may play a large role in determining its fate in the professional market. Publishers insist on customizing their delivery software, because a design that is appropriate to the content is part of what differentiates and sells their products. They will not be willing to settle for a generic viewer.
The PDF provides a solution to three needs:
- First is the need for an interchange format for viewing richly formatted documents.
- Second is the need for a data format for archiving documents.
- Third is a format for transmitting documents for remote printing.
In all three cases, the new age of open systems dictates that the format should be independent of any one particular application. Even better, particularly for archiving and printing, is a rich format that is not yet rendered at a set resolution and is not tied to one kind of output device.
With the exception of WorldView, before Acrobat, page turners were either tied to one application (e.g., FrameViewer) or bound to a rendered image of the page (EDDARS, Helmsman). PDF, like PostScript, is both device and resolution independent. Its viewer is slower than that of other pageturners, but its underlying format is also rich enough to support archiving of published documents that may need to be reprinted on printing presses.
No Hands argues that basing a delivery product on outline font technology will ultimately cause Adobe trouble, because supporting multiple outline technologies will become an unwieldy burden. We shall see. For now, Exchange looks hard to beat for in-house distribution of documents to be printed remotely, precisely because it is based on outline fonts. And remote printing is perhaps the area in which corporations will see the most immediate payback. Distribution and warehousing paper is 60 percent of the total cost of producing documents, according to Colin O'Brien, president of Xerox Document Production Systems (a firm that has had a little experience in documents). Organizations spend untold dollars just printing internal phone directories. Acrobat is very appealing as a way to reduce those costs.
No Hands' point about fonts does underscore what a shame it is that Adobe was unable to persuade Apple or Microsoft to adopt Display PostScript as its imaging model. Had that happened, both Microsoft and Apple could have built in system software for distributing documents based on a screen imaging model that would be the same as low-resolution and high-resolution output devices. As it is, Microsoft and Apple will no doubt add such features to their operating systems, but because they have diverged on different paths, anything based on their own screen models will not be very well suited to cross-platform distribution.
Adobe is still in the enviable position of being the company with the technology that brings it all together. (No Hands and Farallon hope to make that claim one day, too.) It's just that now it is an application instead of system software that does it.
Not ready for professional publishers, yet. Adobe's PDF file format is of keen interest to publishers, who like the fact that it is public, based on PostScript and therefore familiar and easy to adapt to. And, even though the professional segment is less bound to the page metaphor, there are many applications for which a page model will still be useful on the screen. But Adobe will have to strengthen its authoring and retrieval tools, either on its own or in conjunction with third parties, for Acrobat to become competitive in the professional market. As it is now, the product is just not up to the task for anything beyond remote printing and downloadable newsletters, and magazine or journal articles. Our own suspicions on this front were confirmed by Adobe's reference accounts in commercial publishing; all of those with whom we talked were evaluating the product, but none were using it yet at this time.
At the moment, Acrobat is designed for sending one document at a time, in contrast with WorldView and other page turners designed for document collections. Nevertheless, as third-party support develops, Acrobat inevitably will become more appealing for document collections.
PDF: An Open Standard
One of the things that sets Adobe's Acrobat apart from its competitors is the Portable Document Format (PDF), which Adobe hopes will become a de facto standard just as PostScript has. To this end, Adobe has published the Portable Document Format Reference Manual, a programmer's guide to PDF. Its stated purpose is to encourage competitors to market products that will compete head-on with Acrobat.
This sounds crazy until you realize that the market for all the document viewers put together is tiny compared with the installed base of graphics-capable computers. Large numbers of customers won't get interested in document viewers until there is a common data format that is supported by multiple vendors on all platforms. When that does happen, the market will grow tremendously and Adobe will get its share of that growth.
Truly open? Adobe has become a much more open and competitive company in the past couple of years, but software developers who remember the Adobe of the late '80s may still distrust its commitment to open standards. If PDF is really an open standard, third parties must be able to influence its future direction. Having defined it and created the first applications for it, Adobe is clearly in the driver's seat -- for now. As more implementors enter the market, Adobe may be tempted to use its "ownership" of the PDF specification as a way of keeping the competition one step behind. That would be a bad idea.
A parable. Consider what happened to Sun Microsystems and the Unix community. For years, Sun developed powerful technology standards and offered them to other workstation makers. But it was always careful to delay licensing until it had its own product out in the market, assuring itself of a 6-12-month lead. Many of Sun's standards were widely adopted by Sun's competitors, but those competitors also resented Sun's success in driving the market. When Sun became too successful and seemed about to unify the chaotic Unix market under its own banner, the competitors joined forces to oppose Sun, forming OSF.
Well, OSF slowed Sun down, all right. But it also kept the Unix market fragmented, shattering any chance that Unix might become the successor operating system when the mass market finally got tired of DOS. Had Sun been a bit more careful to assure its competitors that they wouldn't be frozen out, they all might be basking in the warmth of mass-market sales volumes today. Instead, it took until last month (after Microsoft started shipping its competitor, NT) for the Unix vendors to join hands. But it now may be too late. By delaying so long, the Unix crowd forfeited their lead to Microsoft.
The moral? Just substitute Adobe for Sun and PDF for Unix. Adobe can drive the market now, and can dominate it for a while. But if Adobe wants PDF to become universal, it will have to share power with its competitors, allowing them a real say in the definition of future versions of the PDF spec.