groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Bug? with color


From: Rick Richardson
Subject: Re: [Groff] Bug? with color
Date: Mon, 31 Dec 2001 11:48:14 -0600
User-agent: Mutt/1.2.5i

On Mon, Dec 31, 2001 at 12:31:18AM -0600, Rick Richardson wrote:
> 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.
> 
>  ...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.

There is a third problem, related to the second problem.  This time
I think it has to do with not setting the color after a restore
of the previous color.  Once again, I think some "is_equal" check
is failing to determine that the color needs to be changed.

I have attached some pretty nasty troff that will exhibit both the
second and the third problems.  This troff was generated by a
C function I wrote to dump colored curses screenshots, and there is no
attempt yet to optimize its output.  The third problem is manifested
in the test by the colored bars on the right side of the screen.
They should all be black.  If you manually insert a \m[black]
just before the right side vertical bar is produced, nothing
will change.  However, if you instead insert a \m[grey1] there,
then that will trick grops into generating a color change.

-Rick

-- 
Rick Richardson  address@hidden        http://home.mn.rr.com/richardsons/
Stock information at your fingertips:   http://linuxtrade.0catch.com/

/* DVD decryption algorithm, tatooable version                             */
/* $ cat title-key scrambled.vob | efdtt >clear.vob      by Charles Hannum */
#define m(i)(x[i]^s[i+84])<<
unsigned char x[5],y,s[2048];main(n){for(read(0,x,5);read(0,s,n=2048);write(1,s
,n))if(s[y=s[13]%8+20]/16%4==1){int i=m(1)17^256+m(0)8,k=m(2)0,j=m(4)17^m(3)9^k
*2-k%8^8,a=0,c=26;for(s[y]-=16;--c;j*=2)a=a*2^i&1,i=i/2^j&1<<24;for(j=127;++j<n
;c=c>y)c+=y=i^i/8^i>>4^i>>12,i=i>>8^y<<17,a^=a>>14,y=a^a*8^a<<6,a=a>>8^y<<9,k=s
[j],k="7Wo~'G_\216"[k&7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/8,s[j]=k^(k&k*2&34)
*6^c+~y;}}

Attachment: screen.tr
Description: Troff document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]