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

Previous Next

Package: emacs;

Reported by: Ted Phelps <phelps <at> pobox.com>

Date: Tue, 6 Apr 2010 14:28:02 UTC

Severity: normal

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


Message #44 received at 5848 <at> debbugs.gnu.org (full text, mbox):

From: Ted Phelps <phelps <at> mantara.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 5848 <at> debbugs.gnu.org
Subject: Re: bug#5848: 23.1.95;
	bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 16:52:40 +1000
=?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...

Thanks,
-Ted




This bug report was last modified 15 years and 82 days ago.

Previous Next


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