The production of digital graphic images for high resolution output may be described as process driven. There are a couple of critical points in the process chain; we will attempt to introduce some clarity and understanding to these elements. Graphic designs for print media are a great source of pleasure to create and produce. The digital tools that are now available offer truly extraordinary potentials to the creative muse.

Unfortunately, there are limits. Most of today's sophisticated software will allow an artist to create images that are either cost prohibitive to produce or impossible to image.

There are two primary limiting agents; the desired finished product and the prepress imaging devices.

First, let us address the limits imposed by the final production process, i.e., presses, etc. This is the most commonly encountered of the problems faced by service bureaus.

At imaging time, questions arise about the characteristics of the job. These may include media type (film (if film, whether negative or posive and whether the emulsion side is to be up or down) or RC (resin coated paper)), line screen values and screen angles, such specifications as bleeds, chokes and spreads (commonly referred to as trapping), and dot gain.

The answers to these questions may be obtained from the organization charged with the plate making and press run aspects of the production process. The details of this part of the project should be the first set of specifications obtained; they have heavy influence on the designer's choices of elements and tools to be used to implement the design. The final production may range from a silk screen at 35 lines per inch (lpi) to 150 lpi (or higher), multi-color, high gloss posters. Each imposes restrictions on the designing artist.

Now let us look at the second major limiter, the image production devices.

The primary limit of an imagesetting device is its rated maximum dots per inch (dpi) capability. Common limits range from 2400 to 3600 dpi. Machines at the 2400-2600 range have maximum line screen capabilities of 150 lpi.

Due to the digital nature of the machines currently in use, line screens and angles are limited. Suffice to say that the mathematics of the algorithms of the resident software prohibit certain combinations from occurring. Your service bureau can illuminate this murky fen for you.

Some of the effects these restrictions may impose include inhibiting the possibilities regarding blends, graduated fills, duotone angles, curve flatness and the like.

Although these limitations may prevent one from doing things in a straightforward manner, your service bureau or users group may be able to suggest workarounds that will get you where you want to go.

The main issue here is that the design process is a circle that starts and ends at that final arbiter of quality production, the press. Check with and involve your printer at all stages of the production process; he'll thank you and so will your service bureau. And your productions expenses will show a marked decrease.

Happy spec-ing and

Until next we write . . .

I trust Ms. Stein will forgive one more version of her immortal phrase. I use it by way of introducing a discussion of one of the pitfalls of proofing to a printer different from the one to which the image files will eventually be sent, specifically the unexpected bad fit or reflow of text.

Many times the idea of using a service bureau for output comes after a system investment. A system purchased for local use only may be very satisfactory. Printing to local devices such as Hewlett-Packard non-Postscript printers is quite efficient and sufficient, even ideal for office and industrial use as well as for other relatively low resolution requirements. In time, however, the desire for better quality output often arises. Enter the service bureau. And the implications of open systems. Sending print files is a solution as is sending native application files. Either raises the vexing problems associated with fonts.

If fonts are missing from a customers job, the solution may be simply to have them sent along or the bureau may opt to obtain a copy for permanent residence.

Simple problems such as missing fonts are not nearly as distressing as the problems engendered by device dependent font metrics. This is an arcane term that simply describes the idea that the widths of characters in like named fonts vary according to individual printer characteristics. These variances manifest themselves primarily in text fit and reflow problems when different printers are selected for proofing and final output.

This problem is particularly tedious with multi-page documents such as newletters. The text reflow can echo down through the entire publication and create all kinds of headaches.

Most service bureaus are prisoners of Postscript. This ubiquitous language is the defacto standard for imagesetters. It does have its detractors but nevertheless, it rules the roost.

There are no easy solutions to this problem. We offer the following suggestions and are constantly trying to find simpler ones.

If you create documents in an environment where a non-Postscript printer is used for generating proofs, you can expect text fit and reflow problems.

The best solution is probably to upgrade the local printer to a model which can interpret Postscript level II. This may incur an expense of several hundred dollars. Over time, it is probably the most cost effective. Making proof files using the target service bureau's printer driver (shrinking to fit when large pages are involved) will allow the service bureau to check the final output for possible errors.

The cheapest solution is to simply know the bear is there and avoid him where possible. After local, non-Postscript proofs are checked for accuracy, a printer driver for the target service bureau machine can be invoked. This will cause text reflow and such fit problems as there are to appear. Alterations to this version of the file to restore the documents appearance should be made by that person most familiar with the documents design intent.

A third option is to send the native document to the service bureau for processing. This pre-supposes that the service bureau has an experienced operator and a copy of the application in which the document was created. This will, of course, run up a bill for labor charges. Check well ahead of deadlines if you opt for this approach. A proof cycle might well be in order.

A final word regarding fonts. Be extremely careful to note the exact name of any font you use. Computers are literal creatures and any difference in a name can cause grief.

Until next we write . . .

In the family of graphic arts programs known as "vector editors", there are many tools available for the artist. Some of these tools may have effects not readily apparent. This column will deal with one such tool (or function). It is one that is widely used and which may be the source of many problems at output time.

The artist has a great luxury available that is most useful; it is the "grouping" function. Grouping objects together provides a means of holding the items in a group in a constant positional relationship such that the items can be moved or otherwise acted on without worry as to subsequent alignment problems. Grouping is commonly used in a compound manner, i.e., nested groups.

