fix duplicated from
http://bugs.ghostscript.com/show_bug.cgi?id=695081#c7  - the palette mismatch part is relevant to this:


diff --git a/gs/devices/gdevxcmp.c b/gs/devices/gdevxcmp.c
index d91e78d..67e4d47 100644
--- a/gs/devices/gdevxcmp.c
+++ b/gs/devices/gdevxcmp.c
@@ -252,6 +252,7 @@ gdev_x_setup_colors(gx_device_X * xdev)
          (xdev->vinfo->class != GrayScale) ? 'C' :     /* Color */
          (xdev->vinfo->colormap_size > 2) ? 'G' :              /* GrayScale */
          'M');         /* MonoChrome */
+    bool palette_mismatch = false;
 
     if (xdev->ghostview) {
         Atom gv_colors = XInternAtom(xdev->dpy, "GHOSTVIEW_COLORS", False);
@@ -281,6 +282,7 @@ gdev_x_setup_colors(gx_device_X * xdev)
             xdev->palette[0] = 'G';
         else if (xdev->palette[0] == 'm')
             xdev->palette[0] = 'M';
+        if (palette != xdev->palette[0]) palette_mismatch = true;
         palette = max(palette, xdev->palette[0]);
     }
 
@@ -431,6 +433,7 @@ grayscale:
         }
 
         /* Allocate the dynamic color table. */
+        if (!xdev->ghostview && !palette_mismatch)
         alloc_dynamic_colors(xdev, xdev->cman.num_rgb -
                              xdev->color_info.dither_grays);
         break;

Please review.

While I was able to duplicate the bug with the current release, and the patch
_did_ get rid of the red in the palette, the colored text along the bottom is
wrong. 'Red', 'Yellow' and 'Pink' are missing, and 'Green' and 'Cyan' are
very dark. I've attached the screen snapshot for what I see with the patched
gdevxcmp.c to the z11 device with .Xdefaults containing:
  Ghostscript*palette: GrayScale
vs what I expect (from the 'display' device with -dDisplayFormat=16#20802)

Created attachment 11330 [details]
colorcir_patched_gdevcmp.png

Created attachment 11331 [details]
colorcir_display_Gray.png

-dDisplayFormat=16#20802

I'm not sure if this is just some limitation of the x11 GrayPalette (such as
only having a certain number of shades of gray), but it looks wrong so I am
rejecting this patch as "incomplete" at best.

(In reply to Ray Johnston from comment #5)
> Created attachment 11331 [details]
> colorcir_display_Gray.png
> 
> -dDisplayFormat=16#20802
> 
> I'm not sure if this is just some limitation of the x11 GrayPalette (such as
> only having a certain number of shades of gray), but it looks wrong so I am
> rejecting this patch as "incomplete" at best.

Thanks for spending the time to look at it. I now see the new X11 output is wrong in that it seems to be allocating/displaying gray shades only using the values of the red channel (hence green/blue/cyan all dark).

I think we have a 2nd bug here. I seem to remember there was a similar bug report about not x11 where only the red channel seems to be used but I can't find the reference (yet).

(In reply to Hin-Tak Leung from comment #6)
...
> Thanks for spending the time to look at it. I now see the new X11 output is
> wrong in that it seems to be allocating/displaying gray shades only using
> the values of the red channel (hence green/blue/cyan all dark).
> 
> I think we have a 2nd bug here. I seem to remember there was a similar bug
> report about not x11 where only the red channel seems to be used but I can't
> find the reference (yet).

I am reading through the xlib programming manual slowly, and indeed it mentions in section 7.8.5 that in a gray colormap, only the red channel is used. The code just has never worked properly even on a gray display with color input (i.e. gs's X11 device on a gray-only X server has always displayed only the red channel).

I'll prepare a batter patch for this 2nd bug.

Created attachment 11680 [details]
fix x gray palette problem

Same patch as in
http://bugs.ghostscript.com/show_bug.cgi?id=695081#c11

There are really two problems with the code - it initialises part of it in gray
(num_component = 1) and starts with a gray ramp, but some of the graphic methods are still in color; and the dynamic color allocation receives data in color
and allocates as such.

So this fix initializes the graphic core properly and makes everything gray according to the graphic core, and repeats the gray index in dynamic color matching and allocation in the X server color allocation.

FWIW, I think the code never worked correctly.

The previous change was incorrect, because disallowing dynamic color only fixes some of the problem; color matching was still happening in color partly in color, and as some part thinks it is in color while some thinks it is in gray, uses only the red component to index into the gray ramp.