High Quality DVI Drivers

Klaus Guntermann TH Darmstadt Joachim Schrod TH Darmstadt

July 1988

Abstract

Document preparation with TEX is done in two steps—first TEX formats the document, afterwards a DVI driver creates the final output. While TEX is reliable and produces the same results in each implementation, DVI drivers remain to be the critical part of the document preparation process. To specify a high-quality DVI driver the circumstances of its usage must be analysed. We identify four groups of persons which are concerned with the handling of a driver: users, (TEX) system administrators, distributors, and developers/maintainers.

The demands on a DVI driver are mainly high reliability (the device must remain in a consistent state), a uniform user interface (previews and printer drivers should behave similar), and a standardisized treatment of extensions (e.g., handling of graphics inclusion). Other matters of interest are available features, accuracy of output, throughput, font handling, portability, and maintainability. This analysis yields in criteria for the judgement of a DVI driver’s quality—furthermore these criteria constitute a contribution to the standardization process.

1 Introduction

“High Quality DVI Drivers” will not discuss the latest high resolution output devices and the drivers that can be used to make them print the most beautiful documents. Instead we will stress drivers for any output device and enlighten their usage and features, to see whether they can be considered high quality. This will not lead to “the ideal driver,” but result in better drivers that become as reliable as TEX is.

Of course the requirements for a driver are different for all the people that come in touch with it. We will start with an investigation of the life of a driver, then we will go into details of user interfaces, output creation, and implementation issues. Finally we will propose standards for extensions via the \special command.

2 Who Is Involved?

To identify the groups of persons who get in contact with a driver we look at the “life” of a driver. It must be taken into account that these groups are distinguished by the functionality they have during the driver’s life not by the identity of subjects. Of course, this covers the widespread situation that the persons who implement a driver write the user manuals, too, and are therefore also users of the driver. As with every software product the life of a driver is not a straight forward sequence of actions. Nevertheless stages can be characterized with the model of the software life cycle [8].

• The driver must be documented, implemented, and tested, afterwards (or in parallel) a user manual must be written. We call this phase the development and documentation phase and the persons concerned the developers.

• Then the driver must be sent to its user by a distributor. There is neither a big difference whether this distributor is a commercial one or not, nor is there a big difference what kind of media is used for the distribution— the principal work of sharing all files that resembles a driver is the same. In this context we want to call your attention to the assumption that the driver is distributed as a system ready to use, i.e. in executable form including a set of fonts, without any sources. If the sources shall also be distributed, arrangements must be made for the creation of a consistent, running system.

• The next step is the receipt of the driver by those who want to use it. This driver must now be installed; if the user is a single person this will be done by himself. But in many cases a (TEX) system administrator will have to do it. These system administrators most often want to adapt the driver to local requirements, too. Therefore we distinguish the installation phase and call the persons concerned installers.

• After the driver has been installed it can be run by users. During this phase errors will be detected (no software system is free of errors) and hints for changes or extensions will evolve.

• The feedback of the users will be treated by the maintenance group. If they change the driver due to this feedback the cycle is entered at the point where the test and the documentation has been done.

During the stages of the software life cycle different people work on the driver. All those people have different requirements—these can even be contradictory. But because the system is made for usage the requirements of the users must have a strong preference over the other ones, our study will start with the user’s point of view. In the rest of this paper we will distinguish from whom the specific requirement will come. Only if all groups have the same requirements or if the context clarifies the persons concerned we omit the distinction.

3 User Interface

The most interesting part of a driver is of course a list of its capabilities. These make it more or less usable. Looking around in the scientific community most people have to deal with heterogeneous computing environments. Documents are often enough moved from one computer to another in the different stages of document preparation. In this case it is mandatory for satisfactory results that drivers in the different environments behave similar. This user requirement splits up into several conditions:

• The drivers must offer the same set of options with a uniform command language interface—as far as reasonable interpretation is possible; see the list below. Additionally there may be alternate command language interfaces that are compatible to the computing environment in question: e.g. a menu and buttons for systems with a graphical shell or any other command language specific option method with prompts for mandatory options etc. These site specific additions make usage easier for people that are restricted to one environment and help them to become familiar with the driver. This may also hold for support staff that has to maintain command scripts for all programs and prepare additional user documentation.

