The DCS Image File Format The Desktop Color Separation (DCS) image file format, which contains both a low resolution preview and the information necessary for a separation of the image, is a picture format definition for electronic color separations that can significantly reduce the expense of producing color publications. The ability of DCS to manage the entire color separation process on desktop reduces production time, and the use of DCS can be implemented without purchasing additional, specialized equipment. Two types of programs use the DCS format: DCS producers and DCS consumers. DCS producers are applications that produce color separations from color images. DCS consumers are desktop publishing and page layout applications capable of driving an output device. Many applications that create color separations have a recordkeeping function that maintains a connection between the document being created and the high resolution files used for printing. A DCS producer application provides information to a DCS consumer (such as a page layout program) in a ÒmainÓ file about the location of high resolution separation files. When the document is color separated, a DCS consumer application will locate and use the high resolution files. WhatÕs new in DCS 2.0? ¥ The option to choose a multiple- or single-file version. DCS originally required that the separation files be separate. With DCS 2.0, these files may now be combined into one. ¥ The ability to specify additional plate colors. DCS 2.0 can point to spot color plates in addition to the standard cyan, magenta, yellow, and black. ¥ The addition of the %%PlateFile comment. This comment adds the ability to choose single or multiple files, as well as the ability to specify additional plate colors. An in-depth look at DCS files DCS is a specification involving one or more files. The first and potentially only file (referred to here as the ÒmainÓ file) contains comments that give the file names and locations for the separations of the original image. Construction of the ÒmainÓ file The ÒmainÓ file should be an EPS picture, and should follow all the guidelines listed in Appendices G and H of the PostScript Language Reference Manual, 2nd ed., with the exception of some changes in the header comment area as described in this document. This ÒmainÓ file should contain additional comments referring to DCS information. DCS information is represented by PostScript header comments, which appear before %%EndComments (these DCS comments are used by the DCS consumer to locate the separation files and download them for the appropriate plate). Composite EPS images The ÒmainÓ file must contain a composite representation of the original image. Typically, this composite image will be used when proofing to a color printer; it should be full resolution to facilitate the highest quality proof possible. If the composite is not present, a DCS consumer will represent the image in an unpredictable form. Screen representations The separation files contain information for the separated plates only (that is, the cyan file should contain information pertaining only to the cyan plate). These separation files should not contain the %%PlateFile comment (described below). Since the separation files are not used for composite proofing or screen representation, the low resolution screen preview and color composite image should be omitted. Dot gain compensation The ÒmainÓ file may also need to contain the %%SuppressDotGainCompensation comment. If this comment is not present, some applications will download a transfer function to correct for the nonlinear grayscale rendering characteristics of the output device before sending the EPS file. If your application is building a file that has dot gain compensation built-in, you should include this comment. However, if you do so, your EPS file should also set up the screen angle, frequency, and dot function, rather than relying on the values active at the time your PostScript file is run. This comment must appear in the ÒmainÓ file before the comments specifying location of color plates. Font information The ÒmainÓ file should include the %%DocumentFonts comment to indicate all the fonts used in the separation files. It is the responsibility of the DCS consumer to guarantee that every font used by the separation files is available on the printer. The %%PlateFile comment DCS 2.0 uses the %%PlateFile comment to specify the location of a particular color separation file. This comment has two different forms, depending on whether the separation files are saved as multiple files or a single file. The %%PlateFile comment Ñ Multiple-file version Separation plate information can be contained in files separate from the ÒmainÓ file. A common form of DCS uses the four process separation colors. You are not limited to the four process colors Ñ any number of spot colors may be specified. To use this form, include the following comment in the ÒmainÓ file: %%PlateFile: (color name) filetype location filename colorname The colorname represents the name of the spot or process color the file represents. The name should be enclosed in parentheses. For example, (Cyan), (Magenta), (TRUMATCH 1-a5), etc. filetype The filetype represents the file format of the separation file (EPS). The filetype field can be something other than (EPS) if the location field is something other than Local. location The location can be Local or some other keyword. However, the only keyword supported by QuarkXPress is Local. Refer to Appendix B of the DCS 2.0 specifications (available from Quark) for further discussion of location. filename The filename identifies the file that contains the separation for the specified color. It may be a complete pathname or just the filename itself. The DCS consumer should search for the specified file. For example, QuarkXPressª will search the directory that contains the DCS ÒmainÓ file. Some filenames may not be valid on all platforms. Example %%PlateFile: (PANTONE 184 CV) EPS Local HD:tstpicture.09 The %%PlateFile comment Ñ Single-file version The single-file version of the %%PlateFile comment allows the use of DCS with one file. The beginning of this file is structured identically to the ÒmainÓ file. After the header information and composite EPS information, the separation information is simply included, rather than being split into separate files. The %%PlateFile comment is modified to reflect the presence of the separation information. The key difference between the multiple-file version and the single-file version is the third field of %%PlateFile . If this field begins with the # character, the file is a single-file version of DCS. %%PlateFile: (color name) filetype #offset size colorname The colorname represents the name of the spot or process color the separation represents. The name should be enclosed in parentheses. For example, (Cyan), (Magenta), (TRUMATCH 1-a5), etc. filetype The filetype represents the file format of the separation (normally EPS). #offset The # character as the first character in the third field area indicates a single-file version. In this case, the third field is interpreted as an offset from the beginning of the file to the separation. size The size field represents the size of the separation in number of bytes. Both the offset and size fields are represented by decimal numbers. Example %%PlateFile: (Yellow) EPS #84777 24621 Notes ¥ A DCS file must be either a single-file version or a multiple-file version. Do not combine the versions within one DCS file. ¥ The DCS consumer will download only separation files with corresponding %%PlateFile comments. If there is no %%PlateFile: (Cyan)... comment, for example, the DCS consumer will not download any cyan information for this separation. ¥ In the single-file format, the size of the main segment of the file (including header, DCS comments, and composite image) can be determined by finding the smallest #offset. Common problems There are a number of misconceptions about EPS and DCS files that you should be aware of when you are creating your own separations. Some of these misconceptions have been discussed in the Adobe PostScript manuals, AdobeÕs Colophon, or in the EPS documentation. Others have never been explicitly mentioned before. 1. Do not assume you can use as many dictionary entries as you want. You probably are limited to only a few (especially if you have used PostScript within the document to add entries). Instead, create a local dictionary. 2. Do not assume anything about the clip path. If you must clip, append your clip path to the current clip path. 3. Do not assume anything about the current scale, translation, or orientation of the EPS picture. 4. Do not perform any transformations on the coordinate system that make assumptions about the paper size. QuarkXPress supports arbitrary sizes. 5. Use of the ÒsettransferÓ operator should be avoided if at all possible. 6. Unless you absolutely must, do not change the screen frequency, angle, or procedure. 7. DCS files should not contain %%PlateColor comments! 8. The first line of the separation file should start with %!PS-Adobe... and should end with %%Trailer so that parsers can detect the whole separation file. (When a DCS consumer outputs the separation files, it should enclose the files with %%BeginDocument:.. and %%EndDocument.) 9. Limit the number of characters used in the header comments to 255 (for backward compatibility on some existing parsers). If a line contains more than 255 characters, split it into multiple lines and begin each continuation with the %%+ convention. Appendix A The Original Desktop Color Separation (DCS 1.0) DCS originally relied on two sets of comments being present in the ÒmainÓ file. Since many DCS producers will continue to produce separations that comply with the original specification, it is important that DCS consumers continue to understand the conventions used in such separations. %%DocumentProcessColors In some situations, one or more of the separation files are not used. If a photograph contains no cyan, an empty cyan file will be generated by the DCS producer application. By specifying that this file is empty, a DCS consumer can avoid wasting time and money printing an unneeded plate. Specify the EPS separation files to be used with the line: %%DocumentProcessColors: cyan magenta yellow black Any of the four colors cyan, magenta, yellow, or black specified in this line will be printed during the final output. Location of the Color Separation Files A standard PostScript file contains a header segment that finishes with %%EndComments. In a DCS-compatible file, this header segment contains four additional lines that specify the location of the color separation files. These lines must appear after the %%BoundingBox comment and before the %%EndComments line. The following lines are used to specify the location of the color separation files. The order of cyan, magenta, yellow, and black is not important: %%CyanPlate: location of an EPS file representing the cyan plate. %%MagentaPlate: location of an EPS file representing the magenta plate. %%YellowPlate: location of an EPS file representing the yellow plate. %%BlackPlate: location of an EPS file representing the black plate. These file names should be complete path names, including the root drive specification. This provides the DCS consumer application with the names of the files to use when separating. If the location of these files changes, the DCS consumer application must be able to locate them. Appendix B Special note regarding the location keyword and multiple-file DCS There are two states that can exist in the location keyword: Local and anything else. Treatment of these two states must be handled differently by the DCS consumer. A DCS consumer application must provide a mechanism to indicate whether the non-local states should be ignored or considered. The following examples refer to an Òexternal file systemÓ. This term refers to a file server capable of interpreting the location keyword. Since the DCS consumer will handle the location keyword differently depending on whether an external file system is present or not, a mechanism must tell the DCS consumer whether such a system is present. In the case of QuarkXPress, a flag in the Printer Description File (PDF) indicates whether an external file system exists. Variations in the location keyword depending on whether an external file system exists If the header contains only Local platefiles: In the following code segment, only the local keyword is used. The presence or absence of an external file system is ignored. The DCS consumer should make an attempt to locate and download the separation file on the local file system. If the consumer is unable to locate the separation file, the composite EPS file should be incorporated in its place. %!PS-Adobe-2.0 EPSF-1.2 %%Creator: QuarkXPress(R) 3.2 %%Title: Document1 (Page 1) %%CreationDate: 7/6/93 6:14 PM %%DocumentProcessColors: Cyan Magenta Black %%DocumentCustomColors: (TRUMATCH 1-a5) %%CMYKCustomColor: 0 .9 .4 .3 (TRUMATCH 1-a5) %%DocumentFonts: Helvetica %%DocumentData: Binary %%LanguageLevel: 1 %%BoundingBox: 0 0 612 792 %%PlateFile: (Black) EPS Local a0.K %%PlateFile: (Cyan) EPS Local a0.C %%PlateFile: (Magenta) EPS Local a0.M %%PlateFile: (TRUMATCH 1-a5) EPS Local a0.9 %%EndComments If the header contains Local and non-Local platefiles: If an external file system is present This DCS file would cause the DCS consumer to use only the header portion of the DCS main file. It would not send any local EPS files, and any line that contains the Local keyword would be ignored. Note that each color has two non-local representations (ÒNewServeÓ and ÒUnixRipÓ). This clearly shows that the DCS interpreter must be able to recognize its unique keyword before it assumes that the following pathname is valid. If no external file system is present For any lines that use the Local keyword, the DCS consumer should make an attempt to locate and download the separation file on the local file system. If the consumer is unable to locate the separation file, the composite EPS file should be incorporated in its place. The lines containing non-Local keywords should be ignored. %!PS-Adobe-2.0 EPSF-1.2 %%Creator: QuarkXPress(R) 3.2 %%Title: Document1 (Page 1) %%CreationDate: 7/6/93 6:14 PM %%DocumentProcessColors: Cyan Magenta Black %%DocumentCustomColors: (TRUMATCH 1-a5) %%CMYKCustomColor: 0 .9 .4 .3 (TRUMATCH 1-a5) %%DocumentFonts: Helvetica %%DocumentData: Binary %%LanguageLevel: 1 %%BoundingBox: 0 0 612 792 %%PlateFile: (Black) EPS Local a0.K %%PlateFile: (Black) TIFF NewServe c:\scans\job045\a0K.scn %%PlateFile: (Black) JPEG UnixRip /usr/jonah/job3/a0_black %%PlateFile: (Cyan) EPS Local a0.C %%PlateFile: (Cyan) TIFF NewServe c:\scans\job045\a0C.scn %%PlateFile: (Cyan) JPEG UnixRip /usr/jonah/job3/a0_Cyan %%PlateFile: (Magenta) EPS Local a0.M %%PlateFile: (Magenta) TIFF NewServe c:\scans\job045\a0M.scn %%PlateFile: (Magenta) JPEG UnixRip /usr/jonah/job3/a0_Magenta %%PlateFile: (TRUMATCH 1-a5) EPS Local a0.9 %%PlateFile: (TRUMATCH 1-a5) TIFF NewServe c:\scans\job045\a0_09.scn %%PlateFile: (TRUMATCH 1-a5) JPEG UnixRip /usr/jonah/job3/a0_TRUM_1-A5 %%EndComments Notes ¥ A DCS file must be either a single-file version or a multiple-file version. Do not combine the versions within one DCS file. ¥ The DCS consumer will download only separation files that have corresponding %%PlateFile comments. If there is no %%PlateFile: (Cyan)... comment, for example, the DCS consumer will not download any cyan information for this separation.