bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#5848: 23.1.95; bands of background after font change if --with-x-too


From: Jan Djärv
Subject: bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 10:23:54 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4



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)

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

        Jan D.






reply via email to

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