• The drivers must create the same visual output on all devices—with respect to resolutions. This condition is extremely important to make previewing reasonable.

• The drivers must handle exceptions the same way. Of course it is the responsibility of the people that install a driver to make the same set of fonts available for all drivers and output devices.

• Activation of any extensions through the \special command must be standardized. Otherwise misinterpretations of commands will lead to unexpected results. Extensions that are not handled must have no effect other than creating a warning message.

Printer drivers must be able to run unattended (in “batchmode”). Requiring interaction in exceptional cases is not tolerable when drivers are processing output files in a spool queue.

Now we list a number of options that is to be included. We start with those options that are considered to be a minimal set:

• Partial output of a DVI file.

The selection must allow to give at least the 1. starting page number

(a) referring to TEX’s \count0, which designates the printed “page number” in most macro packages,

(b) with respect to the order of pages in the DVI file.

This distinction is necessary because some macro packages use the same counter values in several parts of a document. Thus a selection using \count0 does not lead to the desired page in all cases.

2. a maximum number of pages to print (not reasonable for preview drivers) or

3. an end page number, also either referring to \count0 or with respect to the order of pages,

4. an increment used to step through the document (with the reasonable default value 1, but not required for preview drivers, see below)

For printer drivers multiple ranges in one run of a driver are required. Otherwise the initial overhead of a driver run can cumulate.

• Override the magnification for the document to obtain a zoomed output. Of course this will also affect all “true” dimensions.

• Specification of the number of copies—selectable as the number of copies of each page or the number of times the selected page ranges are repeated.

• Placement of the output on the page: values for top and left margin. The default margins must depend on the paper format. In the US the standard margins are 1 in for legal paper. For the European A4 paper 2 cm margins have proved reasonable.

Additionally the following options can enhance the versatility of a driver:

• Selection of pages with respect to the other counters \count1 to \count9. (These counters are seldomly used by macro packages because they usually allocate their counters dynamically.)

• Processing of multiple files in one activation. This reduces the overhead for initialization in printer drivers and allows switches from one document to another without leaving in preview drivers.

• Selection of orientation—portrait or landscape.

Printer drivers have additional features which should be part of a high quality driver:

• Selection of processing order for the pages to override default. Default must be the reading order when the pages are taken from the output stacker, i.e. reverse for face up output, forward for face down or sorter output.

• For devices that allow multiple input stacks or sorter output these must be controllable by driver options. In a multiuser environment operating procedures may require that some of these features can be disabled for the normal user. Otherwise an output job might block the queue waiting for insertion of a sheet in a single sheet feeder.

• Selection of paper format.

• Placement of multiple pages on larger sheets is a requirement for professional output.

Preview drivers require another degree of interactivity. Thus some of the options from above show up again as dynamic selections in the following list:

• For small screens allow reduction of the output to see a whole page on the fly (and switch back again), even if the text is not readable any more.

• Show information about the current page including page number (it may not be written on the page), relative position of the page and the total number of pages in the document.

• For small screens allow the user to select the displayed part freely.

• Let the user scan a page with simple commands if it does not fit on the screen. These commands move the displayed part in discrete steps across the page, there must be an overlap between the actual and the next page notch.

• Let the user select interactively the next page to be seen, but make the default easy without boring interactions for

1. move to the next or the previous page,

2. skip to any page by page number,

3. skip to any page by relative distance (forward or backward),

4. skip to a page relative to start or end of document.

• If the host operating system supports a multi-tasking window system, the driver must be able to use it.

Again there are some options that are not required in each case but make things easier under many circumstances:

• Let the user select the size of a virtual output sheet and handle offset parameters like the printer drivers. Thus positioning of output can be checked completely on the screen.

• Allow display of a ruler to measure distances in the document. The labeling must be user selectable using all the units provided by TEX.

• Override the magnification during the session for closer inspection.