In use, a number of objects may be constructed, aligned and finally grouped. This group may be cloned and the duplicate changed to reflect a conceptual need. These two groups may then be grouped (nesting) and the process continued to project completion.

All in all, this is a wonderful boon to the artist. The selection of any element in a group allows all elements to be selected. A move of one moves all. One can readily appreciate the utility of this convenience.

Unfortunately, there is an underlying hazard to this function. At output time, things can get sticky, particularly regarding the imagesetting language of choice. It is in the nature of the majority of most high-resolution output devices that the language for the input data stream is expected to be Postscript. Other imagesetting instruction languages have similar limits but are not often encountered.

In order to perhaps shed a little light on why one might encounter output problems, let us consider how an imagesetter constructs an image for final production output onto film or RC paper. The process is inherently mathematical in nature as that is the way in which computers operate. Each part of a page (or other unit of production) must be completely described before the element can be submitted for imaging. The reason for this is that the last calculation made may have an impact on some intermediate calculation. These calculations are done in a sequence and are saved as parts of the ongoing process until all calculations regarding a particular object are finished. Given this constraint, the more complex an object, the greater the number of calculations which must be done to describe the object to the imager. As a group presents itself in this environment as a single object, one can see that the impact on the processing engine can be severe. Often, a complex object may cause out-of-memory errors and the like. A nested group of groups can exacerbate this condition.

As the reader may have surmised by now, this process may result in the inability of the target imagesetter to produce what seems to be a rather simple set of image objects.

Sometimes it seems that the more useful a tool is, the more potential for problems it has. Grouping is one of these; it is great help to the artist and anathema to the imagesetter.

It is a simple matter to resolve this problem and is amenable to a solution of process. The following is offered as one means to minimize this common cause of gray hair.

When a project is completed and the page(s) ready for output, simply make a copy of the document and save it. Using this clone, ungroup all groups and save the result. Using this clone to produce a print file for output will be of great utility to user and service bureau alike.

We hope this is of some assistance to the reader.

Until next we write . . .

Graphic artists have two basic kinds of image editing programs available to them. One is for editing bitmaps and the other is for editing vector based artwork. These are usually referred to as PAINT and DRAW programs.

The PAINT group of software products provides editing capabilities for bitmapped images which range from simple black and white line art images to full color (24 and 32 bit) pictures. All of these kinds of images are made up of discrete elements called pixels. At high resolutions (dots per inch) images of this kind can appear as precisely detailed as photographs. Unfortunately, bitmaps don't change size very well and can be very data intensive. That is, they require large amounts of data to convey picture information.

The DRAW programs use mathematical expressions to describe the elements, such as lines, curves and other geometries, of an image. The mathematical description of a line or curve is called a vector. Vectors are very simple primitives but, in combination, can create extremely complex images. Images of this type can be resized as desired without affecting resolution. And the file sizes are very small in comparison.

When these on-the fly vector editors became available, the impact on the computer-based art community was enormous. Bezier curves, editable nodes, orthogonal snaps and graduated fills became integral parts of the artist's repertoire.

One of the first utilities to become available for this new capability was the tracing function. This useful utility is available in standalone or integrated form. The standalone versions are available from several suppliers; most of the vector editing programs have a trace utility bundled within them. The latest versions allow adjustment of a wide variety of parameters. These include centerline or outline tracing, sensitivity, curve adherence, segment length and a host of other settings.

Tracing utilities are a boon to all who would like to have better control of lineart images. These are often left over from analog processes; i.e., available only as veloxes of various sizes for paste-up. The first means of incorporating these images into computer-based documents was as scanned images. These bit maps were usually logotypes and other such examples of line art.

When tracing utilities such as Steamline and CorelTrace became available, the first targets for conversion to curves were these logos and other simple pieces of line art. Soon, more complex images were being traced into vector form for use in the rapidly improving products such as Illustrator, Freehand and CorelDraw.

And therein lies the rub, to borrow from the Bard. Traces from complex line art images can contain hundreds and even thousands of nodes in individual curve segments. At output time on high resolution imagesetters, these complex curves can create conditions which prevent proper imaging. Partial output or refusal to output any image at all may result. Modifications to the parameters of the tracing utility may prevent many of these problems. Lessening the control sensitivities will create fewer nodes. Some experimentation will provide guidelines in this regard.

Other ways to minimize problems are available in the vector editing programs. Close examination of various parts of the imported trace images will reveal that many nodes can be deleted with little or no loss of image detail.

When all else fails, a complex curve describing, say, a flower, can be broken apart at appropriately selected nodes, the separate sections rejoined as closed curves and the problem alleviated.

As a guideline, curves containing more than one thousand nodes should be edited to have fewer than this suggested node limit.

One further note. Most vector editors allow for the importation of files from CAD programs and the like. Be careful when importing .DXF files and their kin. One of the characteristics of files of this type is that many do not support true curves. Very short line segments are connected to approximate curves. One “curve” may comprise hundreds of such segments. As each segment has a node at each end, one can readily appreciate the problem. Fortunately, the solution is quite simple. Just select the bulk of the nodes on the “curve” and delete them. Most times, the vector editing program will create a true curve in their place and little or no curve editing will be required.

Minimizing node counts in vector art is useful on many counts, particularly when high-resolution imagesetting is desired. Your service bureau will appreciate the assistance.

Until next we write . . .

Copyright© 1995-2002

VirtualDesign.com l.l.c.