GNU bug report logs - #5848
23.1.95; bands of background after font change if --with-x-toolkit=no

Previous Next

Full log

View this message in rfc822 format

From: Ted Phelps <phelps <at> mantara.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 5848 <at> debbugs.gnu.org
Subject: bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 19:54:59 +1000

=?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> Ted Phelps skrev 2010-04-07 08.52:
> > =?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
> >> YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
> >>> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
> >>> top side internal border width, respectively.  So, the internal border
> >>> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
> >>> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.
> >>
> >> Thanks for the clarification.  One pixel is still missing though, I'll
> >> keep looking.
> >
> > I've had a closer look and that last pixel is still there when:
> >
> >    pixelwidth = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, cols);
> >    pixelheight = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, rows);
> >
> > In this case, there's a one pixel border around the left, bottom and
> > right edges of the frame.  Hopefully this helps you with your search?
> > Or maybe this is the intended behavior?  I'll see if I can upload a
> > screenshot...
> >
> 
> Does this pixel disappear if you set internal border width to 0?
> I.e:
> 
> (set-frame-parameter nil 'internal-border-width 0)

Yes, it does.

> Anyway, when toolkit-x is no, the wm size hints are off by one pixel,
> so there is actually (font height)-1 extra pixels.

Ok.

Thanks,
-Ted

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.