• Let the user scan the page in a natural way, if it does not fit on the screen. The same command goes right as long as there is something not seen and then return to the left base for the next slice; skip to the next page when the bottom right part was seen.

• Let the user interactively specify the home position on the screen, i.e. the position in the page which will be shown first for a new page.

• Let the user select foregound and background colour if the display is not monochrome.

The principles of operation, any drawbacks or limitations and the user interface must be described in a manual. It must contain

• the environment requirements of the driver (main memory, disk space, special hardware or interfaces),

• precise specifications for all options and their default settings,

• any other way to change the behaviour, e.g. environment controls,

• a reference to all error messages and suggestions for user reaction,

• a description of installation procedures in a separate section, and

• an index.

To help casual users either online documentation through help or online manual features of the host should be available. These must include all possible options with short explanations. If no help system or online manual is available, the driver must give the necessary information when asked. A cryptic list of option switches without explanation is not sufficient.

Developers become users of their drivers when they prepare their documentation. For driver families it is rather straightforward to create one document and select the host specific sections through conditional parts included in TEX’s

\if and \fi.

4 Expected Characteristics

Beyond all bells and whistles there are a few overall characteristics a driver is expected to have. The most important one is its reliability. A driver must not crash down nor must it leave the computer system or the device in an inconsistent state.

• Printers must be reset to a usable state, a following job must be able to use it without difficulties. If there doesn’t exist a font management independent of application software the driver must delete all fonts it has downloaded.

• Previews must leave a usable terminal which accepts user input.

The other side of reliability is a good error recovery. The driver should try to output as much as possible—and the output should be the best approximation to the DVI document which can be made. If the device storage isn’t large enough to hold the contents of one page, if a font or a character is missing, or if some components cannot be output due to hardware drawbacks: in each case the driver should try to discard the page component which leads to the error and should leave the space for it if this is possible.

The error messages should be precise and include information for the user (or the maintainer) to identify the source of the problem. All error messages should be written to a log file, too—the user doesn’t want to copy it to paper by pencil.

These points are much more important than every feature of the driver and even more important than performance. A very fast driver with a bunch of features which doesn’t produce correct output and crashes leaving the system in an inconsistent state (and supplying cryptic error messages) is of no use for realistic productive document preparation.

Nevertheless performance is an important feature, too. A high quality driver should not be the “bottleneck” of the printing process—devices and communication lines are usually very slow. Under some circumstances it can be prefered to discard the support of some features of the user interface while featuring performance issues, e.g. for a production driver for high resolution devices where only final printing is done.

5 Output

The essential task of a driver is to create the most satisfying output which is possible using the intended device. This output is described in the DVI file [1]. As the name expresses the representation of the document is device independent, which is achieved by the following characteristics:

1. The characters are not regarded as an element of (device-specific) fonts but as an element of a type in a specified magnification. The assignment to fonts (and then to font files) must be done by the DVI driver.

2. The positions of these characters (and rules) are given in scaled point (sp), with 2^{16} sp in 1 pt and 72.27 pt in 1 in. Because there is no device available with such a resolution (and surely will not be in the future) a driver has to transform the position details in minute raster into the coarsemeshed raster of the device.

The consequences of these items for a DVI driver are discussed in this section.

5.1 Fonts

Fonts, i.e. collections of character images for a specific output device, are one of the main resources a driver must handle. For each group of persons different views of the font handling can be stated. The primary interest of the developers who must implement, document and maintain a couple of drivers is a uniform handling of these fonts, i.e., a uniform naming scheme. System administrators have to install the driver—they want to adapt the naming scheme to the existing system environment. The user of the DVI driver wants to have a complete set of fonts so that he can create documents with the usual TEX macro packages and doesn’t have to be concerned with the availability of fonts.

5.1.1 The Format of a Font

Fonts are stored in font files. Currently, three different “official” formats of these font files have been published:

1. The GF (generic font file) format [2] is output by .

2. In the older PXL format [4] each character is represented as a bitmap with each bitrow padded to 32 bits. This format has the drawback that an important information (the device dependent width) is not included.

3. The PK (packed font file) format [9] was introduced to achieve savings in the demands for disk space. With this PK format the needed disk space is reduced to about 40 % of the demands of fonts stored in the PXL format.

A driver must at least be able to process fonts in the PK format, the support of the GF format is highly recommended. The PXL format is—due to its space requirements and its lack of device dependent widths—not as important as the other two formats, but a high quality driver should also support it because many old drivers use it and their fonts can be used in this way. If one of the two formats GF or PXL cannot be used conversion programs to the PK format should be part of the driver delivery. High quality DVI drivers may add another capability: the usage of fonts which reside in the device itself.

5.1.2 The Name of a Font File

It can be assumed that every operating system where a DVI driver can run allows to organize files hierarchically. We can regard such a hierarchy as a directed graph with filled nodes. A node contains files and other nodes that are at a hierarchically lower level.

The full name of a font file consists of the name of the node in which the file is stored and the file name itself. Most often, these parts are concatenated with a delimiter in between. It is very usual that file names are treated as a composition of two parts, connected by a dot: the name and the extension. These syntactical elements must be restricted in their length to achieve exchangeability between many systems; the names of the nodes and the name part of the file name must have at most eight characters, file extensions must be limited to three characters [3, p. 89].

These restrictions—which are necessary to get a uniform naming convention on many different computer systems—have a strong impact on the organization of the whole bunch of font files. The fonts come along in different magnifications, magnified fonts are often used as a (bad) replacement for nonexisting sizes of the requested type.

• The name of the font file must contain its type name. Its extension can indicate the font file format. But this indication should only be of relevance for the human, DVI drivers must look at the magic numbers inside the font file to decide if this file represents a font and to determine the format of the font representation. Since the extension must have at most three characters it is not possible to include the coding of an arbitrary magnification in it.

• The fonts with the same magnification should be collected in one node at the lowest level of the font file hierarchy. The name of this node must represent the magnification since it cannot be included in the file names.

• All fonts in all magnifcations for one output device should be clustered in one node at the next higher level in the font file hierarchy. If the fonts are generated by the node that represents all fonts for one device should be named with the identifier of the mode parameter (shortened to eight characters).

This proposed structure of the font file allows the developers to handle different fonts for different devices on different computer systems in the same way.

System administrators have to install the driver—during this installation process the most time will be spent by copying the fonts. An estimation of this time and a specification of the needed disk space must be found in the documentation to allow scheduling the administrator’s work. The font file names will be fixed but the other parts of the full file name can be subject to change.

• At least it must be allowed to specify the placement of the node that represents all fonts for one device, e.g. by prefixing it or by locating it in a directory structure.

• The names of nodes containing all fonts with the same magnification must contain the magnification of these fonts but high quality drivers should allow to adapt the naming conventions to local circumstances. We propose to allow alternations in two ways:

1. It should be possible to influence the digit representation of the font magnification; at least two representations are widely spread, the scale factor in per mille relative to 200 dpi and the font resolution which can be associated with this magnification.

2. It should be possible to insert the representation of the magnification as of (1), in an arbitrary string to form the node name.

With these provisions it is easy to embed a DVI driver into an existing environment.

Another important point for the system administrator is the ability to share the font files beween computers in a network, which results in reduced consumptions of computer resources and a reduced handling time. A high quality driver should support the file access over networks.

5.1.3 Additional Fonts

The set of fonts delivered with a driver is subject to a future step of standardization. In any case there will be documents which require additional fonts, be it complete new fonts or unusual magnifications of fonts. If TEX is used in a multiuser environment the writer seldom has the opportunity to install these fonts at the place where the complete font set is located. But even if he could he often wishes to distinguish the delivered “standard” fonts from the documentspecific ones, i.e., he wants to store them in a different place.

Every driver must allow to hold documentspecific fonts near by the written document, i.e., to install the magnification nodes of these fonts in the same node where the document is placed. Furthermore high quality drivers will accept a list of nodes in the file hierarchy where fonts are searched. The user should be able to define this node-list either in the command line or via the host system in which the list is associated with a name if the host system supports that kind of string mapping (e.g. the environment variables of UNIX or the logicals of VMS). The name of this list must be device specific because each device will have a different search list. With this capability it is possible to install fonts that are used by a team or only by one person and to have enough flexibility for the management of documents.

