Created attachment 357301 [details] emacs 23.1 against emacs 22.3 Description of problem: Just pulled down the new emacs-23.1 update from F11 stable updates, and now launching a new emacs window shows text in approximately double the previous default size. Attaching a screenshot showing a running version of emacs 22 side by side with emacs 23 on the same machine. I have to reduce emacs 23 to a 6 pt font to get something sensible displaying. Reverting to emacs 22.3 gets sensible font sizes again Version-Release number of selected component (if applicable): emacs-23.1-1.fc11 How reproducible: Always Steps to Reproduce: 1. Launch emacs 2. 3. Actual results: Text displayed twice the previous size Expected results: Additional info:
Seeing this as well.
I'm seeing something similar, although the font in my case is smaller than with the old version. The problem seems to be to do with finding fonts. If I attempt to select (using Options => Set default font) the font I normally use (MiscFixed Regular 9), I get set-face-attribute: Font not available: #<font-spec nil nil MiscFixed\ Medium\ Semi-Condensed nil nil nil nil nil 9.0 nil nil nil ((:name . "MiscFixed Medium Semi-Condensed 9"))> in the *Messages* buffer. This is erroneous, because I didn't ask for Semi-Condensed, and anyway SemiCondensed (no hyphen) is available on my system: $ fc-list MiscFixed MiscFixed:style=Regular MiscFixed:style=SemiCondensed MiscFixed:style=Bold MiscFixed:style=Bold SemiCondensed gnome terminal happily runs with font set to MiscFixed Regular 9
The problem here is that emacs is scaling the requested font size according to the display resolution reported by Xorg. eg, my laptop display reports xdpyinfo dimensions: 1600x1200 pixels (304x228 millimeters) resolution: 134x134 dots per inch while my external monitor report dimensions: 1680x1050 pixels (514x321 millimeters) resolution: 83x83 dots per inch Now both of these are accurate for the dimensions of the screen, but that doesn't mean emacs should use them to change the font sizes the user requested For example, using my laptop display - Go to the menu 'Options -> Set Default Font'. - Select 'DejaVu Sans Mono, Book, 12pt' - In a buffer, move cursor over a letter, and type 'c-u c-x =', and it displays xft:-unknown-DejaVu Sans-normal-normal-normal-*-22-*-*-*-*-0-iso10646-1 (#x50) ie, so when user requested requested 12pt, and emacs instead gave them 22pt Doing the same thing after booting up using external display (dpy=83 instead of 134), and it shows emacs gave 14pt xft:-unknown-DejaVu Sans-normal-normal-normal-*-14-*-*-*-*-0-iso10646-1 (#x50) Even worse, if you switch between laptop & external monitor on the fly using xrandr, then the Xorg reported DPI is *not* changed. So booting with laptop display (dpi=134), and then switching to the external monitor (dpi=83), X still reports dpi of 134. So having emacs scale its fonts based off DPI is pretty much useless. It should just give the font size the user requests - ie *exactly* the same size as that shown in the font preview panel of the 'Set Default Font' dialog box when choosing font.
Re comment #3: agreed. (although why it can't find my font at all I don't know). The important thing for a non-wsiwyg editor like emacs is the angle subtended at the eye, not the dimensions on the screen, and that requires knowing the distance from the viewer -- a fact not readily obtainable from X. At the moment, it's often the case that something like a laptop or notebook screen has smaller pixels but is held closer to the user, handily cancelling out the difference. So setting to what the user says (without doing any calculation) is the best option.
FWIW, one nasty hack to force emacs to see a static DPI is to add '--dpi $DPI' when running xrandr to switch heads. Change '$DPI' to match whatever DPI is shown in GTK config System -> Preferences -> Appearance -> Fonts -> Details -> Resolution' this seems to make sure that the font size shown in emacs' font chooser dialog matches the font size it actually then uses. emacs should be honouring the GTK resolution in the first place though, if its going to use GTK for its widgets as it now does eg, my GTK font resolution is set to 96, so when switching monitors on the fly, I I can run use something like xrandr --dpi 96 --output VGA-0 --off --output LVDS --auto this is still sub-optimal though because it won't be set automatically upon login.
I have the exact same problem noted above. In particular a laptop running with an external monitor and DPI forced to 96dpi in GTK. Basing font scaling on the dpi reported by X is incorrect. This is a well known and much discussed issue in GTK for the reason cited in comment #4. The only sane way to deal with this is to allow the user to specify the dpi which most of us do via the GTK "appearance" dialog in the font detail section. You should respect the user's preferred dpi. I have found the workaround posted by Dan in comment #5 to be viable. However, I would like to suggest pushing a major new package upgrade to "stable" in a stable release (F11) with a significant problem which makes the package almost unusable (and which was widely reported during testing) was not wise. Returning from vacation only to discover I could not use my text editor was not pleasant.
hello, I posted the bug report to the upstream mailing list and this is what I got back: http://lists.gnu.org/archive/html/bug-gnu-emacs/2009-09/msg00905.html
FWIW, Emacs in CVS HEAD (upcoming 23.2 release) gets its DPI value from XSETTINGS, i.e. the 96 dpi mentioned in comment #6.
Same problem observed with the default emacs in a new fedora 12 installation with current updates installed. The emacs font size is way too big. It ought to be comparable to the standard font size in a terminal window. It's been fine for many years in fedora and does not seem to be a problem with other distributions like ubuntu. Why is it broken now? This is one that just needs to work out of the box. Among other things, I've got students who are new to linux/emacs/c/c++ programming, and I can't expect them to have to fumble with customizations just to get the editor to behave sensibly when they're first trying to get the hang of a new system.
Created attachment 381561 [details] Patch to read DPI from Xft and XSETTINGS, backported from emacs git repository
Here is a build with the fix for Fedora 12: http://koji.fedoraproject.org/koji/buildinfo?buildID=149287 Please test it and share results, because I do not have this problem on my computer. I tested it using "startx -- -dpi 128" to increase the DPI value, and with the patch the emacs frame is no longer huge, so that seems to be fixed. Is the DPI change caused by switching to an external monitor properly handled now?
With 23.1-16 from Koji, it doesn't run: [paul@vienna]~% emacs (emacs:9088): GLib-WARNING **: g_set_prgname() called multiple times Arithmetic error [paul@vienna]~%
Paul, thanks for testing it. It works for me. Here are commands which I used: $ yum remove emacs emacs-common emacs-el $ yum install --nogpgcheck ./emacs-23.1-16.fc12.i686.rpm ./emacs-common-23.1-16.fc12.i686.rpm $ emacs Do you have Fedora 11 or 12? Do you have x86_64 architecture?
The GLib warning is this: https://bugzilla.gnome.org/show_bug.cgi?id=563627. It has been reverted, it was a mistake on GLibs part to make that warning. The arithmetic error is something else. The patch in comment #10 may actually return a DPI of zero. This happens if there are XSETTINGS but no entry for DPI. As dpi is used in division later on, this leads to aritmetic error. I suspect you would get most part of this bug right if one uses Xft.dpi from X resources as is also done in the patch. The reading of XSETTINGS is mostly for dpi:s that change at runtime. You don't have the proper lisp code in the patch to implement that anyway, so reading XSETTINGS serves little purpose if X resources are set up correctly with Xft.dpi. For Gnome it is, for KDE I'm not sure.
Created attachment 381740 [details] Patch to read DPI just from Xft The simplest solution. It does not handle DPI changes when emacs already runs.
Here is a build with that simpler fix for Fedora 12: http://koji.fedoraproject.org/koji/buildinfo?buildID=149843
The patch was applied in emacs-23.1-17. Emacs-23.1-18 is already issued.
emacs-23.1-11.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11
emacs-23.1-11.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update emacs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/emacs-23.1-11.fc11
emacs-23.1-13.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11
emacs-23.1-13.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update emacs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/emacs-23.1-13.fc11
emacs-23.1-13.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.