[gs-code-review] Enhancements: 542629 CMYK tiff driver
and687440Support for outputting PDF separations separately
Dan Coby
dan.coby at artifex.com
Fri Jun 18 14:58:23 PDT 2004
Igor,
>Could you please read this attentively :
I have been looking at what you have written. However you are not
paying attention to what I have written.
>> >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.
The only low level color values that are saved are those which are
calculated based upon the alternate tint transform functions for
Separation and DeviceN color spaces. The routines inside of
gsequiv.c force the calculation of the needed low level color
values. There is nothing random about what I am saving.
I do not care about the actual low level values for the current
color when tiffsep_fill_rectangle_hl_color is called. I am only
interested in obtaining equivalent CMYK color values for a 100%
value of each of the spot colors within the file.
Dan
-----Original Message-----
From: Igor V. Melichev [mailto:igor.melichev at artifex.com]
Sent: Friday, June 18, 2004 7:00 AM
To: dan.coby at artifex.com; Gs-Code-Review
Subject: Re: [gs-code-review] Enhancements: 542629 CMYK tiff driver
and687440Support for outputting PDF separations separately (xefitra)
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" <dan.coby at artifex.com>
To: "Igor V. Melichev" <igor.melichev at artifex.com>; "Gs-Code-Review" <gs-code-review at ghostscript.com>
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:igor.melichev at artifex.com]
> Sent: Thursday, June 17, 2004 12:30 AM
> To: dan.coby at artifex.com; 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" <dan.coby at artifex.com>
> To: "Gs-Code-Review" <gs-code-review at ghostscript.com>
> 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 <alan at escribe.co.uk> 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:igor.melichev at artifex.com]
> > Sent: Wednesday, June 16, 2004 1:03 AM
> > To: dan.coby at artifex.com; 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 <alan at escribe.co.uk> 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" <dan.coby at artifex.com>
> > To: "Gs-Code-Review" <gs-code-review at ghostscript.com>
> > 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
> > > gs-code-review at ghostscript.com
> > > http://www.ghostscript.com/mailman/listinfo/gs-code-review
> > >
> >
> > _______________________________________________
> > gs-code-review mailing list
> > gs-code-review at ghostscript.com
> > http://www.ghostscript.com/mailman/listinfo/gs-code-review
> >
>
>
>
More information about the gs-code-review
mailing list