***************************************** DIGITAL DAGUERREOTYPES 1.1 AND YOUR FRIENDLY SERVICE BUREAU ***************************************** Thanks to the many PostScript Publishing Service Bureaus around the world, people can create or image sophisticated documents and designs on personal microcomputer systems, and then have them imaged at 1270 dots per inch (500 lines per centimenter), 2540 dots per inch (1000 lines per centimeter), or at even higher resolutions by skilled bureau personnel. The following documentation is intended both for users of Digital Daguerreotypes 1.1 and for owners and staff members at PostScript bureaus who may encounter artwork files in Digital Daguerreotypes format. --------------------- 1. BASIC CONCEPTS --------------------- The Digital Daguerreotypes prologue file DIGIDA.INI or DIGIDA.PS defines a set of PostScript language procedures for such purposes as special text and graphics effects, 3-D coordinate transformations, and so forth. These two versions of the prologue differ only in that DIGIDA.INI includes a built-in exitserver command, while DIGIDA.PS does not. Either version of the prologue has a length of approximately 142,000 bytes, and requires about 225K of free PostScript virtual memory (VM). Digital Daguerreotypes artwork files in .EPD or .PSD format invoke procedures defined in DIGIDA.INI or DIGIDA.PS, as well as built-in PostScript operators and procedures defined within these artwork files themselves. Typically these files have a length of 3K or less, and may describe complex grayscale designs.* Files in .EPD (Encapsulated PostScript Daguerreotypes) format are in fact Encapsulated PostScript format (EPS or EPSF) files importable into various typesetting or page layout applications -- but with the .EPD extension a caution that these files are dependent upon the Digital Daguerreotypes prologue. Apart from this dependence, they are similar to other plain ASCII EPS files without a display header. --------------------- * Some version 1.1 artwork files have a length of 5K or more -- but typically 2K or less of "script" in the usual sense, the bulk taken up by definitions of experimental 3-D routines which I preferred not to place in DIGIDA.INI and DIGIDA.PS at this early stage. For an idea of the level of complexity associated with a "true" 3K artwork file, see ADMIRAL.EPD. -1- Files in .PSD (PostScript Daguerreotypes) format likewise are PostScript files dependent upon the Digital Daguerreotypes prologue, but which might not be intended as importable EPS files, or which possibly exhibit certain anomalies on import which warrant a .PSD as opposed to .EPD extension. For example, a .PSD file, unlike an .EPD file (or EPS file generally), might describe more than one page of output. This discussion should make clear one special risk factor for service bureaus and their customers: the Digital Daguerreotypes prologue MUST be present in VM at the time an .EPD or .PSD file (or document importing such files) is processed -- or a PostScript error of the type undefined will result. --------------------------------- 2. THE CONCATENATION SOLUTION --------------------------------- In some ways, the problems raised by the dependency of Digital Daguerreotypes artwork files on the prologue "library" is analogous to familiar problems with downloadable PostScript fonts. In both cases, an illustration or document is dependent upon code which it does not include. This always raises at least the theoretical risk that the font or prologue might not in fact be present in VM when it is needed. The consequences are more drastic in the case of Digital Daguerreotypes: rather than merely producing some unexpected Courier in place of the missing font, the imagesetter returns an error and stops processing the file. This event could be especially disruptive if it occurs in the middle of processing a long document which happens to include an imported .EPD image. Just as one can avoid the risk of the missing downloadable font by including the font and the document in a single PostScript file, so concatenating the DIGIDA.PS version of the Digital Daguerreotypes prologue with a dependent PostScript file is an obvious way to avoid unexpected PostScript errors. In the case of a "standalone" .EPD or .PSD file -- that is, one not imported into a typesetting or page layout application -- it appears that "crude" concatenation of DIGIDA.PS and the artwork file may be a quick and effective solution. In the MS-DOS operating environment, the following command line would accomplish this crude concatenation (with drives and directory paths being supplied merely for the sake of the example): COPY C:\DIGIDA.PS+C:\EPD\PARK.EPD C:\PARK.PS The resulting self-sufficient PostScript file PARK.PS should image successfully on a PostScript device, and may even import as a self-sufficient EPS file into some applications despite its violation of the Adobe EPSF conventions! -2- ************************************************* ********************************************* VERY IMPORTANT CAUTION!!! If you choose to concatenate the prologue with an .EPD or .PSD artwork file, always use the DIGIDA.PS version of the prologue, NOT the DIGIDA.INI version -- which can disrupt the imaging of the resulting composite PostScript file. ********************************************** ************************************************** CONCATENATION: APPLICATION OUTPUT PRINTED TO DISK If a user is preparing a document including imported .EPD files, then a different concatenation strategy seems effective. First, the user prepares the document in a typesetting or page layout application, importing .EPD files as desired. Then, the user prints the final application output to a PostScript file on disk, and concatenates the DIGIDA.PS prologue with this file. Assuming that the PostScript output file is C:\TEMP01.PS, for example, an MS-DOS user might invoke the command line COPY C:\DIGIDA.PS+C:\TEMP01.PS C:\BUREAU1.PS Again, such a file might deviate for the formal document structuring conventions. However, from the viewpoint of a PostScript language interpreter, it should image successfully. The main advantage of this approach is that the artwork may be imported in the compact .EPD format, meaning faster import times within the application and shorter application document files. Also, only one copy of the DIGIDA.PS code is required for each application PostScript output file to produce a self-sufficient file for imaging. Especially if a single document imports several .EPD files, the economy of this strategy should be clear. MORE DECENT CONCATENATION -- CUTTING AND PASTING Using an ASCII text or program editor which can process files of 140K or longer, and which does not add extraneous control characters or reformat code in undesirable ways, a user or bureau worker can more "decently" combine the DIGIDA.PS version of the prologue with an .EPD artwork file to create a self-sufficient EPS file complying with the Adobe conventions. -3- In the process which follows, we'll "graft" the artwork header and code on to a copy of DIGIDA.PS -- most prudently, after having first copied or renamed both files so as not to change the originals. Again, when combining prologue and artwork into a single file we use always DIGIDA.PS, not DIGIDA.INI. (a) Grafting the EPS Header. --------------------------- Delete the opening one-line header %!PS-Adobe-2.0 from the copied or renamed DIGIDA.PS, and in its place paste the two-line header from the copy of the .EPD file, for example %!PS-Adobe-2.0 EPSF-1.2 %%BoundingBox: 83 480 328 720 in the case of PARK.EPD. These lines include the information necessary for an application to import the file. (b) Merging prologue and artwork code. ------------------------------------- Next, we move to the end of the prologue file to which we've just grafted the EPS header. We find the concluding lines end %%EOF and delete the %%EOF comment, superfluous since this line will no longer mark the end of file. Having deleted this comment, we note the beginning of this now-empty line as the place to paste the artwork code we are about to locate in the copy of the .EPD file. In the copy of the .EPD file, we now search for the first appearance of the line /digidict where and graft the ENTIRE REMAINDER OF THE .EPD FILE STARTING WITH THIS LINE into our modified version of the prologue file at the point where we deleted the end of file comment. Now we have a "self-sufficient" .EPS file which should print by itself or import into a typesetting or page layout application. Incidentally, some .EPD files like PARK.EPD may also have purely discretionary comments, identified by lines starting with a SINGLE percentage sign (%). There's no need to copy such comments into the concatenated file, since they should have no effect on either importing or printing. -4- ADVANTAGES AND DISADVANTAGES OF CONCATENATION Personally I find this concatenation process rather intuitive, especially with Norton Editor -- which possibly implies that it might be anything but intuitive for most typical sane people. Again, this approach is analogous to including a downloadable font as part of a document file -- it makes the file longer, but insures that the font will be there at imaging time. True, DIGIDA.PS is much longer than a typical downloadable font (two or three downloadable font families might be more comparable) -- but here we are avoiding a PostScript error, as opposed merely to some unexpected Courier. ------------------------------------------------- 3. OTHER SOLUTIONS: DIGIDA.INI OR DIGIDA.PS? ------------------------------------------------- The alternative to file concatenation is a reliable arrangement for being sure that DIGIDA.INI or DIGIDA.PS will be present in PostScript VM at the time Digital Daguerreotypes artwork files -- or document importing such files -- are processed. Here it is helpful for the user and the bureau to reach an understanding as to whether DIGIDA.INI (built-in exitserver) or DIGIDA.PS (no exitserver) would be easier for the bureau to manage. Needless to say, the user should communicate very clearly with the bureau, both verbally and on the order form, about which PostScript files may require that the Digital Daguerreotypes prologue be in VM in order to avoid an error condition. Unlike the file concatenation approach, exiting the server loop with DIGIDA.INI or with DIGIDA.PS (plus bureau-supplied code in the latter case) might complicate VM management after the imaging of the relevant files is concluded. As mentioned, DIGIDA.INI or DIGIDA.PS occupies about 225K of VM; given the large numbers of downloadable fonts a bureau might routinely manage, this extra demand could be nontrivial. -5- ***************************************************** IN A NUTSHELL -- SUGGESTIONS FOR CUSTOMERS If you decide to send a bureau .EPD or .PSD files (or documents including such files) separately from the Digital Daguerreotypes prologue: 1. Understand that this solution requires more teamwork and care on the part of you and your bureau. 2. Be EVEN MORE CAREFUL than you would be with a document requiring a downloadable font not included as part of the document itself -- identify each Digital Daguerreotypes artwork file or application-generated file importing such artwork. 3. Ask the bureau to inform you whether they prefer DIGIDA.INI (built-in exitserver) or DIGIDA.PS (no exitserver). 4. Let the bureau know that DIGIDA.PS or DIGIDA.INI requires about 225K of VM. ***************************************************** ------------------------------------------- 4. IMPORTED .EPD FILES: A CLARIFICATION ------------------------------------------- In the discussion above, I have assumed that users of typesetting or page layout applications are importing .EPD files (or concatenated .EPS files created by "grafting" the prologue and artwork code together as described above, pp. 3-4) into a document and then printing the document to disk in PostScript. At this point, one solution is to concatenate DIGIDA.PS with this PostScript print-to-disk document output, test the resulting new file to be sure it images successfully, and then send it to the bureau. Alternatively, the user does not perform this concatenation, but sends the application PostScript output file to the bureau, plus the bureau's choice of DIGIDA.PS or DIGIDA.INI in the case of a document with .EPD files. Some people, however, prefer to send actual application files to bureaus -- not the PostScript output printed to disk, but the file in the format of the given application. In this case, the bureau might attempt to print to the imagesetter directly from the application file. -6- If the application file includes a concatenated .EPS file, this should be no problem. If the application file includes simple .EPD files however, then again the bureau must be sure to install DIGIDA.PS or DIGIDA.INI in VM _before_ attempting to print the document itself. Alternatively, the bureau might itself print the application file to disk in PostScript, and then concatenate DIGIDA.PS with that output before sending the combined file to the imagesetter (the same procedure discussed at p. 3 above). Otherwise a PostScript error of the type undefined would occur -- and the bureau might need to print the application file to disk in order to track down the difficulty. ------------------------------------------------------ 5. FILE COMPLEXITY, IMAGING TIME, AND BUREAU RATES ------------------------------------------------------ Since imagesetters use various Raster Image Processing Systems (RIPS), it is difficult to predict how long a particular piece of Digital Daguerreotypes artwork might take to image. However, experience indicates that the answer in many cases could be a LONG time -- much longer than an average page, or even an average PostScript illustration. This raises the complication that for a bureau, imaging time is money. A bureau's rate schedules presume that a typical page will take, say, three minutes to image -- as opposed to 30 minutes. Imagesetters must place a vast number of dots on a page; thus they may take much longer to image a given .PSD or .EPD file than a desktop system rasterizing to screen, say, at 200 dpi, or even to hard copy at 300 or 360 dpi. For example, SPCUGLGO.EPD took about three minutes to rasterize at 200 dpi to a displayable .PCX file, and maybe five minutes to print at 360 dpi, on a clone 286/287-10 system. However, even with a 50 MHz RIPS, it required 27 minutes to process on an Afga ProSet 9400 imagesetter at 2540 dpi. Digital Daguerreotypes shares an assortment of processor- intensive features with more conventional PostScript art environments: for example, various character path effects. Additionally, such Digital Daguerreotypes features as complex gradient extrusions can easily require hundreds of grayscale layers for a given illustration, increasing imaging time accordingly. -7- Also, invoking the new 3-D coordinate system of version 1.1 adds yet another level of matrix mathematics to the already intricate package of 2-D transformations included in standard PostScript. However, the longest imaging times may be associated not so much with 3-D transformations as with factors such as complex gradient extrusions applied to a number of text and geometric objects -- as in the case of ADMIRAL.EPD, designed before the introduction of the new 3-D system.* Bureaus might have various policies about adjusting rates for uncommonly long imaging times; friendly and informed negotiations seem the best approach. -------------- CONCLUSION -------------- I would not venture to predict the possible range of problems which Digital Daguerreotypes might cause for service bureaus, including the outright bugs or incompatibilities equivalent to bugs which Murphy's Law predicts could be lurking in the code itself. However, I would like to lend my full cooperation to users and bureaus alike who may have occasion to confront these complications. More specifically, I would offer this exhortation to any user considering bringing any Digital Daguerreotypes code within 300 meters of a PostScript service bureau: ****************************************** RUN THE CODE THROUGH A POSTSCRIPT LANGUAGE INTERPRETER AND BE SURE IT PROVOKES NO ERRORS BEFORE YOU ASK A BUREAU TO IMAGE IT. ****************************************** This precaution will not prevent all PostScript errors at the bureau, since some errors are "device-specific," including ones I might not have suspected -- but it is an excellent way of minimizing avoidable aggravations for customer and bureau. ---------------- * While the original version of ADMIRAL.EPD was completed on 19 June 1992, and ran without problem on Freedom of Press, I very fortunately was alerted on 18 September that this file needed a minor revision to avoid an error on standard PostScript devices. Thanks to Larry Clark for this timely observation. -8- As some users apt to write PostScript files themselves will be aware, certain "device-specific" errors on high-resolution imagesetters are also avoidable: applying charpath to only one font character at a time, and "encapsulating" complex objects within a save-restore pair to reclaim VM, are techniques as relevant to Digital Daguerreotypes artwork as elsewhere. Above all, friendship and informed teamwork should help users and bureaus cope with the complications of a new PostScript language design environment. --------------------- TECHNICAL SUPPORT --------------------- Users and service bureaus are warmly invited to write or telephone for technical support: The PC Scriptorium c/o Ms. Margo Schulter 5901 Newman Ct. #6 Sacramento, CA 95819-2626 U.S.A. (916) 457-8935 Please note that this telephone number is not toll-free, although the support itself is free. You may also seek technical support on LaserPub, the International Laser Publishing Conference of FidoNet, a free information service made possible by BBS SysOps around the world. Service bureau operators and personnel often contribute very actively to this conference. -9-