Re: [Groff] Bug? with color

[Rick Richardson]

On Sun, Dec 30, 2001 at 08:07:36AM -0600, Rick Richardson wrote:
> 
> Attached is an example that shows an apparent bug with color.
> Run the example with:
> 
>       groff -t -man xxx.1 > xxx.ps && ps2pdf xxx.ps && acroread xxx.pdf
> 
> The example as attached will work.  But if you change the place
> where it says "red2" to "red", then the word comes out black
> instead of red.

There is another bug with color, somewhat related to the above.

If a sequence something like this is fed into grops from troff...

        DF ##00000000ffff
        V26400
        H72000
        DP 0 -12000 6000 0 0 12000 -6000 0
        DF ##000000000000
        DF ##00000000ffff
        h6000
        DP 0 -12000 6000 0 0 12000 -6000 0
        DF ##000000000000
        DF ##00000000ffff
        h6000
        DP 0 -12000 6000 0 0 12000 -6000 0
        DF ##000000000000
        DF ##00000000ffff
        h6000
        DP 0 -12000 6000 0 0 12000 -6000 0
        DF ##000000000000
        DF ##ffff00000000
        h6000
        DP 0 -12000 6000 0 0 12000 -6000 0
        DF ##000000000000
        DF ##ffff00000000
        h6000
        DP 0 -12000 6000 0 0 12000 -6000 0
        DF ##000000000000
        DF ##ffff00000000
        h6000
        DP 0 -12000 6000 0 0 12000 -6000 0

 ...then grops will fail to change the fill color in the generated
Postscript from blue to red.

I'm not sure what the exact problem is, but the code that is failing is
this from ps_printer::fill_path() ...

  else {
    if (output_color->is_equal(fill_color))
      out.put_symbol("fill");
    else {
      set_color(fill_color, 0);
      out.put_symbol("FC");
    }
  }

As a workaround, forcing that fragment to always generate the "FC"
symbol by disabling the is_equal optimization fixes this second
problem.  However, it doesn't fix my original complaint.  There, the
problem is that grops isn't generating a "CO" symbol when it needs to.

-Rick