5.1.4 Missing Fonts

But, what if a font file cannot be found? First it must be guaranteed that a correct magnification value has been used; incorrect magnifications can be introduced due to the fact that they are partly represented as integers in per mille. If this can be assured replacement fonts should be looked for.

Every driver must replace nonexistent fonts at least with an unmagnified font of the device—of course, the same type should be used. High quality drivers will also look for other magnifications to choose a font which comes closest to that the user has wanted. If still no font can be found the TFM files (normally used by TEX only) may serve as a source for informaton about the dimensions of these font’s characters, so that an appropriate space can be left. All this should be done in the spirit of “don’t cancel the output—the writer wants to see as much as is available.”

We strongly recommend not to scale bitimage characters to the desired size within the driver. Either the document is important, then the desired font should be created by . Or it is a document for which this small work is still too much, then another font can be chosen.

5.2 Typesetting Is At Least Setting Types

The quality of the output must not be determined by the driver. The user of a driver expects that the output is as accurate as the device can do it and that equivalent results are received on other computer systems and other devices (with respect to different resolutions and deficiencies in the printing engines). The program DVItype [5] claims to create the correct output and that every DVI driver must not differ in its positioning results. Therefore DVItype shall be a kind of “prototype” for each DVI driver and the developer can check his implementation.

To produce satisfying results a font designer can decide to choose for a character an other device dependent width than the equivalent of the device independent width. E.g., the device dependent width of ‘m’ in the unmagnified font cmr10 made for the printing engine imagen is one pixel wider than the equivalent of the device independent width in pixels. Therefore the DVI driver must not ignore the device dependent width. The only exception of this fact comes along with the usage of substituted fonts: the device dependent widths are wrong (because it’s an other magnification) but the device independent widths can be scaled to the desired magnification and can be used as the width of the respective character. Please note, that this implies a necessary change in DVItype because the usage of fonts in the GF or PK format must be supported that include this information.

The differences between device dependent and device independent widths result in different positions in the ‘device raster’ and the ‘device independent (DVI) raster.’ Furthermore differences are established due to rounding errors, as explained in DVItype. These differences must be adjusted at defined places and must not be allowed to diverge beyond a given limit. Both situations are covered in DVItype—and the treatment of both is not completely satisfying.

1. The adjustment of the horizontal difference should only occur between words, so that the distances between characters in one word are not altered. A similar policy should be used for the adjustment of the vertical differences, they should disappear only between lines. This will lead to the same vertical position of the character’s baselines in one line even if a fraction is inserted in it. Therefore we have to identify the place where a word ends and we have to distinguish the dividing space between two lines from a vertical movement within a line.

• It is a typesetting standard that words are divided by approximately 1/_{3} quad. This may vary usually by ^{1}/_{9} quad, bigger differences are seldom used. Therefore a right movement of 0.2 quad or above can be considered as the dividing space between two words. The same amount must not be taken for left movements, because TEX does relatively wide left movements to position accents above characters. The relevant characters are the small ones, capitals are only used at the beginning of a word. An acceptable limit is 0.9 quad, no non-capitals are beyond this limit.

• Baselines are approximately 1.2 quad apart, 0.8 quad seems to be a suitable limit for leaving the line area.

The difference to DVItype is not the method but the values. Especially the limit for the left movement is too small in DVItype, it doesn’t cover all non-capitals.

2. Version 2.6 of DVItype introduces the concept of a “maximal drift” to limit the difference between the device position and the DVI position: if a maximal difference is exceeded the device position is corrected. The problem with the realization of this concept is twofold:

(a) The maximal difference max drift is expressed as a fixed dimension, i.e. its current value is two pixels (for a standard device with 300 dpi, originally 200 dpi). If the same value will be used for another device with a different resolution the correction of the device positions will be done at different DVI positions—resulting in a different output that is gone beyond the difference caused by the different rasters. Therefore we propose to choose a value in a device dependent unit, e.g. one percent of the resolution’s dpi-value. This value will still be used as a dimension in pixel.

