initial and default frames use different inter-line spacing

[Jeff Sheinberg]

This bug report will be sent to the Free Software Foundation,
 not to your local site managers!!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

In GNU Emacs 20.7.2 (i386-debian-linux-gnu, X toolkit)
 of Tue Jul 25 2000 on raven
configured using `configure  i386-debian-linux-gnu --prefix=/usr 
--sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib 
--infodir=/usr/share/info --with-pop=yes --with-x=yes --with-x-toolkit=yes'

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Hi,

I am using this font,

    -misc-fixed-medium-r-normal-*-15-*-*-*-c-*-iso8859-1

from Xfree86-3.3.6, along with the the Debian xserver-s3 3.3.6-38
package under the Debian xfree86-common 4.0.3-4 infrastructure.
This font is commonly known as "9x15".

The bug in Emacs is that the initial frame is physically larger
than subsequently created frames due to the interline spacing of
the initial frame being larger than the interline spacing of
subsequently created frames.

In other words, the number of lines in both types of frames is
identical, however, the physical size of the initial frame is
larger than the physical size of subsequent frames.

It is easy for me to reproduce this bug,

    bash-$ emacs -q

    C-x 5 2

now just line up the frames side by side and it is obvious what I
mean.  Here is the output of "xwininfo" for each of these frames,

    bash-$ xwininfo     # the initial frame

    xwininfo: Window id: 0x4c00019 "*scratch*"

      Absolute upper-left X:  1020
      Absolute upper-left Y:  31
      Relative upper-left X:  0
      Relative upper-left Y:  0
      Width: 740
      Height: 988
      Depth: 16
      Visual Class: TrueColor
      Border width: 0
      Class: InputOutput
      Colormap: 0x21 (installed)
      Bit Gravity State: NorthWestGravity
      Window Gravity State: NorthWestGravity
      Backing Store State: NotUseful
      Save Under State: no
      Map State: IsViewable
      Override Redirect State: no
      Corners:  +1020+31  --480+31  --480-5  +1020-5
      -geometry 80x60+1015-0

    bash-$ xwininfo     # the subsequent frame

    xwininfo: Window id: 0x4c0005f "*scratch*"

      Absolute upper-left X:  1020
      Absolute upper-left Y:  53
      Relative upper-left X:  0
      Relative upper-left Y:  0
      Width: 740
      Height: 928
      Depth: 16
      Visual Class: TrueColor
      Border width: 0
      Class: InputOutput
      Colormap: 0x21 (installed)
      Bit Gravity State: NorthWestGravity
      Window Gravity State: NorthWestGravity
      Backing Store State: NotUseful
      Save Under State: no
      Map State: IsViewable
      Override Redirect State: no
      Corners:  +1020+53  --480+53  --480-43  +1020-43
      -geometry 80x60+1015+30

Note that the number of lines in each window is the same (60
lines), however, the height of the initial frame is 988 pixels,
while the height of the subsequent frame is 928 pixels.

Also, I get the same kind of results whether the xrdb database
contains an entry for "Emacs.geometry" or not, just the number of
lines in each frame changes from the compiled in Emacs default,
the same bug that I described above still occurs.

I prefer that by default, Emacs uses the same interline spacing
between fonts as that used by the "xterm" program.  Of course,
this should be easy for the Emacs user to customize.

It took me quite some time to realize what was going on here, as I
initially used a workaround by setting "default-frame-alist",
however, this didn't work with Gnus, because Gnus mimicks the
initial frame construction, and I finally got fed up re-sizing
Gnus's initial frame by hand.

Thanks,
-- 
Jeff Sheinberg  <jeffsh@erols.com>

Recent input:
down down down down down down down down down down down 
up up up up up down down down down return n SPC n n 
tab return SPC SPC tab tab tab return next prior u 
down down down down down down down down down down down 
down down down down down down down down down down down 
down down down down down down down down down down down 
down down down down return next tab tab tab tab return 
SPC SPC SPC SPC SPC SPC backspace backspace M-tab return 
SPC C-x b return SPC menu-bar vm-menubar-emacs menu-bar 
help-menu report-emacs-bug

Recent messages:
unzipping emacs-e20-9.gz...done
unzipping emacs-e20-10.gz...
unzipping emacs-e20-10.gz...done
unzipping elisp.gz...
unzipping elisp.gz...done
unzipping elisp-27.gz...
unzipping elisp-27.gz...done
End of message 255 from Reminder Service
Loading emacsbug...
Loading emacsbug...done