MASTER regression after switching system font size to 13.333 pixel - fonts appear too large in some apps that do hand made font sizing - treating pixel units as point units

I see this bug too. I had to use 10px fonts in order to get something usable. See bug #327386.

Oops ! I meant bug 310353 :/

I can confirm this, its terrible...

please attach screenshots for the new default (13.333px) and for "10" ... please include a few apps: gnome-terminal, thunderbird, firefox, ekiga, etc.

more: also please include the output of xdpyinfo and tell me what DPI you see in the font settings dialog.

xdpyinfo for me :

name of display: :0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 10600000
X.Org version: 1.6.0
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x8800005, revert to Parent
number of extensions: 29
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    DRI2
    GLX
    Generic Event Extension
    MIT-SCREEN-SAVER
    MIT-SHM
    NV-CONTROL
    NV-GLX
    RANDR
    RECORD
    RENDER
    SECURITY
    SHAPE
    SYNC
    X-Resource
    XC-MISC
    XFIXES
    XFree86-DGA
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
    XVideo-MotionCompensation
default screen number: 0
number of screens: 1

screen #0:
  dimensions: 1280x800 pixels (332x212 millimeters)
  resolution: 98x96 dots per inch
  depths (7): 24, 1, 4, 8, 15, 16, 32
  root window id: 0x1a7
  depth of root window: 24 planes
  number of colormaps: minimum 1, maximum 1
  default colormap: 0x20
  default number of colormap cells: 256
  preallocated pixels: black 0, white 16777215
  options: backing-store NO, save-unders NO
  largest cursor: 64x64
  current input event mask: 0x7ac03f
    KeyPressMask KeyReleaseMask ButtonPressMask
    ButtonReleaseMask EnterWindowMask LeaveWindowMask
    KeymapStateMask ExposureMask StructureNotifyMask
    SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask
    PropertyChangeMask
  number of visuals: 120
  default visual id: 0x21
  visual:
    visual id: 0x21
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
  visual:
    visual id: 0x22
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
  visual:
    visual id: 0x24
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
  visual:
    visual id: 0x25
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
  visual:
    visual id: 0x26
    cl...

xpydinfo is attached

My DPI is set to 96

Here you have the screenshots I took in my latop.

My dpi setting is 106 (it was changed automatically from 96 when I migrated to Jaunty).

The dpyinfo command says this about my screen:

screen #0:
  dimensions: 1024x768 pixels (246x185 millimeters)
  resolution: 106x105 dots per inch

If you need more information about dpyinfo tell me it and I will include its full output.

Here is couple of screenshots: Gnome Terminal, Pidgin (only status messages are affected) and SMPlayer.

I forgot information about my screen: 17'', 1280x1024

I'm using a KVM based Qemu for screenshots. Anyway, it shows the bug clearly.

I can confirm this bug, default settings of font sizes of 13.333 are way to big...

I have a dual screen setup (2x19") 2560*1024
my resolution is reported as 86dpi in the fonts settings dialog.

xdpyinfo attached

please check gnome-terminal from my ppa: https://edge.launchpad.net/~asac/+archive ... that should fix it and monospace 13.333px is right with it.

i keep the libgnome task open for now as it uncovered these issues.

Is there an intention to increase the default font sizes and some dpi issues resulting in overly large rendering, or should the default settings have remained the same in the first place?

This new gnome-terminal didn't change anything for me. However, I'm not sure whether the cause is that the fix is incorrect, given that, for some reason, when I move back from 10 to 13.333, this time all applications are huge, not just gnome-terminal and thunderbird. You have attached a firefox screenshot with the gnome-panel to see what I mean.

I tried restarting the system, just in case without luck.

Carlos: the value you need to move to is 13.333px ... to test gnome-terminal, please set that directly in gconf-editor as the UI fix that in gnome is missing. e.g. go to /desktop/gnome/interface/monospace_font_name and set that to "Monospace 13.333px" or just unset the key. ... same for the other settings you modified - if you did that.

note: the "px" is the important part here. that wasnt honoured by gnome-terminal causing an artificial size boost (e.g. similar to what happens if you just use "13.3333" without px.

Look for example at Virtual Box or at Skype or even at people's statueses in Pidgin and see for yourself what you did by changing from 10 to 13.333 with default font size. This is just hilarious.

I also use Ubuntu as a guest OS in Virtual Box and having to make it fullscreen to be able to just use terminal is very inconvenient.

The only app that looks better for me with new font size is Open Office. I don't mind going back to 10 in OO though. For me 10 was the right choice for the size of the current font.

I'd like to add a few things:

- People unhappy with the font sizes can change them back manually in System > Preferences > Appearance > Fonts. I'm not implying that I think that 13.333 is a good default value, though.

- The other day's update managed to change the font sizes for only three of the five categories listed in Appearance > Fonts. "Window title font" and "Desktop font" remained at 10. This resulted in very odd combinations of fonts. I would understand this if I had explicitly set those two to 10, but I hadn't (neither on my desktop or on my laptop), so I suspect this is a mistake in the update.

- I would like to know, on which grounds was 13.333 chosen as a good default value? Or as a better default than 10, in any case?

- About the 'px', how come 13.333px (not 13.333pt) responds to the DPI setting?

- And about DPI settings, I think it's not a terribly good idea to scale fonts to have fixed physical sizes across different monitors. On my 12" laptop I expect to see the same amount of stuff as on my 19" monitor, only smaller. I've done a test in which I set the correct DPI on both computers, open a terminal with the same font size on both and put them side by side. Indeed, the physical sizes are the same, as intended. But - what looks OK on my desktop looks way too big on my laptop, and what looks OK on my laptop looks way too small on my desktop. A 9" netbook would be a lot worse. I think that the ability to set the correct DPI value is useful, but the default font sizes should be pixel sizes, not physical sizes.

BTW, even on my desktop (19", 1280x1024, 86 DPI) the 13.333 default looks too big indeed. My 12" laptop panel has 126 DPI, so it's much worse there. I've reset both my computers to 96dpi, 10px, which I quite like...

I agree with pablomme - this is what I was implying with my question.

Nothing against increasing default font sizes, at all in fact, just curious as to the rationale.

But, in any case, I think pablomme is right, doesn't seem like a good idea to define the values in pixels - needs a measure that will scale reasonably according to the dpi.

Actually thinking about this a bit more I think I have the solution to the font size madness:

- We do not want fixed physical sizes, as explained above

- We do not want fixed pixel sizes either - what happens if you have two monitors of the same size and different resolution? You want greater detail, not smaller fonts.

- What we want is the physical font size to be a *fixed fraction of the screen size*. That makes small screens have smaller fonts, large screens have larger fonts, and same-size screens of different resolutions (or even the same screen at different resolutions) have the same font sizes.

I.e., we want:

FONT_SIZE_IN_PT = FACTOR_X * (RESOLUTION_X / DPI_X) / 72

or if we want to use the vertical screen size for reference

FONT_SIZE_IN_PT = FACTOR_Y * (RESOLUTION_Y / DPI_Y) / 72

Doing the maths for my monitor, and assuming that the font sizes I like are optimal, FACTOR_X = 1/96 and FACTOR_Y = 1/77.

NB, if I am not mistaken, the font size refers to the vertical size of the characters. However there is no problem in defining it using the horizontal screen size - in fact I would recommend that option to deal with wide-screen aspect ratios consistently.

NB2, it would be a good idea to lower-limit the default font size in pixels, to make sure it can be rendered. Think mobile-phone sized displays.

Typo. That should have been

FONT_SIZE_IN_PT = FACTOR_X * (RESOLUTION_X / DPI_X) * 72
FONT_SIZE_IN_PT = FACTOR_Y * (RESOLUTION_Y / DPI_Y) * 72

The factors above are correct though.

FWIW, Nautilus seems to exhibit the same issue here with 13.333px as gnome-terminal (see the screenshot)

13.333px is 10 point for 96 dpi ... so if you see a difference on such screens it means the applications have a bug.

Update:

So. gnome-terminal is already fixed and available in my PPA: https://edge.launchpad.net/~asac/+archive

I will land a bunch of more fixes including thunderbird tomorrow or monday there. So add my PPA apt lines and upgrade two times a day and see how things become better for you. Thanks for testing and providing feedback.

bzr commit -m '* fix LP: #345189 - thunderbird 2 treats pixel sized system fonts as
  if they were point sized, which causes for to HUGE fonts
  - add debian/patches/lp345189_absolute_font_sizing.patch
  - update debian/patches/series' --fixes 'lp:345189'
Committing to: bzr+ssh://<email address hidden>/~mozillateam/thunderbird/thunderbird.dev/
modified debian/changelog
added debian/patches/lp345189_absolute_font_sizing.patch
modified debian/patches/series
Committed revision 98.

this is happening to me too

Alexander,

gnome-terminal looks better now.

Thunderbird looks better too, however, if I compare it side to side with Firefox, the menu text is still slightly bigger in Thunderbird.

I think the main problem is that the default font size is now 13.333 for most fonts except for "Desktop Font" and "Window Title" where it is 10. This causes the weird behavior see in Chris Coulson's screen shot ( https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/345189/comments/26 ) where the icons on the desktop and the icons in Nautilus (drawn by the same application) have different sized text.

Aside from that, I think that unless nautilus is also broken and uses way too big fonts for the definition of 13.333px, this definition is not a good default and should be reverted back to 10px (which looks really nice on my 96dpi display, and have always been).

Also, just as a side note, in MS-Windows the default desktop font size is even smaller then 10px (or equivalent, I'm not sure how MS-Windows font-sizes map to GNOME's) and a lot of people I talked with are complaining that the fonts are too big when they move from MS-Windows to GNOME.

Oded, 13.333px == 10 point on 96 dpi ... apps that look different have a bug.

affects OOo

affects update-manager

its not an update manager issue, but rather a gtk or maybe pango one. The problem seems to be that scaled tags (small, big, etc.) for markup eliminates the absolute flag from its base size somehow. I contacted pango developer to get a better idea where this issue comes from.

Anyway, keeping update-manager in the bug (as invalid) as its useful to QA our changes.

we will backout the defaults change in libgnome for jaunty.

libgnome backout committed to bzr:

bzr commit -m 'RELEASE 2.26.0-0ubuntu2 to ubuntu/jaunty
* debian/libgnome2-common.gconf-defaults: fix LP: #345189 - regression after
  switching system font size to 13.333; we backout the new font defaults made in
  2.25.1-0ubuntu2 and force 96 dpi again (see 2.24.1-1ubuntu3)' --fixes 'lp:345189'
Committing to: /tmp/g/ubuntu/
modified debian/changelog
modified debian/libgnome2-common.gconf-defaults
Committed revision 4.

Alexander, the problem is that the window and desktop font is set at 10px while other fonts are set as 13.333px. All is "px".

The result is that the text looks disproportioned between the application and the window title as can be seen in the last couple of screenshots. Worse - if you look at a nautilus window vs. icons on the desktop they look very different even though its the same application showing the same thing (files).

Moreover, I'd like to note that the text box I'm currently writing this text in is specified as having font sized at 10pt (not pixels) and I think (from my experience reading things on computer screens over the years) that Firefox renders it faithfully. If you'll look in the screenshot you'd notice that the text looks radically different then the one nautilus renders which is clearly way too big. However the text size in this text box pretty much matches up to the text size of the window title which is currently set (as by default) to "10" (whatever that is in the GNOME font properties dialog).
[Not that it matters, but this display is currently set to 86dpi by Ubuntu automatic DPI magic thing]

What I'm saying is that there are two major issues in this regression ticket:
1. GNOME defaults use two different font sizes: 10 and 13.333 for no apparent reason and it looks horrible.
2. Apparently most application on the GNOME desktop render the font as if the number was specified in points and not pixels, and as a result the font is rendered way too bit. On my desktop this currently includes Metacity and Nautilus, GNOME control-center applications and a few more.

Lastly, there seems to be a related problem with the font preferences dialog: when you first load it, the font sizes are specified as 13.333 (not for all, as noted) but when you want to change it there is no option for 13.333 to change it back. Worse - if you type 13.333 manually in the "font size" box and click "OK", the text in the application suddenly grows by 33%. So it looks like even the GNOME font properties dialog doesn't know that the font size is measured suddenly in pixels.

Font sizes in GNOME have always been in points and are still so in all applications (except perhaps those that were modified during this discussion) - why was this change suddenly introduced? it doesn't make any sense.

This bug was fixed in the package libgnome - 2.26.0-0ubuntu2

---------------
libgnome (2.26.0-0ubuntu2) jaunty; urgency=low

  * debian/libgnome2-common.gconf-defaults: fix LP: #345189 - regression after
    switching system font size to 13.333; we backout the new font defaults made in
    2.25.1-0ubuntu2 and force 96 dpi again (see 2.24.1-1ubuntu3)

 -- Alexander Sack <email address hidden> Mon, 23 Mar 2009 12:34:41 +0100

for openoffice.org its a duplicate of http://qa.openoffice.org/issues/show_bug.cgi?id=99293 - fixed in 3.1 (karmic)

filed gnome-terminal bug upstream and submitted patch to http://bugzilla.gnome.org/show_bug.cgi?id=576675

filed gtkhtml bug and provided patch in: http://bugzilla.gnome.org/show_bug.cgi?id=576684

confirmed in evolution.

filed evolution bug (http://bugzilla.gnome.org/show_bug.cgi?id=576694) and submitted patch.

It is still completely unclear to me why this change is pursued at all.

This negates the whole "automatic DPI detection" and goes against good desktop display practices: Basically what you are saying is that the font size should be set as device dependent (exact pixel size) even though you do not know anything about the device!

A pixel size setting will only work if you compute it correctly against the actual device DPI - which you can't know in advance: a default setting of 13.333px will work great on 96DPI devices, but if my device is 86 DPI it will look too big.

Worse - if the DPI is hardset to 96 (as it was before the auto detection), and I fix this to the actual DPI of my device (for example - after reading the manual that came with my screen), the font size will not change as it is set to a physical px size instead of device independent point size.

I think this is bad practice - choosing the correct pixel size for a font is the job of the rendering infrastructure (after checking the device's DPI and the required point size) and not the job of the vendor.

This bug was fixed in the package gnome-terminal - 2.26.0-0ubuntu2

---------------
gnome-terminal (2.26.0-0ubuntu2) jaunty; urgency=low

  * src/terminal-screen.c: honour point and pixel sized system
    fonts - LP: #345189
    - add debian/patches/30_honour_point_pixel_sizes.patch
  * gnome-terminal.desktop.in.in: don't show gnome-terminal menu entry
    in XFCE by default - LP: #352451
    - add debian/patches/05_dont_show_only_in_xfce.patch

 -- Alexander Sack <email address hidden> Thu, 19 Mar 2009 12:47:58 +0100

This bug was fixed in the package evolution - 2.26.0-0ubuntu3

---------------
evolution (2.26.0-0ubuntu3) jaunty; urgency=low

  * debian/patches/90_svn_update.patch:
    - update to the current svn version so it get testing before next tarball
      (lp: #233620, #347852, #302637, #345189, #290287, #353226)

 -- Sebastien Bacher <email address hidden> Wed, 08 Apr 2009 18:24:08 +0200

This bug was fixed in the package thunderbird - 2.0.0.21+nobinonly-0ubuntu1.9.04.1

---------------
thunderbird (2.0.0.21+nobinonly-0ubuntu1.9.04.1) jaunty; urgency=low

  (cherry pick rev 98 from lp:~mozillateam/thunderbird/thunderbird.dev)
  * fix LP: #345189 - thunderbird 2 treats pixel sized system fonts as
    if they were point sized, which causes for to HUGE fonts
    - add debian/patches/lp345189_absolute_font_sizing.patch
    - update debian/patches/series

  (cherry pick rev 101 from lp:~mozillateam/thunderbird/thunderbird.dev)
  * fix LP: #145716 - panel launcher breaks on upgrade; we provide a
    compatibility link for the old mozilla-thunderbird binary
    - update debian/thunderbird.links

 -- Alexander Sack <email address hidden> Thu, 09 Apr 2009 10:41:05 +0200

This bug was fixed in the package thunderbird - 2.0.0.22+build1+nobinonly-0ubuntu1.nspr474

---------------
thunderbird (2.0.0.22+build1+nobinonly-0ubuntu1.nspr474) karmic; urgency=low

  * security/stability update 2.0.0.22 (USN-782-1)
  * add patch to fix ftbfs with gcc 4.4 (s/elif/else/)
    - add debian/patches/ftbfs_gcc44_elif.patch
    - update debian/patches/series
  * fix LP: #345189 - thunderbird 2 treats pixel sized system fonts as
    if they were point sized, which causes for to HUGE fonts
    - add debian/patches/lp345189_absolute_font_sizing.patch
    - update debian/patches/series
  * fix LP: #137221 - thunderbird-gnome-support package required for
    gnome capabilities; the gnome parts were always loadable modules and
    fail to load gracefully if depends cannot be fulfilled anyway; in turn
    we ship gnome components in the main thunderbird package and apply a bit
    magic in debian/rules to strip the gnome related dependencies from it;
    on top of this thunderbird-gnome-support becomes an empty package which gets
    all the dependencies for convenience; the purpose of new gnome-support is
    hence to install all required depends; in order to add the required depends
    to the gnome-support package we introduce a new substvar "shlibs:GnomeShlibs"
    and refer to it in control
    - remove debian/thunderbird-gnome-support.install
    - update debian/rules
    - update debian/control
  * the change for LP: #137221 moves files from thunderbird-gnome-support to
    thunderbird package; adding Replaces to thunderbird package accordingly
    - update debian/control
  * fix LP: #145716 - panel launcher breaks on upgrade; we provide a
    compatibility link for the old mozilla-thunderbird binary
    - update debian/thunderbird.links
  * drop not used control.in from debian/ dir
    - remove debian/control.in
  * pick up latest nspr (>= 4.7.4) to potentially fix armel build (LP: #385325)
    - update debian/control

 -- Alexander Sack <email address hidden> Tue, 16 Jun 2009 14:02:03 +0200

the issue is fixed in karmic

Don't just reopen closed bug tasks without leaving any comment

It looks like dicandoit2's account needs to be suspended and/or deleted, but I'll leave that up to Chris Coulson to request.

This is also a good example of why people who aren't in bug squad should not be allowed to change bug status. A brand new launchpad account can do a lot of damage if they want to do so, such as this person. Also notice dicandoit2 expands to 'd I can do it 2'...

I've reverted the second round of dicandoit2's rather pointless vandalism, save that, not being a bugcontrol member, I can't set "Won't Fix", so instead had to settle for setting brasero/jaunty and gtkhtml3.14/jaunty to "Invalid" as nearest semi-appropriate surrogate.

Thanks a lot for the cleanup, Max!!!

Max is a good example of why it is good that people who aren't in bug squad are allowed to change bug status :)

This bug was fixed in the package gnome-terminal - 2.28.0-0ubuntu1

---------------
gnome-terminal (2.28.0-0ubuntu1) karmic; urgency=low

  * New upstream release (LP: #434162)
    - many bug fixes: (LP: #359759, #381041, #340091, #345189)
    - updated translation
  * Bump libvte-dev to 0.21.5

 -- Didier Roche <email address hidden> Tue, 22 Sep 2009 10:41:40 +0200

jaunty have reached eol

I am quite certain these bugs are fixed in Maverick. so closing the remaining bugs. pardon me if i closed any task that is still a bug.