(b) If the device position must be corrected, DVItype does this by a movement of max drift pixels towards the DVI position. This always results in a device position one pixel next to the pixel equivalent of the DVI position, regardless of the resolution. This movement (and also a direct movement to the DVI position) is not satisfactory because it will eventually get too large and will disturb the eye of the reader. We propose to position half-way between the device and the DVI position, i.e. to move ⌈max drift/2⌉ pixels towards the DVI position. For the current value of max drift (two pixels) this doesn’t change the behaviour of DVItype.

6 Implementation

The requirement of similar behaviour is achieved best by drivers derived from the same source. The best known example of such a set of drivers is the driver family by Nelson F. Beebe [3]. Furthermore this simplifies the implementation of a driver for a new device, if the device can be handled similar to one already in the set of supported devices.

In the following section we will distinguish between the host computer and the output device itself. Usually they will be connected by a communication channel. The bandwidth may range from a serial line with rather poor throughput to a very closely coupled system where the device has access to the internal bus of the host and transfers can be made via direct memory access (DMA).

In general one has to distinguish two different types of hardcopy output devices:

• Some need the output as a complete bitmapped page image. In this case a huge amount of data (increasing very rapidly with growing resolution) must be transferred from the controlling host to the output device. This leads in general to serious performance restrictions unless there is a high bandwidth communication channel between the host and the device.

To reduce the size of the bitmap that has to be stored and transmitted one wishes to reduce the size of the buffer used. Unfortunately it is not possible to use the size from the DVI file postamble, that is supposed to give the dimensions for the largest page of the document. But the values do not reflect any parts that were added when TEX composed the page image and included the head and footlines, nor does it contain all overfull lines.

Into this category we also take devices that need the printing information not as a dot matrix, but as a list of vectors that must be painted.

• Other devices can use local memory to store downloaded font sets. This can lead to reasonable throughput e.g. in a workstation environment even when the device is linked to the host by a serial line. This holds only for the current desk top printers with resolutions of 300 dpi. Higher resolutions again require higher throughput unless the patterns of the characters are sent encoded instead of indicating the bit patterns.

There may be differences whether the download of a character may occur at any time, only between pages or only at the very beginning of an output job. Furthermore often the size of downloadable characters is limited and larger characters must be inserted as bitmaps anyway. Also the number of downloadable characters may be limited on a per page or per job base, and these limits may vary when the description of a page grows large, or large graphics images are included.

The movement of the virtual output cursor may be limited, such that output for a page must be sorted in either vertical or also horizontal order. This holds especially for devices that can move their output medium only in one direction and are not capable of storing the contents for a full page in local memory.

For screen previewers another categorization must be made. Vector displays are of limited usability, when single bit addressing capabilities are required to display dot matrices. In current workstations or personal computers the screen image is composed of bitmapped memory regions, even multiple bitplanes are used for colour output or greyscale displays. These bit planes are usually addressable by the controling host, at least at the system level. The main difference in system throughput is, whether there exist special purpose processors (“blitters”) that can move rectangles of these bit planes with high efficiency. This is due to the fact that the character images must be moved to arbitrary bit positions on the screen, but the master processor can address the memory only in 8 bit quantities, or even larger chunks, and thus image lines for each character must be shifted to the proper position before they can be inserted. The blitter processors are designed to handle these shifts internally and can change arbitrary regions.

When the display is not connected to the host’s bus, but through a slow terminal line, one needs local intelligence in the “terminal” to emulate a downloadable device to achieve reasonable throughput if bit images shall be displayed. If this intelligence is absent or not programmable, one has to live with output that cannot show accurate positions, because the proper fonts cannot be used. Such output can only be considered as a preliminary solution and does by no means lead to high quality output.

6.1 Language Issues

The main problems for implementation of a driver family are caused by the need to implement drivers for different devices in a variety of computer architectures and operating systems. To make such a family manageable it is necessary that the “base” implementation language allows modularization. Without software modules the resulting software system becomes too large to maintain or even to compile on small computers.

