SAMPLE CHAPTER

We're now ready to consider the actual business of rendering or composing a document in a form suitable for the consumer to use. (For our purposes, "composing" and "composition" refer to the process of preparing material for presentation, either in print or electronic form, although sometimes you'll find the term "build" used for the latter.) In doing so, we find lots of similarities in preparing hard and soft copy, and even more differences -- composition for the medium of choice, then, is usually two very different processes, using different application processing programs.

A few years ago, I attended a session at a publishing conference where one of the major vendors demonstrated a product, then still in development, that displayed a faithful, high-quality rendering of the printed page on a graphic display. The page used for the demo was a nicely-designed magazine-style page, with a dropped, centered heading and subheading and with two columns of text running around a centered, full-color photograph. After they displayed this page for a while, they went on to explain how the consumer was supposed to be able to read it (because when the full page was displayed, the type was too small for comfortable reading). They carefully zoomed in on the upper left column, read the upper portion of that column, shifted the image up to see the rest of that column, and then shifted the image down again to pick up the top of the upper right column and read down that column, shifting the image once again to see the bottom of it. At the bottom of the second column was a "continued on page 23," and they executed a jump to page 23, thereby preserving in electrons one of the more irritating aspects of the use of the print medium.

One could understand, given the interests and concerns of most of that particular audience, why they chose that example instead of one in a single-column layout with a larger font to make the page friendly for online reading. Nonetheless, the example they did choose demonstrated that a lot of what we know about turning out appealing and useful printed documents simply doesn't apply when the medium is display, and we should be seeking to optimize the advantages of that medium rather than distorting it to produce a page image that works well on paper.

There are some applications where an electronic facsimile of the printed page is indeed a requirement. And there are other applications that are what one might call "layout sensitive," where the concern is the specific view the reader sees. The availability of good tools to support this function is much to be desired. (And, just in case I was giving the wrong impression, nowhere is it written that these documents could not be produced from SGML source.) However, these are typically not applications where the primary concern is the usability of the information for the softcopy information consumer.

The print medium has enjoyed a half a millennium head start and even so, few magazines or technical manuals look today the way they did 50 years or even 15 years ago, except for the ones that do look the way they did years ago, which is to say they look dreadful. We should expect that there is much more to be learned about presentation in the display medium than we know today.

• What is a readable line length?
• Is this font that looks great on paper robust enough for a display, or does the lower resolution weaken it and wash it out?
• How do the variations in available color palettes affect the selection and use of color?
• What are the implications of the use of color for color-blind consumers?
• And so forth

