1 /* Copyright (C) 2002 Aladdin Enterprises. All rights reserved. 2 3 This software is provided AS-IS with no warranty, either express or 4 implied. 5 6 This software is distributed under license and may not be copied, 7 modified or distributed except as expressly authorized under the terms 8 of the license contained in the file LICENSE in this distribution. 9 10 For more information about licensing, please refer to 11 http://www.ghostscript.com/licensing/. For information on 12 commercial licensing, go to http://www.artifex.com/licensing/ or 13 contact Artifex Software, Inc., 101 Lucas Valley Road #110, 14 San Rafael, CA 94903, U.S.A., +1(415)492-9861. 15 */ 16 17 /* $Id: gsovrc.h,v 1.4 2004/09/22 00:37:12 dan Exp $ */ 18 /* overprint/overprint mode compositor interface */ 19 20 #ifndef gsovrc_INCLUDED 21 # define gsovrc_INCLUDED 22 23 #include "gsstype.h" 24 #include "gxcomp.h" 25 26 /* 27 * Overprint compositor. 28 * 29 * The overprint and overprint mode capability allow drawing operations 30 * to affect a subset of the set of color model components, rather than 31 * all components. The overprint feature allows the set of affected 32 * components to be determined by the color space, but independently of 33 * the drawing color. Overprint mode allows both the color space and 34 * drawing color to determine which components are affected. 35 * 36 * The significance of the overprint feature for a device is dependent on 37 * the extent of rendering that is to be performed for that device: 38 * 39 * 1. High level devices, such as the PDFWrite and PSWrite devices, 40 * do not, in principle, require the graphic library to convert 41 * between color spaces and color models. These devices can accept 42 * color space descriptions, so conversion to a color model can be 43 * left to whatever application uses the generated file. 44 * 45 * For these devices, overprint and overprint mode are just 46 * additional state parameters that are incorporated into the output 47 * file, which may or may not be supported on the eventual target 48 * application. 49 * 50 * Note that the current implementation of PDFWrite and PSWrite 51 * do require the graphic library to convert between color spaces 52 * and a color model, for all objects except images. To implement 53 * the overprint feature under this design, the devices would 54 * have to support the get_bits_rectangle method, which means they 55 * would need to function as low-level devices. Since that defeats 56 * the purpose of having a high-level device, for the time being 57 * overprint and overprint mode are not fully supported for the 58 * PDFWrite and PSWrite devices. 59 * 60 * 2. Low level devices require the graphic library to convert between 61 * color spaces and color models, and perform actual rendering. For 62 * these devices both overprint and overprint mode require a form 63 * of mixing of the drawing color with any existing output. This 64 * mixing is mechanically similar to that required for transparency 65 * or raster op support, but differs from these because it affects 66 * different color components differently (transparency and raster 67 * operations are applied uniformly to all color components). 68 * 69 * Because the implementation of overprint for high level devices is 70 * either trivial or essentially impossible (short of dealing with them 71 * as low level devices), the discussion below is restricted to the 72 * implementation for low level devices. 73 * 74 * In principle, the effects of overprint and overprint mode are 75 * modified by changes to the current color, the current color space, 76 * and the process color model. 77 * 78 * In most situation, the process color model cannot be changed without 79 * discarding any existing graphic output, so within a given page this 80 * affect may be ignored. An exception arises when emulating features 81 * such as the "overprint preview" mode of Acrobat 5.0. This mode uses 82 * a "fully dynamic" color model: any named color component is consider 83 * to exist in the process color model (its conversion to a "real" color 84 * is determined by the tint transform function associated with its 85 * initial invocation). In this situation, the process color model may 86 * "monotonically increase" as a page is processed. Since any such 87 * change is associated with a change of color space, we need not be 88 * concerned with independent changes in the process color model. 89 * 90 * For typical graphic operations such as line drawing or area filling, 91 * both the current color and the current color space remain constant. 92 * Overprint and overprint mode are significant for these operations 93 * only if the output page contained data prior to the operation. If 94 * this is not the case, overprint is irrelevant, as the initial state 95 * of any retained color components, and the state of these components 96 * in the drawing color, will be the same. 97 * 98 * Aside from the devices that generate output, Ghostscript makes use 99 * of two additional types of the devices for rendering. Forwarding 100 * devices do not generate output of their own; they merely forward 101 * rendering commands to a target device. Accumulating devices render 102 * output to a special buffer (often part of clipping or a caching 103 * operation), which is subsequently sent to the primary output device 104 * in a lower-level form. 105 * 106 * It is conceivable that a forwarding device could be dependent on the 107 * overprint feature (e.g.: an "inking" filter to determine how much 108 * of each colorant is required in each area of the output), but this 109 * is unlikely and, in practice, never seems to arise (in practice, 110 * inking filters scan the fully generated output). Hence, we ignore 111 * this possibility, and need not be concerned with overprint when 112 * installing or removing forwarding devices. 113 * 114 * Overprint is of interest to accumulating devices only if these 115 * devices either begin operation with a non-empty output buffer, or if 116 * the current color or color space can change during the lifetime of 117 * an instantiation of the device. Most instantiations of accumulating 118 * devices live only for the rendering of a single graphic object, for 119 * which neither the color or color space can change. There are a few 120 * exceptions: 121 * 122 * - Though images and shaded fills are single graphic objects, they 123 * involve (potentially) many colors. Conveniently, overprint mode 124 * does not apply to either images or shaded fills, so these cause 125 * no difficulty. For the same reason PatternType 2 patterns do 126 * not cause difficulty, though it is necessary to create/update 127 * the overprint compositor to reflect the colorspace included 128 * in the shading dictionary. 129 * 130 * - The gs_pdf14_device, which implements the PDF 1.4 transparency 131 * facilities, is an accumulating device that supports only 132 * the high-level rendering methods (fill_path, etc.). Actual 133 * rendering is done with a separate marking device, an instance 134 * of which is created for each graphic object rendered. The 135 * marking device renders into the output buffer of the 136 * gs_pdf14_device, which contains the results of prior rendering 137 * operations. Thus, overprint is significant to the marking 138 * device. The interaction of transparency and overprint are, 139 * however, more complex than can be captured by a simple 140 * compositor. The gs_pdf14_device and the corresponding device 141 * (will) implement overprint and overprint mode directly. These 142 * devices discard attempts to build an overprint compositor. 143 * 144 * - The most essential exception involves colored tiling patterns. 145 * Both the color and color space may change multiple times 146 * during the rendering of a colored pattern. If a colored 147 * pattern is cached, an accurate implementation would require 148 * the cache to included compositor creation instructions. 149 * This is not possible in the current Ghostscript pattern 150 * cache (which has other problems independent of overprint). 151 * The best that can be done is to keep the overprint compositor 152 * current during the caching operation itself. For single level 153 * patterns, this will allow the tile instance to be rendered 154 * accurately, even if the tile does not properly overprint 155 * the output raster. 156 * 157 * Based on this reasoning, we can limit application of the overprint 158 * compositor to a small numer of situations: 159 * 160 * 1. When the overprint or overprint mode parameter of the current 161 * graphic state is changed (the overprint mode parameter is 162 * ignored if overprint is set to false). 163 * 164 * 2. When the current color space changes, if overprint is set to true 165 * (the colorspace cannot be relevant if the overprint is false). 166 * There are a few exceptions to this rule for uncolored caches 167 * (user paths, FontType 3 fonts) and anti-alias super-sampling. 168 * 169 * 3. If the current device color changes, if overprint is true and 170 * overprint mode is 1. 171 * 172 * 4. If the device in the graphic state is changed, or if this device is 173 * reopened after having been closed (e.g.: due to the action of 174 * put_params), if the overprint parameter is set to true. 175 * 176 * 5. During grestore or setgstate (because the overprint/overprint 177 * mode parameters might change without the current device changing). 178 * 179 * 6. When creating the pattern accumulator device, if overprint is 180 * set to true. 181 * 182 * In PostScript and PDF, a change of the color space always has an 183 * associated change of the current color, so it is possible to 184 * exclude color space changes from the list above. We do not do this, 185 * however, because changes in the color space are usually less frequent 186 * than changes in the current color, and the latter are only significant 187 * if overprint mode is 1. 188 * 189 * Unlike the other compositors used by Ghostscript (the alpha-channel 190 * compositor and the implemented but not used raster operation 191 * compositor), once created, the overprint compositor is made part of the 192 * current graphic state, and assumes the lifetime and open/close 193 * status of the device to which it is applied. In effect, the device to 194 * which the compositor is applied will, for purposes of the graphic 195 * state, cease to exist as as independent item. The only way to discard 196 * the compositor is to change the current device. 197 * 198 * Subsequent invocations of create_compositor will not create a new 199 * compositor. Rather, they change the parameters of the existing 200 * compositor device. The compositor functions with only a small 201 * performance penalty if overprint is disabled, so there is no reason 202 * to discard the compositor if oveprint is turned off. 203 * 204 * The compositor device will emulate the open/close state of the device 205 * to which it is applied. This is accomplished by forwarding all open 206 * and close requests. In addition, the compositor device will check the 207 * status of the device to which it is applied after each put_params call, 208 * and will change its own status to reflect this status. The underlying 209 * device is required to close itself if an invocation of put_params 210 * changes in the process color model. 211 * 212 * NB: It is not possible, without an excessive performance delay, for 213 * the compositor to detect all cases in which the device to which 214 * it is applied may close itself due to an error condition. We 215 * believe this will never cause difficulty in practice, as the 216 * closing of a device is not itself used as an error indication. 217 */ 218 219 #ifndef gs_overprint_params_t_DEFINED 220 # define gs_overprint_params_t_DEFINED 221 typedef struct gs_overprint_params_s gs_overprint_params_t; 222 #endif 223 224 struct gs_overprint_params_s { 225 226 /* 227 * Are any component values to be retained? 228 * 229 * If this is false (overprint off), all other fields in the compositor 230 * are ignored, and the compositor does nothing with respect to rendering 231 * (it doesn't even impose a performance penalty). 232 * 233 * If this field is true, the retain_spot_comps and potentially the 234 * retained_comps fields should be initialized. 235 * 236 * Note that this field may be false even if overprint is true. This 237 * would be the case if the current color space was a Separation color 238 * space with the component "All". 239 */ 240 bool retain_any_comps; 241 242 /* 243 * Are spot (non-process) color component values retained? 244 * 245 * If overprint is true, this field will be true for all color spaces 246 * other than Separation/DeviceN color spaces. 247 * 248 * The overprint compositor will itself determine what constitutes a 249 * process color. This is done by using the color space mapping 250 * routines for the target device for all three standard device 251 * color spaces (DeviceGray, DeviceRGB, and DeviceCMYK) and the 252 * set of all possible colors with individual components either 0 253 * or 1. Any color model component which is mapped to 0 for all of 254 * these cases is considered a spot color. 255 * 256 * If this field is true, the drawn_comps field (see below) is ignored. 257 * 258 * NB: This field should not be used if the DeviceCMYK color space 259 * is being used with a DeviceCMYK color model (which may have 260 * additional spot colors). Such a color model must explicitly 261 * list the set of drawn components, so as to support overprint 262 * mode. 263 */ 264 bool retain_spot_comps; 265 266 /* 267 * The list of color model compoents to be retained (i.e.: that are 268 * not affected by drawing operations). The field is bit-encoded; 269 * the bit corresponding to component i is (1 << i). This bit will be 270 * 1 if the corresponding component is set from the drawing color, 0 if 271 * it is to be left unaffected. 272 */ 273 gx_color_index drawn_comps; 274 }; 275 276 /* 277 * The overprint compositor structure. This is exactly analogous to other 278 * compositor structures, consisting of a the compositor common elements 279 * and the overprint-specific parameters. 280 */ 281 typedef struct gs_overprint_s { 282 gs_composite_common; 283 gs_overprint_params_t params; 284 } gs_overprint_t; 285 286 /* 287 * In a modest violation of good coding practice, the gs_composite_common 288 * fields are "known" to be simple (contain no pointers to garbage 289 * collected memory), and we also know the gs_overprint_params_t structure 290 * to be simple, so we just create a trivial structure descriptor for the 291 * entire gs_overprint_s structure. 292 */ 293 #define private_st_gs_overprint_t() /* In gsovrc.c */\ 294 gs_private_st_simple(st_overprint, gs_overprint_t, "gs_overprint_t"); 295 296 297 298 /* some elementary macros for manipulating drawn_comps */ 299 #define gs_overprint_set_drawn_comp(drawn_comps, i) \ 300 ((drawn_comps) |= (gx_color_index)1 << (i)) 301 302 #define gs_overprint_clear_drawn_comp(drawn_comps, i) \ 303 ((drawn_comps) &= ~((gx_color_index)1 << 1)) 304 305 #define gs_overprint_clear_all_drawn_comps(drawn_comps) \ 306 ((drawn_comps) = 0) 307 308 #define gs_overprint_get_drawn_comp(drawn_comps, i) \ 309 (((drawn_comps) & ((gx_color_index)1 << (i))) != 0) 310 311 312 /* 313 * In the unlikely event that the overprint parameters will ever be 314 * allocated on the heap, we provide GC structure descriptors for 315 * them. 316 */ 317 extern_st(st_overprint_params); 318 319 #define public_st_overprint_params_t /* in gsovrc.c */ \ 320 gs_public_st_simple( st_overprint_params, \ 321 gs_overprint_params_t, \ 322 "gs_overprint_params_t" ) 323 324 325 /* create an overprint composition object */ 326 extern int gs_create_overprint( 327 gs_composite_t ** ppct, 328 const gs_overprint_params_t * pparams, 329 gs_memory_t * mem ); 330 331 /* verify that a compositor is the overprint compositor */ 332 extern bool gs_is_overprint_compositor(const gs_composite_t * pct); 333 334 #endif /* gsovrc_INCLUDED */ 335