An implementation for a new device can require basic changes in strategy for some parts of the driver. These can be handled best by replacing certain modules with versions specific to devices or device families. Of course the interface of the module in question must be clearly defined and obeyed by all implementations.

To make it easy to port the driver to a variety of computer systems the language must be available with a reasonable amount of standardization. From the developer’s point of view it is important that the language has a literate programming extension. This will, by the way, make the developer a user of the driver even during implementation and maintenance.

Changes required by different operating systems or architectures can be made using a change file mechanism, as Knuth introduced it with WEB for TEX. This mechanism was first only available for all the “literate programming” language extensions; but it has been implemented recently by a small tool [6] for any base language.

6.2 Host requirements

Due to hardware drawbacks it may be necessary to be able to limit the amount of main memory required for the driver or parts of its internal tables in certain environments (e.g., in the Intel processor line with their 64 KB addressing limitation). Also the number of files usable in parallel may be limited, or the output channel to the device might be of low throughput. On the other hand it may be useful to provide features for operation of the driver in a networking environment, where the font files reside on file servers and the output may be spooled to print servers. At least the driver should be able to access the files over a network when the operating system allows this.

6.3 Device Features

6.3.1 Device “Hardware” Features

Another Pandora’s box opens when you ask for the variety of special features of hardcopy output devices. There exist lots of different concepts for paper handling:

• multiple input stacks,

• single sheet feeders,

• output in different bins or through sorters,

• both sides printing,

• changes of paper sizes and output placement.

And even on dot matrix printers it is almost impossible to find two models that use the same single sheet processing commands.

Not all of these features can be reasonable in each environment. E.g., it is not wise to allow single sheet insertion for an unattended device that is connected to a spool queue. Such features must be disabled for spool operation.

For printer drivers, but even more for preview drivers it is necessary that the driver program clips any parts of the output page that do not fit onto the current page resp. fit into the current output window or the whole screen, if the device does not support clipping by itself.

A time consuming part of device customization is the selection of parameters for the creation of fonts with . This problem cannot be neglected, because especially for new output devices it seems to be very hard to find out how to create satisfactory fonts. Unfortunately it is not sufficient to feed the device resolution into . Other parameters that reflect the appearance of output created by the device must be determined. This becomes even more complicated when a device has a knob to change its printing parameters (e.g. darkness). In this case different software packages might require different positions of the knob to produce optimal results and thus different parameters for are necessary. Similar problems occur if the appearance of output depends on the quality of paper inserted.

6.3.2 Device “Software” Features

The situation is in no case better for the software features. The feature most requested by users is the possibility to integrate graphics into documents. The following formats for graphics are currently found:

• Most printers can handle graphics in bitmap format. But the encoding of the bit image to the printer formats is more or less obscure and by no means generalized. Also the rapidly growing size of bitmap images with increasing resolution makes the usage of this kind of graphic inclusion not very attractive.

• For diagrams etc. the use of vector graphics may be more appropriate.

• The most flexible solution can be achieved by use of a page description language such as PostScript. This offers a broad range of applications.

But one must be aware, that all these extensions lead to non portable documents. One of the main advantages of the TEX DVI output is lost.

For devices with the same font parameters but different bitmap encodings it is possible to integrate a uniform raster image support. This format can be driver family dependent (unless standardized) but allow at least a limited portability of graphics. The format must include the dimensions of the graphic anyway and even preview drivers that use a different resolution can display a frame in the size of the graphic insert to allow checking of correct positions. Additionally the raster can be stored in a compressed format, like the one used in the PK format and thus at least the disk’s storage requirements can be reduced. If the device requires the full bitmap no savings can be achieved for the transfer. But if it supports a special encoding with reduced amount of data the graphic data can be transformed to achieve best throughput.

7 Support of extensions by \special

A driver may allow activation of device specific features through the \special command provided by TEX’s DVI output.

