Re: Enhancements: 542629 CMYK tiff driver and687440Support for outputting PDF separations separately

Dan,

Could you please read this attentively :

> >When tiffsep_fill_rectangle_hl_color is being called,
> >the low level color may be not loaded.

You wrote :

> Like all drawing operations, the color information should be set appropriately
> prior to the fill_rectangle_hl_color method being called

fill_rectangle_hl_color uses a high level color, and the high
level color information is set appropriately before it is called.
However YOUR implementation stores a LOW LEVEL COLOR information,
which is NOT set before fill_rectangle_hl_color is called.

> >It will store an undefined or a random low level color.

Igor.



----- Original Message ----- 
From: "Dan Coby" <[email protected]>
To: "Igor V. Melichev" <[email protected]>; "Gs-Code-Review" <[email protected]>
Sent: Friday, June 18, 2004 5:07 AM
Subject: RE: [gs-code-review] Enhancements: 542629 CMYK tiff driver and687440Support for outputting PDF separations
separately (xefitra)


>
> Igor,
>
> >> >> /* tiffsep device: Generate individual TIFF gray files for each separation. */
> >> >
> >> >What is "each" : any one from the document, or any one from SeparationNames, or both ?
> >>
> >> Both are possible.  The SeparationOrder device parameter can be used to
> >> select which separations are output.  If it is not specified then separations
> >> are created for both the process color model colorants (CMYK) and the spot
> >> colors.  The spot colors can be specified explicitly via the SeparationColorNames
> >> device parameter or the device will automatically detect spot colors if the
> >> MaxSeparations device parameter is specified.
> >
> >Please add to gs/doc/ .
>
> That information was already covered within previous comments.
>
>
> >> >Since it handles low level colors,
> >> >update_spot_equivalent_cmyk_colors shouldn't call here.
> >> >Don't define tiffsep_fill_rectangle_hl_color.
> >>
> >> If tiffsep_fill_rectangle_hl_color was not present then it would be possible
> >> to miss determining the equivalent CMYK color for a spot color which was
> >> only used inside a rectfill.  Since I commonly use the rectfill operator
> >> for creating test files, I am very sure that this routine is necessary.
> >> Please also note that all five of the high level object drawing routines
> >> are implemented for this same reason.  Each consists of the call to
> >> update_spot_equivalent_cmyk_colors followed by a call to the default
> >> handler for the routine.
> >>
> >tiffsep handles low level colors, right ?
>
> The equivalent CMYK color for a spot color is determined based upon information
> inside of the color space.  It uses the alternate tint transform from a
> Separation or a DeviceN color space.
>
> >Thus it must not store high level colors.
>
> There should be no reason why any device cannot use the color space information
> in the high level drawing routines.
>
> >When tiffsep_fill_rectangle_hl_color is being called,
> >the low level color may be not loaded.
> >It will store an undefined or a random low level color.
>
> Like all drawing operations, the color information should be set appropriately
> prior to the fill_rectangle_hl_color method being called.  Since this is a high
> level drawing routine, only the high level color information needs to be set.
> If the high level color information is not set then any device which tried to use
> this information would have problems.  If this information is not set then the
> logic behind the fill_rectangle_hl_color needs to be changed.
>
> >Instead doing that, tiffsep must use the default implementation,
> >which just return 'undefined', which informs the graphics library
> >that the device doesn't handle high level colors.
> >After receiving it, the graphics library provides correct low level colors.
> >Before receiving it, low level colors may be undefined.
>
> The tiffsep_fill_rectangle_hl_color routine is using the default
> fill_rectangle_hl_color routine.  For the purposes of the tiffsep device, the
> details of how the default routine works are not important.
>
>
> >> >Hmm, what happens if CMYK separations are not specified at all ?
> >> >Is pdev->devn_params.num_std_colorant_names equal to zero in this case ?
> >>
> >> The number of standard colorant names is determined by the process color
> >> model for the device.  For the tiffsep device this is 4 (CMYK).  By
> >> using the SeparationOrder device parameter, it is possible to select
> >> which colorants are written into separation files.  The list of colorants
> >> specified via SeparationOrder may include any/all/none of the CMYK
> >> colorants.  However this has no effect upon the value in the
> >> num_std_colorant_names field.
> >
> >IMO whenever the answer appears 3 times longer than the question,
> >the code to be commented with the answer.
>
> In general, I am a big believer in extensively commenting source files.
> However in this case the comments in gdevdevn.h already state that
> num_std_colorant_names specifies the number of names for the process color
> model.  I have no idea why you decided that the comment was not true.
> Please give me a reason for your belief.
>
> I will add a comment to this section that the tiffsep device is using a
> process color model with 4 (CMYK) standard colorants.
>
>
> Dan
>
> -----Original Message-----
> From: Igor V. Melichev [mailto:[email protected]]
> Sent: Thursday, June 17, 2004 12:30 AM
> To: [email protected]; Gs-Code-Review
> Subject: Re: [gs-code-review] Enhancements: 542629 CMYK tiff driver
> and687440Support for outputting PDF separations separately
>
>
> Dan,
>
> > >> /* tiffsep device: Generate individual TIFF gray files for each separation. */
> > >
> > >What is "each" : any one from the document, or any one from SeparationNames, or both ?
> >
> > Both are possible.  The SeparationOrder device parameter can be used to
> > select which separations are output.  If it is not specified then separations
> > are created for both the process color model colorants (CMYK) and the spot
> > colors.  The spot colors can be specified explicitly via the SeparationColorNames
> > device parameter or the device will automatically detect spot colors if the
> > MaxSeparations device parameter is specified.
>
> Please add to gs/doc/ .
>
> > >Since it handles low level colors,
> > >update_spot_equivalent_cmyk_colors shouldn't call here.
> > >Don't define tiffsep_fill_rectangle_hl_color.
> >
> > If tiffsep_fill_rectangle_hl_color was not present then it would be possible
> > to miss determining the equivalent CMYK color for a spot color which was
> > only used inside a rectfill.  Since I commonly use the rectfill operator
> > for creating test files, I am very sure that this routine is necessary.
> > Please also note that all five of the high level object drawing routines
> > are implemented for this same reason.  Each consists of the call to
> > update_spot_equivalent_cmyk_colors followed by a call to the default
> > handler for the routine.
> >
>
> tiffsep handles low level colors, right ?
> Thus it must not store high level colors.
> When tiffsep_fill_rectangle_hl_color is being called,
> the low level color may be not loaded.
> It will store an undefined or a random low level color.
> Instead doing that, tiffsep must use the default implementation,
> which just return 'undefined', which informs the graphics library
> that the device doesn't handle high level colors.
> After receiving it, the graphics library provides correct low level colors.
> Before receiving it, low level colors may be undefined.
>
> > Having a common routine also means that each
> > device must have common features.
>
> IMO this sentence isn't true.
> There exist a default implementation and specific implementations.
> Specific implementations may have or may have not some common features.
> Also the default implementation may have or may have not some common features
> with any or some specific implementations.
>
> Factoring out a big portion of code from various implementation
> (either default or specific) one simplifies the understanding and
> the further maintenance of the code. Copy-n-replace works against that.
> I noticed that a big portion of code, which uses various arbitrary assumptions,
> has been duplicated in several modules, which do not form a
> logical group. Due to the absence of mutual referenced comments,
> the number of arbitrary assumptions appears to be multiplied with
> the number of modules.
>
> When I request factoring out a common code, my main intention
> is to collect the arbitrary assumptions in a single place,
> so that a maintainer can easy find all them.
> The code style used in those modules appears exactly contrary to that.
>
> > I did create common routines
> > which are used for the get_params/put_params routines.  As a result, I have
> > had to make changes in the spotcmy, devicen, psdrgb, and psdcmyk devices
> > even when the changes were not really needed by all of these device.
>
> This only means that the common routines were not properly parameterized.
>
> > >Hmm, what happens if CMYK separations are not specified at all ?
> > >Is pdev->devn_params.num_std_colorant_names equal to zero in this case ?
> >
> > The number of standard colorant names is determined by the process color
> > model for the device.  For the tiffsep device this is 4 (CMYK).  By
> > using the SeparationOrder device parameter, it is possible to select
> > which colorants are written into separation files.  The list of colorants
> > specified via SeparationOrder may include any/all/none of the CMYK
> > colorants.  However this has no effect upon the value in the
> > num_std_colorant_names field.
>
> IMO whenever the answer appears 3 times longer than the question,
> the code to be commented with the answer.
>
> Igor.
>
> ----- Original Message ----- 
> From: "Dan Coby" <[email protected]>
> To: "Gs-Code-Review" <[email protected]>
> Sent: Thursday, June 17, 2004 7:41 AM
> Subject: FW: [gs-code-review] Enhancements: 542629 CMYK tiff driver and687440Support for outputting PDF separations
> separately
>
>
> >
> > Igor,
> >
> > >> The tiffsep device also prints the names of any spot colors
> > >...
> > >> Ghostscript passes.
> > >>
> > >
> > >This should be added to gs/doc/ .
> >
> > Okay.
> >
> >
> > >> This device creates multiple output files.
> > >> ...
> > >
> > >Reaching this place of the text, everybody have forgotten,
> > >which device is "this". Please replace :
> > >
> > >    The tiffsep device creates multiple output files.
> > >    ...
> >
> > I evidently have a little more faith in our readers but I will make
> > this change.
> >
> >
> > >> This device creates multiple output files.  The file specified
> > >...
> > >> the OutputFile parameter.
> > >
> > >This should be added to gs/doc/ .
> >
> > Okay.
> >
> >
> > >> +<dd>Produces a tiffgray output for each separation plus it also creates a tiff32nc
> > >> +file that contains a composite CMYK image. It can handle up to 8 separations. The
> > >> +device can produce a maximum of eight separations per pass.  For more than eight
> > >> +separations, use the SeparationColorNames and SeparationOrder device parameters to
> > >> +select groups of up to eight separations. The device will automatically recognize
> > >> +up to four spot colors if <b><tt>-dMaxSeparations=8</tt></b> is specified on the
> > >> +command line.
> > >
> > >This short message would be fine for News.htm,
> > >but IMO it is unsatisfactory for Devices.htm, which must contain a clear instruction
> > >for users. I strongly recommend to copy the extended explanation from the log message.
> >
> > I have already agreed to extending the documentation in doc/Devices.htm.
> >
> >
> > >> File names for the separations for the
> > >> CMYK planes are created by appending '.Cyan.tif', '.Magenta.tif'
> > >> '.Yellow.tif' or '.Black.tif' to the to the end of the file name
> > >> specified via the OutputFile parameter.
> > >
> > >Did you test it with OutputFile=%d, which is supposed to create
> > >individual files per page ?
> >
> > Yes.
> >
> >
> > >> /* tiffsep device: Generate individual TIFF gray files for each separation. */
> > >
> > >What is "each" : any one from the document, or any one from SeparationNames, or both ?
> >
> > Both are possible.  The SeparationOrder device parameter can be used to
> > select which separations are output.  If it is not specified then separations
> > are created for both the process color model colorants (CMYK) and the spot
> > colors.  The spot colors can be specified explicitly via the SeparationColorNames
> > device parameter or the device will automatically detect spot colors if the
> > MaxSeparations device parameter is specified.
> >
> >
> > >> * Thanks to Alan Barclay <[email protected]> for donating the original
> > >
> > >Do we have a permission to publicize his personal data ?
> >
> > That comment came from the src/gdevtfnx.c source file.  This device predates
> > my tenure at Artifex.  Since that file has existed for many years I assume that
> > we have permission to mention his name.  I doubt that the comment would have
> > been placed there if Peter did not have approval from Alan.  Obviously Peter
> > would have removed the comment if there had been any complaint from Alan.  Since
> > the src/gdevtsep.c module uses both some actual code from src/gdevtfnx.c and
> > definitely some of the ideas from that module, I thought that it was appropriate
> > to also copy the acknowledgement to Alan.
> >
> >
> > >> /*
> > >>  * PSD device with CMYK process color model and spot color support.
> > >>  */
> > >
> > >Do you mean tiffsep device ?
> >
> > Comment changed.
> >
> >
> > >Since it handles low level colors,
> > >update_spot_equivalent_cmyk_colors shouldn't call here.
> > >Don't define tiffsep_fill_rectangle_hl_color.
> >
> > If tiffsep_fill_rectangle_hl_color was not present then it would be possible
> > to miss determining the equivalent CMYK color for a spot color which was
> > only used inside a rectfill.  Since I commonly use the rectfill operator
> > for creating test files, I am very sure that this routine is necessary.
> > Please also note that all five of the high level object drawing routines
> > are implemented for this same reason.  Each consists of the call to
> > update_spot_equivalent_cmyk_colors followed by a call to the default
> > handler for the routine.
> >
> >
> > >> tiffsep_get_color_comp_index
> > >
> > >Have you got a strong need to copy-n-replace
> > >this huge code for each device ?
> > >If not, please provide a public default implementation,
> > >at least for the common part of all variants.
> >
> > I have debated this issue.  Having a common routine also means that each
> > device must have common features.  This may not be desired in all cases.
> > For now, I would prefer the flexibility of having separate copies of this
> > routine.  I would consider changing this in the future if having separate
> > routines proves to be a maintenance problem.  I did create common routines
> > which are used for the get_params/put_params routines.  As a result, I have
> > had to make changes in the spotcmy, devicen, psdrgb, and psdcmyk devices
> > even when the changes were not really needed by all of these device.
> >
> >
> > >>         if (sep_num < pdev->devn_params.num_std_colorant_names) {
> > >>      switch (sep_num) {
> > >>   case 0: cmyk_map[comp_num].c = frac_1; break;
> > >>   case 1: cmyk_map[comp_num].m = frac_1; break;
> > >>   case 2: cmyk_map[comp_num].y = frac_1; break;
> > >>   case 3: cmyk_map[comp_num].k = frac_1; break;
> > >>      }
> > >>  }
> > >
> > >Hmm, what happens if CMYK separations are not specified at all ?
> > >Is pdev->devn_params.num_std_colorant_names equal to zero in this case ?
> >
> > The number of standard colorant names is determined by the process color
> > model for the device.  For the tiffsep device this is 4 (CMYK).  By
> > using the SeparationOrder device parameter, it is possible to select
> > which colorants are written into separation files.  The list of colorants
> > specified via SeparationOrder may include any/all/none of the CMYK
> > colorants.  However this has no effect upon the value in the
> > num_std_colorant_names field.
> >
> >
> > >Where one can find an explanation ?
> >
> > The description for the num_std_colorant_names field is in the
> > src/gdevdevn.h header file.  This header file contains the description for
> > all of the fields in the gs_devn_params structure.
> >
> >
> > >> build_cmyk_raster_line
> > >[...]
> > >> cyan /= frac_1;
> > >
> > >I'm unclear about the precision of this division,
> > >when the value comes from capture_spot_equivalent_cmyk_colors.
> > >Likely the division gives either 0 or 1.
> >
> > No, the result will not be either 0 or 1.  The value that is in the
> > 'cyan' variable at the time of the division is the sum of the equivalent
> > cyan contribution from each of the colorants.  The contribution for
> > each colorant is calculated based upon the product of the value from
> > capture_spot_equivalent_cmyk_colors (which is a frac) and the value
> > of the colorant (which is 8 bits for the tiffsep device).  Thus the
> > product can have 23 bits.  Since the tiffsep device can have a maximum
> > of 8 colorants, the sum of the contributions could be 26 bits.  After
> > the division we have 11 bits.  This is clamped to an eight bit value.
> >
> >
> >
> > >> tiffsep_print_page
> > >[...]
> > >> for (y = 0; y < pdev->height; ++y) {
> > >
> > >Doesn't it provide the banding ?
> >
> > The logic is the same as that found in the tiff12nc and tiff24nc devices.
> > I.e. a single tiff band is created for the output data.
> >
> >
> > Dan
> >
> > -----Original Message-----
> > From: Igor V. Melichev [mailto:[email protected]]
> > Sent: Wednesday, June 16, 2004 1:03 AM
> > To: [email protected]; Gs-Code-Review
> > Subject: Re: [gs-code-review] Enhancements: 542629 CMYK tiff driver and
> > 687440Support for outputting PDF separations separately
> >
> >
> > Dan,
> >
> > > The tiffsep device also prints the names of any spot colors
> > > detected within a document to stderr.  (stderr is also use for the
> > > output from the bbox device.)  For each spot color the name of
> > > the color is printed preceded by '%%SeparationName:  '.  This
> > > provides a mechanism for external applications to be informed about
> > > the names of spot colors with a document.
> > >
> > > Due to the 64 bit pixel size limitation, the tiffsep can handle
> > > a maximum of 8 colorants per pass.  However it is possible to
> > > handle more than 8 colorants by doing multiple passes.  For each
> > > pass after the first one, the names of all of the separations need
> > > to be specified via the SeparationColorNames parameter and the
> > > names of the desired separations need to be specified via the
> > > SeparationOrder parameter.  When colorants are selected via the
> > > SeparationOrder parameter, the composite CMYK output contains
> > > the equivalent CMYK data only from the selected colorants.  It is
> > > possible to create an overall CMYK composite for more than 8
> > > colorants by then adding together (via an external application like
> > > imagemagick) the composite CMYK output files from the individual
> > > Ghostscript passes.
> > >
> >
> > This should be added to gs/doc/ .
> >
> > > This device creates multiple output files.
> > > ...
> >
> > Reaching this place of the text, everybody have forgotten,
> > which device is "this". Please replace :
> >
> >     The tiffsep device creates multiple output files.
> >     ...
> >
> > > This device creates multiple output files.  The file specified
> > > via the OutputFile command line parameter is used to contain the
> > > composite CMYK equivalent.  File names for the separations for the
> > > CMYK planes are created by appending '.Cyan.tif', '.Magenta.tif'
> > > '.Yellow.tif' or '.Black.tif' to the to the end of the file name
> > > specified via the OutputFile parameter.  File names for the spot
> > > color separation files are created by appending '.sn.tif' (where n
> > > is the spot color number) to the end of the file name specified via
> > > the OutputFile parameter.
> >
> > This should be added to gs/doc/ .
> >
> > > +<dd>Produces a tiffgray output for each separation plus it also creates a tiff32nc
> > > +file that contains a composite CMYK image. It can handle up to 8 separations. The
> > > +device can produce a maximum of eight separations per pass.  For more than eight
> > > +separations, use the SeparationColorNames and SeparationOrder device parameters to
> > > +select groups of up to eight separations. The device will automatically recognize
> > > +up to four spot colors if <b><tt>-dMaxSeparations=8</tt></b> is specified on the
> > > +command line.
> >
> > This short message would be fine for News.htm,
> > but IMO it is unsatisfactory for Devices.htm, which must contain a clear instruction
> > for users. I strongly recommend to copy the extended explanation from the log message.
> >
> > > File names for the separations for the
> > > CMYK planes are created by appending '.Cyan.tif', '.Magenta.tif'
> > > '.Yellow.tif' or '.Black.tif' to the to the end of the file name
> > > specified via the OutputFile parameter.
> >
> > Did you test it with OutputFile=%d, which is supposed to create
> > individual files per page ?
> >
> > > /* tiffsep device: Generate individual TIFF gray files for each separation. */
> >
> > What is "each" : any one from the document, or any one from SeparationNames, or both ?
> >
> > > * Thanks to Alan Barclay <[email protected]> for donating the original
> >
> > Do we have a permission to publicize his personal data ?
> >
> > > /*
> > >  * PSD device with CMYK process color model and spot color support.
> > >  */
> >
> > Do you mean tiffsep device ?
> >
> > > private int
> > > tiffsep_fill_rectangle_hl_color(gx_device *pdev,
> > >     const gs_fixed_rect *rect,
> > >     const gs_imager_state *pis, const gx_drawing_color *pdcolor,
> > >     const gx_clip_path *pcpath)
> > > {
> > >     tiffsep_device * psdev = (tiffsep_device *)pdev;
> > >
> > >     update_spot_equivalent_cmyk_colors(pdev, pis,
> > >       &psdev->devn_params, &psdev->equiv_cmyk_colors);
> > >     return gx_default_fill_rectangle_hl_color(pdev, rect,
> > >       pis, pdcolor, pcpath);
> > > }
> >
> > Since it handles low level colors,
> > update_spot_equivalent_cmyk_colors shouldn't call here.
> > Don't define tiffsep_fill_rectangle_hl_color.
> >
> > > tiffsep_get_color_comp_index
> >
> > Have you got a strong need to copy-n-replace
> > this huge code for each device ?
> > If not, please provide a public default implementation,
> > at least for the common part of all variants.
> >
> > >         if (sep_num < pdev->devn_params.num_std_colorant_names) {
> > >      switch (sep_num) {
> > >   case 0: cmyk_map[comp_num].c = frac_1; break;
> > >   case 1: cmyk_map[comp_num].m = frac_1; break;
> > >   case 2: cmyk_map[comp_num].y = frac_1; break;
> > >   case 3: cmyk_map[comp_num].k = frac_1; break;
> > >      }
> > >  }
> >
> > Hmm, what happens if CMYK separations are not specified at all ?
> > Is pdev->devn_params.num_std_colorant_names equal to zero in this case ?
> > Where one can find an explanation ?
> >
> > > build_cmyk_raster_line
> > [...]
> > > cyan /= frac_1;
> >
> > I'm unclear about the precision of this division,
> > when the value comes from capture_spot_equivalent_cmyk_colors.
> > Likely the division gives either 0 or 1.
> >
> > > tiffsep_print_page
> > [...]
> > > for (y = 0; y < pdev->height; ++y) {
> >
> > Doesn't it provide the banding ?
> >
> > Igor.
> >
> >
> > ----- Original Message ----- 
> > From: "Dan Coby" <[email protected]>
> > To: "Gs-Code-Review" <[email protected]>
> > Sent: Wednesday, June 16, 2004 8:23 AM
> > Subject: [gs-code-review] Enhancements: 542629 CMYK tiff driver and 687440Support for outputting PDF separations
separately
> >
> >
> > >
> > > This change implements the enhancements described in 542629 CMYK
> > > tiff driver and 687440 Support for outputting PDF separations
> > > separately.  This change implements three devices:  tiffgray
> > > which produces an 8 bit gray output with uncompressed data,
> > > tiff32nc which produces 32 bit CMYK with uncompressed data, and
> > > tiffsep which produces a tiffgray file for each separation
> > > (CMYK and spot colors) and it also produces a CMYK output file
> > > which is created using the CMYK image data plus the spot
> > > colors image data.  The spot colors are converted to CMYK using
> > > the logic in 687431.
> > >
> > > DETAILS:
> > >
> > > This change requires that 687504 be included in the sources.
> > >
> > > The tiffgray and tiff32nc devices are logically similar to the
> > > tiff24nc device except for the use of gray and CMYK process
> > > color models.
> > >
> > > The tiffsep device uses much of the logic which has been created
> > > for the psdcmyk and spotcmyk devices.  These include logic for
> > > implementing the SeparationOrder setpagedevice parameter 687423,
> > > logic for determining an equivalent CMYK color to spot colors
> > > 687431, and automatically detecting spot colors (without requiring
> > > that they be specified via the SeparationColorNames setpagedevice
> > > parameter 687504.
> > >
> > > The tiffsep device also prints the names of any spot colors
> > > detected within a document to stderr.  (stderr is also use for the
> > > output from the bbox device.)  For each spot color the name of
> > > the color is printed preceded by '%%SeparationName:  '.  This
> > > provides a mechanism for external applications to be informed about
> > > the names of spot colors with a document.
> > >
> > > Due to the 64 bit pixel size limitation, the tiffsep can handle
> > > a maximum of 8 colorants per pass.  However it is possible to
> > > handle more than 8 colorants by doing multiple passes.  For each
> > > pass after the first one, the names of all of the separations need
> > > to be specified via the SeparationColorNames parameter and the
> > > names of the desired separations need to be specified via the
> > > SeparationOrder parameter.  When colorants are selected via the
> > > SeparationOrder parameter, the composite CMYK output contains
> > > the equivalent CMYK data only from the selected colorants.  It is
> > > possible to create an overall CMYK composite for more than 8
> > > colorants by then adding together (via an external application like
> > > imagemagick) the composite CMYK output files from the individual
> > > Ghostscript passes.
> > >
> > > Internally each spot color is assigned a spot color number.  These
> > > numbers start with 0 for the first spot color.  The spot color
> > > numbers are assigned in the same order as the names are printed to
> > > stderr (see above).  This order also matches the ordering in the
> > > SeparationColorNames list, if this parameter is specified.  The
> > > spot color numbers are not affected by the SeparationOrder parameter.
> > >
> > > This device creates multiple output files.  The file specified
> > > via the OutputFile command line parameter is used to contain the
> > > composite CMYK equivalent.  File names for the separations for the
> > > CMYK planes are created by appending '.Cyan.tif', '.Magenta.tif'
> > > '.Yellow.tif' or '.Black.tif' to the to the end of the file name
> > > specified via the OutputFile parameter.  File names for the spot
> > > color separation files are created by appending '.sn.tif' (where n
> > > is the spot color number) to the end of the file name specified via
> > > the OutputFile parameter.
> > >
> > > The src/gdevtsep.c source file does have a compile time option for
> > > including/not the '.tif' at the end of the created file name.  It
> > > also has a compile time option for using the name of the spot color
> > > as part of the file name.  However this is not enabled since there
> > > may be conflicts with spot color names (in which Adobe allows almost
> > > anything) and the operating system's conventions on file naming.
> > >
> > > This change consists of the new source module src/gdevtsep.c,
> > > changes to devs.mak for defining the new devices, changes to the
> > > various top level make files for including these devices in their
> > > DEVICE_DEVS definitions, and changes to the documentation files.
> > >
> > >
> > > Dan
> >
> >
> > --------------------------------------------------------------------------------
> >
> >
> > > _______________________________________________
> > > gs-code-review mailing list
> > > [email protected]
> > > http://www.ghostscript.com/mailman/listinfo/gs-code-review
> > >
> >
> > _______________________________________________
> > gs-code-review mailing list
> > [email protected]
> > http://www.ghostscript.com/mailman/listinfo/gs-code-review
> >
>
>
>