FW: [gs-code-review] Revision to 687504 Enhancement: Imaging
spotcolors without using the SeparationColorNames parameter.
Dan Coby
dan.coby at artifex.com
Wed Jun 16 20:40:12 PDT 2004
Igor,
>> Log message:
>[...]
>> This commit only implements this feature on the psdcmyk device.
>
>Why it changes "devicen" ?
The log message has been changed to include the spotcmyk and devicen devices.
>> /*
>> * If we have SeparationOrder specified then the number of components
>> - * is given by the number of names in the list. Otherwise the number
>> - * of ProcessColorModel components and SeparationColorNames is used.
>> + * is given by the number of names in the list. Otherwise check if
>> + * the MaxSeparations parameter has specified a value. If so then use
>> + * that value, otherwise use the number of ProcessColorModel components
>> + * plus the number of SeparationColorNames is used.
>> */
>
>Against possible user's confusions,
>I recommend to print a warning and return an error on the conflict.
No. The reason for the different possible numbers of device components is
due to the fact that there are three things that can affect the number of
device colorants. It is desirable to keep all three methods. An error
message would effectively disable either the SeparationColornames, the
SeparationOrder, or the MaxSeparation device parameters. Any/all/none of
these three may be specified.
>Also I don't like that this comment appears twice.
>I would make a function wrapping it.
Okay.
>> + /*
>> + * The given name does not match any of our current components or
>> + * separations. If this is a separation name and we have room
>> + * for it then add it to our list of separations.
>> + */
>
>Does this come from Adobe specs ?
>If not, it's another source of user's confusions.
>I'd print a warning and return error.
The entire reason for adding this feature is to automatically recognize when
a new spot color is found when running a file. Previously the user was required
to specify all spot colors using the SeparationColorNames device parameter.
This feature makes that optional. Adobe does automatically recognize spot
colors within both Distiller and Acrobat.
>Also I'm unclear what happens when !(we have room) :
>is it just ignored ? Why ?
If we have already reached the maximum number of spot colors allowed then
we do not add more. The result is that the spot color will be processed using
the alternate tint transform specified in the Separation or DeviceN color space.
This is the same operation that occurred previously if a spot color was not
specified via the SeparationColorNames device parameter.
>> /*
>> + Define the options for the component_type parameter to get_color_comp_index
>> + routines. Note: This information is currently being used by the routines
>> + for identifying when they are being given a separation name. Some devices
>> + automaticaly add separations to the device's components if the separation
>> + is not previously known and there is room in the device.
>> +*/
>
>See above.
I do not understand your comment.
>> + automaticaly
>
>Microsoft spell checker reports a misprint : "automatically".
Corrected.
Dan
-----Original Message-----
From: Igor V. Melichev [mailto:igor.melichev at artifex.com]
Sent: Wednesday, June 16, 2004 12:00 AM
To: dan.coby at artifex.com; Gs-Code-Review
Subject: Re: [gs-code-review] Revision to 687504 Enhancement: Imaging
spotcolors without using the SeparationColorNames parameter.
Dan,
> Log message:
[...]
> This commit only implements this feature on the psdcmyk device.
Why it changes "devicen" ?
> /*
> * If we have SeparationOrder specified then the number of components
> - * is given by the number of names in the list. Otherwise the number
> - * of ProcessColorModel components and SeparationColorNames is used.
> + * is given by the number of names in the list. Otherwise check if
> + * the MaxSeparations parameter has specified a value. If so then use
> + * that value, otherwise use the number of ProcessColorModel components
> + * plus the number of SeparationColorNames is used.
> */
Against possible user's confusions,
I recommend to print a warning and return an error on the conflict.
Also I don't like that this comment appears twice.
I would make a function wrapping it.
> + /*
> + * The given name does not match any of our current components or
> + * separations. If this is a separation name and we have room
> + * for it then add it to our list of separations.
> + */
Does this come from Adobe specs ?
If not, it's another source of user's confusions.
I'd print a warning and return error.
Also I'm unclear what happens when !(we have room) :
is it just ignored ? Why ?
> /*
> + Define the options for the component_type parameter to get_color_comp_index
> + routines. Note: This information is currently being used by the routines
> + for identifying when they are being given a separation name. Some devices
> + automaticaly add separations to the device's components if the separation
> + is not previously known and there is room in the device.
> +*/
See above.
> + automaticaly
Microsoft spell checker reports a misprint : "automatically".
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] Revision to 687504 Enhancement: Imaging spotcolors without using the SeparationColorNames
parameter.
>
> This is a revision to the enhancement 687504. Note: The previous
> email on this item had a typo which reported the bug number as
> 687594.
>
> This revision changes the handling to the SeparationColorNames
> parameter. Storage for spot color names is now allocated and the
> color name copied into the newly allocated storage. Previously
> a pointer to the original name in the parameter memory was used.
> However this created a conflict with the structure enumeration
> for names which was previously added for this feature.
>
>
> Log message:
>
> 687504 Enhancement: Imaging spot colors without using the
> SeparationColorNames parameter.
>
> DETAILS:
>
> The purpose of this enhancement is to provide an example of how
> to implement imaging spot colors without requiring that they be
> specified in advance via the SeparationColorNames setpagedevice
> parameter. Note: Spot colors are only supported on a few devices
> which have output file formats which allow for spot colors. These
> are currently the psdcmyk, spotcmyk, and xcfcmyk devices.
>
> This commit only implements this feature on the psdcmyk device.
>
> In order to implement this feature, a device needs to be able to
> allocate image buffer memory for each colorant and to detect when
> a new colorant is being used inside of a color space. The
> implementation has the following pieces:
>
> 1. The handling of the MaxSeparation setpagedevice parameter was
> extended. Previously this parameter was always set to one. For
> most devices it now indicates the number of colorants being used
> by the device. For most devices this is a fixed quantity, however
> for the psdcmyk device, this parameter can be used to tell the
> device to allocate image buffer memory for up to eight colorants.
> (The eight colorant limit is due to the fact that the psdcmyk
> device uses 8 bits per colorant and we currently have a 64 bit
> maximum pixel size.)
>
> 2. The devices already have a 'get_color_comp_index' routine which
> is used to query if a colorant is supported by the device. However
> this routine is used for both real components in color spaces and also
> for some special cases. For instance, the same halftone may be used
> either for a cyan or a red colorant. To handle this case, the halftoning
> setup logic will query the get_color_comp_index routine to check if
> cyan is supported by the device. If not then a query is made to see
> if the device supports red. By monitoring the names of the components
> passed to get_color_comp_index routine, a device can detect when a new spot
> color is being used. However it is necessary to be able to detect
> the special cases so that the device does not believe that it has a
> 'red' spot color. To do this the third parameter of the
> get_color_comp_index device proc was logically modified to indicate
> if a name represents a name actually in a color space or one of the
> special case situations. Previously this parameter was not being used.
>
> 3. The get_color_comp_index routine for the psdcmyk device was
> modified to look for new spot colors and to add then to its list of
> colorants if there was space available. Note: This also required
> that the psdcmyk device have its own structure descriptor, pointer
> enumeration and relocation procedures. The macro which was used to
> define the psdcmyk and psdrgb devices needed to be changed since the
> previous macro used the st_device_printer structure descriptor instead
> of the new structure descriptor for the psd devices.
>
>
> Dan
--------------------------------------------------------------------------------
> _______________________________________________
> 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