Another point here is the high variability in the capabilities of displays. When you go to the publishing trade shows, all of the products are demonstrated on enormous, high-resolution screens, but in the mid-90s, the screens being newly-acquired are still predominantly 14 to 15 inches on the diagonal. (Display screens seem not to have enjoyed quite the same repeated and dramatic price/performance breakthroughs we've seen in other areas.)

Developing the output specification

At last we are on the verge of actually publishing something (well, at least getting it into publishable form).

It is highly desirable, if you're not already enjoying the benefit of their participation in your publishing process, to enlist one or more graphic designers to assist in developing the specifications for any processing programs that are directly producing content presentations for the consumer, either hard copy or soft. If this is beyond the budget of your project, you can still sometimes find, squirreled away in other parts of the enterprise, people with these skills who are willing to let themselves be borrowed to consult on design. If you have any reason at all to think that your presentation could be bettered in either communications effectiveness, or the image your documents project, or both, you will find that the contributions of a graphic designer can add significant value to your endeavor.

If you are using existing designs for either hard or soft copy, there isn't a whole lot of work to do here (assuming that the composition programs you are going to use are capable of producing the same result). You may already have written specifications for font style and size, leading, line weights, layout, and the like. If not, a sample document can be annotated with this information for use by the text programmer. For mapping the SGML elements to print output, probably the simplest thing to do with hard copy is take existing pages and annotate them to show the SGML source elements that they represent. What the equivalent might be for soft copy depends on the annotation capabilities of the soft copy tools you used (but at a minimum you can generally print something and work from that).

If you are using new designs, you will probably have mockups of the pages and displays and you can use these similarly.

There is one special consideration, which seems to be more of problem in print than soft copy designs, and that is to try and keep your design as flexibile as possible with respect to the lengths of elements. If you have a style that requires that chapter headings, for instance, not wrap, you may be better off with a style that looks better if the heading doesn't wrap but is still acceptable if it does. One thing you can't do in SGML is restrict the content of an element to what will fit in 28 picas.

If this is your first experience in putting materials online, you should expect to do some testing with your consumers or their surrogates before you decide on the final form of your presentation.

While those of us who have published in print for many years know that the most obnoxious problem we deal with on a daily basis is where the page is going to break, there are some advantages to page-oriented publishing. It allows for convenient places, like running headings and footings, to put identification information, effectivity information, and the like, not to mention footnotes. In a pageless environment, some alternative must be found for presenting this information, especially if it is information that must be persistently displayed. The ability to do this is dependent on the capabilities of your browser, so the possibilities there have to be determined first before you can decide how you want to do it. For instance, navigation aids such as chapter titles in the running headings aren't needed if the browser provides for persistent display of the equivalent information -- say, a table of contents that moves dynamically as the reader scrolls the document.

If your browser has the necessary options, you must also decide things like whether figures are to be inline or floated (placed in a separate window and displayed at user request) or mixed. If they can be mixed, how are the two different forms distinguished in the source?

And if your display of graphics isn't instantaneous, we strongly suggest you get rid of any graphics you may have that are merely decorative. Decorative graphics are fine where they don't require any investment on the part of the user, but if a user has waited for a graphic to paint on the screen only to find that it has no useful information in it, that user is liable to be unhappy. Indeed, if the graphics are to be displayed at user request, it is probably a good idea to augment the normal reference to the graphic with a description of what information it contains, so the user has a basis for deciding whether to pull up the graphic or not. (Having to describe the purpose of the graphic may be a good way to winnow out any that are merely decorative.)

And you must determine how caution, warning, or danger notices are to be treated -- for instance, can they be made to display automatically and persistently for as long as any of the information to which they apply is being displayed? Does the source document provide enough information to determine the scope of the notice? If not, some tuning of the DTD may be in order.

Another area to explore is the dimensions of tables. Some browsers allow for the possibility of very wide tables that the user can scroll horizontally. However, it is often the case that some tables are more useful when treated as very wide tables and other tables are more useful when their width is held within the boundaries of the screen and any expansion is vertical instead.

You should also be aware that the information "bite" shown on a typical display screen is considerably less than that of a two-page spread in a typical hardcopy document. Your information presentation is losing some of the benefit of the larger bite, the price one pays for not having to deal with page breaks per se. There isn't a whole lot you can do about this except to minimize the use of vertical white space, because all it does for you is test the strength of your user's scrolling finger.

If you notice that your graphics, when placed online, have difficult-to-read annotations surrounded by lots of white space, you might want to revisit your electronic drawing board, too. We've all seen graphics where, when you zoomed in close enough to be able to read the label, you could no longer see what it was pointing to. Rather than trying to illustrate everything in one large picture, your presentation might benefit from smaller graphics that handle different parts of the large picture.

Implementing the output specification

It is theoretically the case that, given an SGML DTD and a documented composition program interface, an application processing program can be written that can generate a data stream for that composition program from an SGML source instance. This is not to say that you will necessarily get the output result you wanted, nor does it suggest that all SGML documents will format happily with all composition programs. (Composition programs get better all the time, but I can still remember the days when I couldn't write a footnote longer than 7 lines because the composition program I was using thought that 7 lines was sufficient for even the most verbose footnote writer.) What this means is that developing the output part of your SGML-based application processing program is largely a question of meeting the application interface of your chosen composition programs. And this, in turn, means that the selection of composition programs should be based on an assessment of the following capabilities:

• Composition capability

  This is the most basic question of all -- can it do the job? You should have a well-prioritized checklist of function against which to measure all the contenders. And you need to make sure that your definition of a function and the vendor's definition agree, so that the vendor's claim to have a particular function doesn't lead to later disappointment. It is also important not to have your function list expressed in terms of implementation, because there can be many ways of implementing publishing functions and you might pass by a superior implementation of the needed function because it wasn't recognized as such. (Because users are used to expressing functional requirements in terms of the implementations with which they are familiar, it is sometimes difficult to extract the desired function from a user's statement of a requirement. The effort pays off, however.) For instance, a statement of a requirement for, say, widow and orphan handling should be expressed in terms of the desired results, rather than the specific algorithms for processing them.

• Capacity

  All too often one hears of composition systems that die of exhaustion on page 2524 of a 2850 page document at 3AM on the day in which the contract penalties kick in. Or of composition systems that can produce a master index for your library of books, but sorting it takes 96 hours. If your workload tends to large documents or other resource-consumptive tasks, you should ask your prospective vendor for reference accounts that have loads similar to your own. In many cases, it is not a matter of the processing program's capacity but rather the availability of other system resources for use by the processing program, so the equipment configuration is also a consideration here.

  You should also ask about any restrictions, such as size or count limitations, on the features you are interested in. There may be length limits on headings or index entries that can't hold the polysyllabic chemical names you need for your FDA New Drug Application.

• Ease of specification

  What you are looking for here is some balance between highly powerful but difficult-to-drive programs, where it takes a long time for the text programmer to learn how to use it effectively and efficiently, and simple-minded interfaces that don't really support what you need to be able to do. (Of course, sometimes you can thwart even the most determinedly idiot interface by preprocessing the SGML and transforming it into something simpler before handing it off to the composition program, but this approach won't work for anything where you need to control the actual composition details.)

• Parameterization, maintainability, and extensibility

  If, on the day you decide to change the base font from Baskerville to Cheltenham, you find you have to open 300 dialog boxes and change 200 occurrences of the font name (the other 100 dialog boxes because you don't have an authoritative list of the ones that have to be opened, so you have to open them all), you have a system that either doesn't support parameterization or an application processing program that failed to use it properly.

  Successful SGML applications grow. The expectation in designing the application processing program should be that it will be subject to regular update for years to come, so all the good things that make a program maintainable and extendable -- modularization, parameterization, etc. -- have to happen here, as well, and the underlying composition program has to make this possible. If it takes as much effort to add support for the second set of paired-list elements as it did for the first, this objective has not been met.

The portable application processing specification

Not very long after the publishing community came to understand how to achieve portable documents, it became a requirement to have portable application processing specifications as well. The development of application processing programs is a fairly major commitment of resources, depending of course on the richness and complexity of the processing required. (It should be noted, however, that setting up major SGML-based applications is not more difficult or more expensive than setting up any other type of major publishing application that provides comparable functionality.) The desire to have an application processing specification that can outlive a particular set of software components, or that can be interchanged with systems with unlike components, is not difficult to understand.

You may have already encountered references to FOSIs (generally pronounced "FAH-sees") and/or DSSSL ("DISS-uhl"). FOSIs, or Format Output Specification Instances, are SGML documents that define the output format for print materials derived from SGML source. Very briefly, a FOSI associates SGML element types (identified in any DTD) with composition specifications. The FOSI specification itself was developed as a stopgap measure in defining portable application processing specifications to support the United States Department of Defense CALS (Commerce At Light Speed, formerly Continuous Acquisition and Life-cycle Support, formerly Computer-aided Acquisition and Logistics System) initiative and is fairly limited in function. Support for the use of FOSIs has been implemented by a very small number of vendors. The gap that FOSIs were stopping was the wait for the completion of DSSSL and the availability of systems that support it.

DSSSL, or "Document Style Semantics and Specification Language," is a recently-approved International Standard (ISO/IEC 10179). One tends to think of the word "semantic" as referring to the meaning of an element in terms of its content -- for instance, a part number element in an illustrated parts catalog. However, here the word "semantic" refers instead to the presentation semantics that can be applied to an element -- its font, size, position, etc.

The objective of DSSSL is to allow the development of application processing specifications that are independent of any specific composition program or other application processing program. There is an effort underway to define a subset, known as "DSSSL Online," implementations of which are likely to precede full DSSSL implementations into the marketplace.