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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 Apr 2010 11:18:25 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> 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.

> Upon further investigation, this is true for cols, but not always for lines.
> We have

> #define FRAME_LINE_TO_PIXEL_Y(f, row) \
>    ((row < FRAME_TOP_MARGIN (f) ? 0 : FRAME_INTERNAL_BORDER_WIDTH (f))        
> \
>     + (row) * FRAME_LINE_HEIGHT (f))


> So if row is less than FRAME_TOP_MARGIN (which is menu bar lines + tool bar 
> lines), internal border width is not added.  That makes sense for 
> FRAME_LINE_TO_PIXEL_Y as the internal border is below the tool bar.  But it 
> is 
> not correct for
> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT, which is supposed to return the total frame 
> size.  When setting wm size hints, this call

>      base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 0);

> will return just one internal border.  Thus, a pixel is missing.
> Thanks for pointing me in the right direction.

FRAME_LINE_TO_PIXEL_Y used to be 

#define FRAME_LINE_TO_PIXEL_Y(f, row) \
  (FRAME_INTERNAL_BORDER_WIDTH (f)  \
   + (row) * FRAME_LINE_HEIGHT (f))

and I changed the definition as you quoted so it takes account of the
`row < FRAME_TOP_MARGIN (f)' case in order to draw and handle events
for non-toolkit menu/tool bars correctly.  Actually I seem to have
overlooked the `base_height' calculation by specifying 0 as the number
of lines.  (Also, `row' should have been parenthesized.)

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp