6 . 5 Integrating Text and Graphics
The integration of text and graphics is probably the single most problematic issue in electronic publishing. Document processing systems take many different approaches to the problems involved. Some systems import the graphics into the document. Others point to external files. Others convert the graphics into an internal format. Some allow graphics editing; others do not. Invariably, each document processing system has its own level of understanding of the graphics formats it can use. The formats themselves impose restrictions on the ultimate flexibility possible.
It is important to understand the types of graphic formats a particular document processing system can use. The portabilitythe ability to use the document on more than one computing platform of the document may depend on this one factor. Graphics formats supported on only one hardware platform will surely cause problems when the document and its associated graphics are transferred to another hardware platform.
Just as document processing systems can be classified as batch or WYSIWYG, the integration of text and graphics can also be accomplished in a batch or WYSIWYG manner. Let's examine both forms of integration and end this section with some thoughts about advice for users.
6 . 5 . 1 Language Oriented Integration
One aspect of a batch approach to text and graphics integration is a reliance on file names. In the typical case, a languageoriented document processor interprets the document and enters some graphics interpretation mode where it expects to see the file name of a graphic. The document containing the file name reference must be correct, and the file containing the graphic must also be correct and must include any conventions about the directory.
File name references are crucial when using a set of files that were moved, for example, from a UNIX to DOS system. DOS has more restrictive naming conventions then UNIX. To guarantee accurate file names, you must restrict the names to the least common denominator the DOS file names. An alternative approach to restrictive file names is to come up with a file name mapping scheme with some utility programs to automate the process. Either way, the solution is distasteful.
Encapsulated PostScript (EPS) files are the most commonly used format to represent the graphics placed in documents. Virtually all electronic publishing systems, including both the batch and WYSIWYG systems, allow the user to place an EPS file(13).
Both TeX and troff have mechanisms for importing PostScript files. These mechanisms consist of a set of TeX commands or troff macros, that insert the PostScript graphic at the appropriate point in the document.
A marvelous example of text and graphics integration in the UNIX environment is FaceSaver.(14) It's also an example of the UNIX hacker mentality. Over a period of several years, attendees of USENIX conferences (a popular UNIX conference) had their pictures taken and saved by the people running the FaceSaver project. The idea was to create a repository of faces accessible on the Internet. This has now been accomplished and the faces are stored at UUNET, a widely accessible Internet provider.
Given the existence of this repository of images, it is only natural that a number of "FaceSaver" utilities have been created. One particularly clever set converts the image into PostScript and enables the user to create business cards, labels, a letterhead, or a dartboard.(15)
6 . 5 . 2 WYSIWYG Integration
Some document processing systems, usually the higherend systems, attempt to display the graphic on the screen with the text. The manipulation of these graphics varies widely, ranging from no manipulation to total control. One important characteristic is whether the graphics are treated as an unbreakable block or whether the system supports some amount of graphic editing. In addition, some systems have an internal set of graphics. For example, FrameMaker has, roughly put, the equivalent to MacDraw built in, but without bitmapped image manipulation capabilities.
The placement of graphics and how the graphics should flow, visually and logically, within the text is a major design issue for page layout and document processing systems. The classic page layout system typified by PageMaker allows a high degree of textual integration with the graphics. You simply drag the graphic into an area of text, and the system will visually flow the text around the graphic. The control of such run-arounds gives the document designer a great deal of freedom. (See Section 3 . 1 . 4 Page in Chapter 3 Points of View for an illustration of text flowing around a graphic.)
Some systems allow graphics to be anchored to text; as new text is inserted or deleted, the graphic remains attached to the correct place in the text. Another form of anchoring is to attach the graphic to a particular location on a page, such as the top of the page.
WYSIWYG publishing systems differ in many subtle ways. The ability of a system to incorporate graphics into an integrated document is an area in which these differences can make a real difference in your publishing job. Keep an eye out for the types of graphic manipulations allowed and how the system handles external file references.
6 . 5 . 3 Inline versus External on the Web
As we've just concluded our discussion of language versus WYSIWYG, it is appropriate to compare the two integration mechanisms available for Web browsing. In much the same way that document processing systems have evolved from languages to WYSIWYG, Web browsers are evolving from a collection of loosely integrated "helper" applications to tighter integrated inline systems.
Lost in all the technical whiz-bang demos and slick Web pages we see is the supremely important issue of the user interface. The most significant problem with the external helper application approach is the change in user interface that a user must endure. One second you're happily clicking on links and the next moment some foreign application pops up and you must figure out what to do. Of course, the use of external applications is a good way of distributing new types of data formats before going through the labor of integrating that data type with your browser.
Netscape appears to have a good solution to this problem with the development of an API(16) that formalizes how applications may embed themselves in Web documents. This approach is similar to Microsoft's OLE (Object Linking and Embedding)(17) and the OpenDoc(18) architecture. The concept of "plug-ins," dynamically callable functional additions to an application, is well proven and is used extensively by a wide variety of PC and Mac software vendors. In geek terms, the plug-in architectures really consist of a welldefined Application Programming Interface (API), the interface between an application and externally defined functionality. The first Netscape Plug-in was a Virtual Reality Modeling Language (VRML) browser called WebFX by Paper Software Inc. In fact Netscape liked it so much they bought the company!(19) The plug-in is now called Live3D.
An example at the Live3D simple examples page at Netscape
This particular plug-in example uses the "frames" extension defined by Netscape that allows independently scrollable windows within the context of a single Web "page."
One interesting example of Web application integration is Adobe's Acrobat Amber. It effectively embeds their PDF Reader product into the Web browser. It functions quite nicely, but again, the integration of user interfaces becomes problematic. The icons from the Acrobat Reader product are now presently embedded on top of the PDF page in a strange location for Netscape's Navigator. It is unusual to go to a URL and have another application effectively embed itself in the page. Not terrible, just unusual.
Adobe's Amber PDF Netscape plug-in
Clearly the king of integration, however, is Java. Java represents the first true attempt at an open, fully distributable, neutral, Internet execution machine. Java is powerful for a few key reasons. First, it is highly portable. It is tightly integrated with the Internet and can establish asynchronous threads of communications which stream data across the net. (For more detail on Java, see Section 2 . 1 Java/HotJava in Chapter 2 World Wide Web the Next Generation.)
HotJava Sun's Java based Web browser
6 . 5 . 4 Integration Advice
Inevitably, you will be asked for advice on integrating some graphics with some text. Let's look at the problem from a different point of view the user's.
USER TYPES
The decision to use one particular graphics format over another, or to advise someone else in that decision, has a subtle component the type of end user. It may be perfectly appropriate to give one person one solution and another person a different solution. Some user types are:
FRANTIC USER: Someone with too many things to do. Word and document processing are just painful things they have to do to get that damn document formatted and printed. Typically, these are frontline managers.
TECHIE USER: A technical professional who is usually focused on one particular job at a time.
SYSTEMS ADMINISTRATOR: Someone who isn't all that familiar with publishing systems, but on whom you depend to keep your computers and network running.
SECRETARY: Someone who is often worth more than the boss and is forced to live with whatever approach the "experts" choose.
PUBLISHING PROFESSIONAL: Someone who is familiar with the primary publishing system, but who is not necessarily all that computer literate.
QUESTIONS TO ASK
In all cases, the format chosen must be usable by the publishing system familiar to the user. Some important questions are:
Will the graphic need to be modified once it is integrated with the text?
If so, how difficult is that process?
Does the integration process convert the native drawing format into another format that cannot be modified?
A conversion from a geometric representation to a bitmapped representation is a one way conversion. After the geometry is converted into a bitmap it would take a lot of trouble to go in the reverse direction, if at all. The notyetintegrated original geometric graphic must be maintained somewhere if changes are expected, raising the specter of configuration management.
Each type of user will have a different level of understanding and concern about these issues. Your responsibility as the expert is to balance these concerns with the requirements of the tasks at hand. It also pays to help educate the users so that they can eventually make these decisions for themselves or at least appreciate their complexity.