When such extensions are supported by a driver, it is necessary that they are clearly tagged such that other drivers will not attempt to interpret them inadvertedly. The following form for the \special string is recommended:

     <tag>: <action>

The <tag> is supposed to indicate the type of extension. This can resemble driver specific or device specific tags. Each driver may handle more than one tag. Special strings starting with tags that are unknown to the driver must be ignored. A warning message should be issued. To get a uniform handling among different drivers all tags must be registered—the appropriate place for this seems to be TUG. TUG can control that new tags are mnemonic and that their meaning is properly specified.

The <action> entry defines the action that shall be performed. It’s recommended form is

     <function> [ :<parameters> ]

where all legal functions must be specified with the registration of the tag. The entries <tag> and <function> must not be case sensitive. The optional <parameters> section specifies additional information for the function (the delimiting colon is needed to allow parameter lists that start with white space).

To include a picture file myfile.pic in the format described above one may write e.g.

     \special{picfile: include: myfile.pic}

Often \specials are demanded that activate any directive for the driver and document it in the DVI file, e.g.

• page orientation and placement,

• horizontal and vertical offset,

• number of copies,

• sheet feeder input,

• output stacker or sorter selection,

• processing order, and

• colour selection (where appropriate).

But the current DVI file format does not allow \specials to appear outside of pages, i.e., they are only allowed between bop and eop. If one of the above directives is within a page then parts of this page can already be output. Furthermore other pages can be output before, therefore an implementable specification of this \specials will be rather difficult.

For documentation purposes an additional comment tag should be included. This allows to add information about the source and status of the DVI file, which is tied to the file, but not printed in the document.

Also device specific functions can be made available. If a device offers a “local” command language (e.g. PostScript or PreScribe), escapes can be made through the \special mechanism. They must be tagged by the name of the local command language or the device name to avoid misinterpretation by other devices. The required functions may be command for the execution of an immediate local command given in <parameters> or include for copying a local command sequence from a file.

The user should not have to write these \special commands by himself. In most cases it is more appropriate to offer additional command definition files with macros that map logically structured functions to the proper \special sequences. E.g., in the case of graphics inclusion the macro should also take parameters for the desired space for the picture and add all the necessary positioning commands to make the placement of the picture correct.

8 Installation

During the installation of a driver the following actions must be undertaken:

• check the completeness of the distribution,

• setup the programs and customize search paths for the files used,

• enable or disable selectable features, and

• finally contain a test run to make sure that at least the easy things work properly. This test should exercise also all extensions of the driver.

The installation procedure must be described in the manual. If the host computer is a multi user system, the installation part of the manual must be separable. For update versions a replacement installation must be supplied.

9 Conclusion

In this article we have listed the main issues for reliable drivers of high quality. Currently most existing drivers do not meet all points. The distinction between minimal subset of functions and additional features may serve as a measure of quality. It is intended that the discussion of this article will carry on the standardization process [7] and thus finally lead to more conforming drivers which make life easier for everybody who creates, maintains or uses them.

References

[1] Device independent file format. TUGboat, 3(2):14–19, 1982.

[2] Generic font file format. TUGboat, 6(1):8–11, 1985.

[3] Nelson H. F. Beebe. A TEX DVI driver family. In TUG VIII Conference Proceedings, pages 71–113, TEX User Group, 1987.

[4] David R. Fuchs. The format of PXL files. TUGboat, 2(3):8–12, 1981.

[5] David R. Fuchs. The DVItype Processor (Version 2.7). WEB Program, Stanford University, August 1984.

[6] Klaus Guntermann and Wolfgang Rülling. Another approach to multiple changefiles. TUGboat, 7(3):134, 1986.

[7] Robert W. McGaffey. Developing TEX DVI driver standards. In TUG VIII Conference Proceedings, pages 69–70, TEX User Group, 1987.

[8] J. L. Peters and L. L. Trip. A model of software engineering. In Proc. 3rd International Conference on Software Engineering, pages 63–70, Institute of Electrical and Electronics Engineers, New York, 1978.

[9] Tomas Rockicki. Packed (PK) font file format. TUGboat, 6(3):115–120, 1985.