[Top][All Lists]

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

bug#16306: 24.3.50; font change creates blank column on Lucid

From: YAMAMOTO Mitsuharu
Subject: bug#16306: 24.3.50; font change creates blank column on Lucid
Date: Thu, 02 Jan 2014 14:37:49 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Wed, 01 Jan 2014 12:09:39 +0100, martin rudalics <address@hidden> said:

>> On my system, (640 16 16 2) before and (1120 28 16 2) after the
>> font change.

> 28 for the fringe width doesn't look right, this should be 30 since
> a character is 15 pixels wide with the new font.  So there could be
> a bug in compute_fringe_widths, a function I never touched.  But
> this still would not explain a difference of four pixels.

There is actually nothing wrong with the calculation of the fringe
width, because the character width for the new font (Courier-18) is 14
on my side (14 * 80 = 1120).

> Could you try starting with GDB in x_new_font and tell me which
> value of "width" is passed to x_set_window_size_1 and how the latter
> calculates "pixelwidth" which it passes to XResizeWindow?

The value of "width" is 1120 as of the entry to x_set_window_size_1,
and the value of "pixelwidth" is 1166 at the call to XResizeWindow.

It is the window manager "quartz-wm" that reduces the width from 1166
to 1162, probably because it respects the size hint that was set in
update_wm_hints (in widget.c).  There, the value of base_width/height
is calculated using the width/height of the frame *before* resizing.

> And please also try the following patch (as mentioned earlier I
> never understood that calculation and what the value "14" is
> supposed to accomplish).  For me it doesn't change anything - maybe
> it does for you.

It doesn't change the behavior for me, either.

                                     YAMAMOTO Mitsuharu

reply via email to

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