Okay, you don't have to logout...you just have to exit all terminals
and then relaunch (so that the shared library gets reloaded.)

I verified that it's enough simply to replace /usr/lib/libvte.so.4.0.0
version 0.10.26 with libvte.so.4.0.0 version 0.11.0 to reproduce the bug.

I have the same problem. When the VTE_USE_DRAW environment variable is
set to 0, the problem is not occurred.

The GTK+ DPI hint was being applied wrong.  Should be fixed in 0.11.1.

This bug is still present in 0.11.3.

And still in 0.10.4

I'm still not seeing it here -- the terminal's font corresponds
exactly to what I'm selecting in the font selector.  Which font family
are you seeing this with?  You're certain that the terminal in this
case was started with --disable-factory or with no others already open?

I just checked out the cvs source from Apr. 25th, 2003 at 21:43
UT. This is version 0.11.4 of vte, and I'm definitely seeing the
bug. All I have to do is copy over the /usr/lib/libvte.so.4.0.0 with
the version compiled from the cvs source and open a new
terminal. Here's some info:

The bug occurs with all fonts that I select, but I'm using "courier 10
 pitch" at 14 pt size. 

I have anti-aliased text enabled and have this in my .bashrc: 
export GDK_USE_XFT=1.

I'm using version 2.2.1 of gnome-terminal, which has xft compiled into it:

josh@spleen:~$ ldd /usr/bin/gnome-terminal  | egrep Xft\|xft\|vte
        libvte.so.4 => /usr/lib/libvte.so.4 (0x4001e000)
        libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x400cb000)
        libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x4072a000)


The work around suggested above, setting VTE_USE_DRAW=0, which works
for me in version 0.11.0 of libvte, no longer works with version
0.11.4, so we've made negative progress.

I'll attach a screenshot of an open terminal running along with the
font selection menu in which you can cleary see the difference in font
sizes.

Created attachment 16010 [details]
screenshot showing discrepency in selected and displayed font size

What is the selected DPI setting in gnome-font-properties?  Can you
run "xprop -root | grep ^RESOURCE_MANAGER" and append the output?

josh@spleen:~$ xprop -root | grep ^RESOURCE_MANAGER
RESOURCE_MANAGER(STRING) =
"*customization:\t-color\nXft.antialias:\t1\nXft.dpi:\t103.000000\nXft.hinting:\t1\nXft.hintstyle:\thintmedium\nXft.rgba:\tnone\n"

Does sid also include the patch to GTK+ to allow it to use these hints?

As far as this dpi hint goes: If I'm not mistaken, this dpi hint value
is set in start-here->desktop preferences->font->details->dpi and it
doen't really matter what this is set to on my setup because I don't
have the "use the same font size as other applications" box checked
(see screenshot.)

If I check the box, then the terminal font changes size, so it would
seem that this hint is used, but the displayed font is still smaller
than the setting.

The DPI value from the gnome-font-properties dialog is always used if
GTK+ supports it.  I guess a better question would be: if you change
the DPI in the dialog to 72 and change nothing else, does the terminal
font size change?

Okay, now I know a little more about when the error occurs:

Using libvte version 0.11.0 from sid, the font size changes when the
box is checked and when I change the dpi (and I close all terminals
and open a new one.) so sid has the patch.

Using the cvs version I checked out and compiled today (version
0.11.4), the font size does not change when the box is checked and I
change the dpi setting. I guess this patch isn't in cvs, huh?

Here's a new piece of info: When the box is checked then the terminal
displays the same size font as is set for "applications" (why it's not
displaying the font set for "terminal applications" is probably a
separate bug.)

Only when in the terminal profile the box is *not* checked, and the
font gets set directly in the terminal profile dialog, does the
terminal display the wrong font size. In this case, I verified that
the workaround above works in version 0.11.0 from sid, but not with
the cvs version from today.

I have to quantify my last observation:

Using libvte version 0.11.0 from sid, the font size changes when the
box is checked **and when the environment variable VTE_USE_DRAW=0**,
then font size changes when I change the dpi. If the variable is not
set to zero, then the font size in the terminal does not change when
after changing the dpi.

Using libvte version 0.11.4 from cvs today, the font size does not
change when the box is checked when I change the dpi, *regardless of
the value of VTE_USE_DRAW*, whether 0,1, or unset.

Please forget about 0.11.0 and the VTE_USE_DRAW environment variable.
 Neither is the same as HEAD, which is what I'm trying to make sure
works here.

If you change the DPI setting in gnome-font-properties, does the text
in other windows resize?  If it does, then something's wrong in the
way vte is applying the Xft hints that it's getting from GTK.

Yes. When I change the dpi in gnome-font-props, all the fonts in other
applications and the window decorations etc. change after closing the
application and restarting it, but not the font in the terminal. Does
this help?

I've been playing with the dpi hint stuff in vtefc.c and vteglyph.c to
no avail...where else should I be looking?

If the applications need to be restarted in order for font settings to
take effect, then the installed version of GTK+ doesn't support
reporting those settings.  A working fallback (to the resource
database) should have things looking normally in CVS now.

I am sorry to say  that I checked out and compiled HEAD from Apr. 29th
at 8:50 UT. The bug is still there, just as stubborn as ever.

uh, maybe I misunderstood what you meant by a "working fallback." I
though you meant some kind of fix. I see that you just issue a warning
that font selection won't work properly. Does that mean that you
consider this nab?

Even if the version of gtk+ is supporting dynamic changing of dpi, the
terminal should still get initialized properly, right?

sorry, I meant to say, 

Even if the version of gtk+ *doesn't* support dynamic changing of dpi...

Er, no, that warning was removed once the fallback went in.  My guess
is anoncvs didn't have the newest code yet.

Yes. I checked out head again Apr. 29th at 15:11 UTC and recompiled.
The font is now being displayed at the correct size (juhu.)

I don't know if the remaining discrepency is a different bug, you tell me:

If, in the edit profiles box, I check "use the same font size as other
applications" it displays a font at the same size as is selected in
gnome-font-properties as application font, but doesn't display the
correct face. i.e. if I change the size of the application font, then
the font in the terminal also changes size, but if I select a differnt
font, the face (shape) never changes.

If, in the edit profiles box, I do *not* check the box, and select the
font directly in the dialog then the font in the terminal displays
both the correct size and the correct face.

The second question is why the terminal responds to the "application
font" and not to the "terminal font" setting in gnome-font-properties.

If the terminal is obeying the size, then it's working as
gnome-terminal expects it to.  If the font-properties dialog indicates
that something else should happen, then it's a policy disagreement
between gnome-terminal and the control-center module, nothing to be
done about that in the vte module.

Although the bug is resolved, just wanted to mention that this seems
to be fully resolved as of 0.11.5.

Thanks Nalin!