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 14:54:04 -0600
User-agent: Mutt/1.2.5i

On Mon, Dec 31, 2001 at 11:48:14AM -0600, Rick Richardson wrote:
> 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() ...
> 
> 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.

Just as an FYI, a disabling all of the is_equal checks in a quite
gross manner will fix all three of these problems:

        $ grep is_equal *.cc
        ps.cc:  && sbuf_color->is_equal(env->col) && 0) {
        ps.cc:  if (1 || !output_color->is_equal(sbuf_color))
        ps.cc:  if (1 || !env->col->is_equal(output_color))
        ps.cc:    if (0 && output_color->is_equal(fill_color))

Of course, that also disables the optimizations that the code was
attempting to do.  But the rule is the code has to be correct
before trying to optimize it :-).

-Rick

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

The last line of a right hand page should not end with a hyphen. This
has been a style rule for many years, yet it is amazing that most word
processors do not do this! I just smile when I pick up a book produced
with something like Frame and you immediately find these errors.
Needless to say, troff does this correctly, and has for 20+ years. A
friend commented to me that normal evolution would have gone Word to
Frame to troff, but instead, the computer industry has gone the other
way! -W. Richard Stevens, author of 7 popular technical books. [R.I.P.]

reply via email to

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