RE: Partial fix for Bug 687418 WTS does not workwith bitcmyk driver

Russell,

>I tried testing my patches on other devices.
>The patch I sent to gs-code-review needs some fixes - you can make 
>the gx_default_decode_color go into an infinite loop if comp_bits is
>set incorrectly.  Updated patch attached.

Thanks.


>Another issue I found is that check_device_separable returns 
>immediately if separable_and_linear is already known.  
>Testing with png16m I got GX_CINFO_SEP_LIN.  check_device_separable 
>returned immediately, set_linear_color_bits_mask_shift was no 
>longer called, so the bits/mask/shift were never set.  
>Guaranteed to cause a few regressions.

I want to allow devices to be able to specify their own shift/bits/mask
values.  Thus I do not want to have check_device_separable setting values
in all cases.  The purpose behind check_device_separable is to handle those
cases in which 'separability' is not specified.  If a device specifies
that it is 'separable' then it also needs to set up these values.
Thus we (I will) need to correct the png16m device and any other devices
which already specify that they are 'separable'.


>check_device_separable will mark the epswrite device as separable.  
>Is this correct for a vector device?

Yes.  For high level output it does not matter if this data is set or
not.  For cases of low level output, it is desirable that this data
be specified.


>When I did enable check_device_separable, I got a lot of crashes.
>Attached is my test code
>  gs -dNOPAUSE -dBATCH ctest3.ps
>This iterates through nearly all devices, and writes to stderr some 
>details from color_info and tests encode_color, decode_color and if 
>linear and separable also gx_default_encode_color and 
>gx_default_decode_color.

Yes, there are still problems.  Which is the reason that this logic
is still disabled.  Putting the call to check_device_separable inside
fill_in_procs is causing problems.  One problem with the creation
of the overprint device has been corrected.  There are also problems
with the memory devices calling fill_in_procs with only partially
initialized device structures.  This results in seg faults when the
encode_color routine is called.  I think that the solution is to move
the call to check_device_separable to another location.  Logically
this routine needs to be in either the device creation or device open
logic.  I have been looking at the device open logic.  The default
open routine (gx_default_open_device) seems like a logical choice
but unfortunately many (most) devices do not use this routine either
directly or indirectly.


>This needs my testing patch to src/zcolor.c

Thanks for the test code (both the code in zcolor.c and ctest3.ps).


>Without check-device_separable enabled, some interesting ones are:
>  bjc800: 4 overlapping components, max_color=63, dither_colors=5
>  pjxl: max_color=255, dither_colors=5

Interesting.  I did not know about these two devices.  Do you know
the reason for the incompatibility?

>  devicen: max_color=255 dither_colors=1

I will fix this.  I have to take the blame for this.

>  mswindll: marked as separable and linear but bits/mask/shift 
>     not set.      This device is obsolete.

I will look at this device.



Dan

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Russell Lang
Sent: Monday, May 10, 2004 4:05 AM
To: [email protected]
Subject: Re: [gs-code-review] Partial fix for Bug 687418 WTS does not
workwith bitcmyk driver


Dan,

> Modified Files:
> 	gdevdflt.c 
> Log Message:
> Disable the fix for 687418.  This is causing many errors in the 
regression
> tests.  These need to be investigated.

I tried testing my patches on other devices.
The patch I sent to gs-code-review needs some fixes - you can make 
the gx_default_decode_color go into an infinite loop if comp_bits is
set incorrectly.  Updated patch attached.

Another issue I found is that check_device_separable returns 
immediately if separable_and_linear is already known.  
Testing with png16m I got GX_CINFO_SEP_LIN.  check_device_separable 
returned immediately, set_linear_color_bits_mask_shift was no 
longer called, so the bits/mask/shift were never set.  
Guaranteed to cause a few regressions.

check_device_separable will mark the epswrite device as separable.  
Is this correct for a vector device?

When I did enable check_device_separable, I got a lot of crashes.
Attached is my test code
  gs -dNOPAUSE -dBATCH ctest3.ps
This iterates through nearly all devices, and writes to stderr some 
details from color_info and tests encode_color, decode_color and if 
linear and separable also gx_default_encode_color and 
gx_default_decode_color.

This needs my testing patch to src/zcolor.c

Without check-device_separable enabled, some interesting ones are:
  bjc800: 4 overlapping components, max_color=63, dither_colors=5
  pjxl: max_color=255, dither_colors=5
  devicen: max_color=255 dither_colors=1
  mswindll: marked as separable and linear but bits/mask/shift 
     not set.      This device is obsolete.

Russell



On 7 May 2004 at 22:17, Russell Lang wrote:

> Dan,
> 
> Note that this patch does not change color_info.gray_index,
> which is not set by check_device_separable and so could be
> wrong for some devices.
> 
> This patch also includes some test code in zcolor.c which can (or 
> should) be omitted.  This test code checks whether the encode_color, 
> decode_color, separable_and_linear routines are consistent.  
> 
> 
> LOG MESSAGE:
> Prevent check_device_separable from accepting non-consecutive
> bits as separable and linear.  Modify gx_default_encode_color
> and gx_default_decode_color to work on devices for which
> max_color+1 != comp_bits[i].  Partial fix for bug #687418.  
> 
> DETAILS:
> One example device for which max_color+1 != comp_bits[i] is
> the Windows 16-bit native formats with 5:6:5 bits for RGB.
> This has max_color set to 63 (not 31) to get the best results 
> for green, but this did not work with the default encode_color
> function.
> 
> Russell Lang                   [email protected]
> Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/
> 
> 
> 
> 


Russell Lang                   [email protected]
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/