Bug 687805 - Should gx_device_copy_color_procs() copy new-style procs?
Summary: Should gx_device_copy_color_procs() copy new-style procs?
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: master
Hardware: All All
: P4 minor
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-18 17:53 UTC by Raph Levien
Modified: 2011-07-16 14:50 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raph Levien 2004-11-18 17:53:41 UTC
In fixing bug 687770, I discovered that gx_device_copy_color_procs() copies over
the old-style procs (map_rgb_color and the like), but not new-style
(encode_color and the like). I patched that locally to gs_make_null_device, but
it's possible the change should go in for all uses of forwarded null devices.
This bug is a reminder to check those other uses to see whether the change would
do harm or good.

Another minor and related code cleanup would be to fix the UMR of the
device_color variable (which is stored in an identically named field in the
image enum) in gx_image_enum_begin. It seems to be uninitialized in the masked
case, then referenced later when evaluating tiles_fit in image_render_mono().
I'm not sure whether a default value of true or false makes more sense.
Comment 1 Michael Vrhel 2011-07-16 14:50:21 UTC
I am going to close this.  Where this operation is used the encode and decode procs are set to forward to the target device and I don't really see any issue with that.