Default font size too large if using native DPI

Bug #310353 reported by hackel on 2008-12-21
130
This bug affects 22 people
Affects Status Importance Assigned to Milestone
gnome-control-center (Ubuntu)
Medium
Unassigned
Jaunty
High
Unassigned
libgnome (Ubuntu)
High
Unassigned
Jaunty
High
Unassigned

Bug Description

Binary package hint: gnome-control-center

I realise this is largely a matter of opinion, however I think enough people might agree with me that I am going to call it a bug. If the DPI is set correctly in GNOME, then the default font size of 10 is much too big to be usable. I currently have mine set to 7.5, though perhaps I like it smaller than most, and 8 would be a good default.

This issue is not apparent for many users, because they are running on higher DPI screens, but GNOME forces the DPI down to 96 instead of the users actual DPI (see bug #157398), so they see the fonts smaller than they actually should be. Once GNOME defaults to using the actual DPI value, this problem will become much more serious.

To see if you agree with me, find your DPI by running "xdpyinfo | grep resolution", then set your GNOME DPI to an average of the two values in System>Prefs>Appearance>Fonts>Details. Make sure all the GNOME fonts are set to 10pt, and then decide if you think this is usable or if it's too big.

Do you mean gnome-settings-daemon?

Federico, is there any reason we hardcode this?

There was a weird rationale from Owen Taylor; let me dig it up...

I doubt that Gnome does hardcode it. Gnome seems to ask the Xserver, which dpi setting to use during the first start of your GNOME session. I'm sure about this, because I had "DisplaySize 16 16" in my xorg.conf due to another bug and GNOME uses the according dpi value, which of course looked comletely weird. I think I tested this with Beta1. Not sure. Maybe it was Alpha5+. But I can check it again. gconf needs to be killed and the ~/.gconf directory removed
before setting DisplaySize in xorg.conf and restarting GNOME session.

Is it still true that it is hardcoded? Stefan Dirsch (CC:) installed 10.2 Beta1 recently on a test machine where the monitor was not correctly detected. /etc/X11/xorg.conf contained DisplaySize 16 16 in the "Monitor" section after the installation which is of course hideously wrong. The fonts in the login screen of gdm were *huge* because of this, it was barely possible to log in. And after logging in, all fonts in the Gnome desktop were *huge* as well. If Gnome had hardcoded 96 dpi, this wouldn't have happened. I don't want to say that hardcoding were a good idea. I just have the impression that it isn't hardcoded at the moment. Apparently gconfd uses the dpi it can get from the X-server. But it seems to get the dpi from the X-server only once and then remember it. That means even if you notice the problem and fix "DisplaySize" in /etc/X11/xorg.conf to contain the correct values, the font size in Gnome will stay wrong. To fix the problem for Gnome as well after fixing it in /etc/X11/xorg.conf, one has to kill gconfd and delete the dpi entry in ~/.gconf (or just rm -rf ~/.gconf* to make sure).

I suspect the theory behind this is that in stock X there's no GUI way to change the DPI value, so GNOME provides an override in case your X config is wrong (under the theory that you're not likely to figure out how to fix it in xorg.conf if you didn't get it right in the first place). Since SUSE does provide a GUI way to change X's value, the argument falls apart a little (although the GNOME setting has the advantage that you don't need to restart X after changing it).

Dan, this is the answer to which question?

sorry, that's in answer to "why does GNOME have this setting at all rather than just always using the setting from xorg.conf?"

But you can see in comments #4 and #5 that gconfd *does* use the Xserver settings. At least initially.

Federico, can you answer, please?

I don't know the whole code, but here are some data points:

1. gnome-settings-daemon queries the configuration value stored in GConf for "/desktop/gnome/font_rendering/dpi". It then propagates this value using the XSETTINGS protocol (on the "Xft/DPI" property), and also sets the "Xft.dpi" Xresource for apps which may want to use it (GNOME doesn't use that one).

2. The default value for /desktop/gnome/font_rendering/dpi in the GConf schema is 96.

3. GTK+ apps query the XSETTINGS manager for the "Xft/DPI property", and set this as the GdkScreen's resolution. If an XSETTINGS manager is not running, GdkScreen uses the magic value of -1 for the resolution.

4. GtkWidget queries GdkScreen for the resolution, and sets that value on the Pango font rendering context.

5. Pango sees the resolution set in the context; if it is -1 (unset), it uses a fallback value of 96 DPI. This is what gets used for rendering.

The rationale is as Dan says. X servers don't provide correct DPI information in an uncomfortably large percentage of cases, so GNOME ignores that and a) provides a reasonable default value; b) lets the user change it easily.

We can put a trivial patch in control-center2 to keep the Xft.dpi Xresource from being set in gnome-settings-daemon (as a quick hack to address the original comment).

The root of the problem is that the X server does not provide reasonable values. If we could trust it, there would be no need for this setting at all :)

About comment #4:

GDM probably picks up the values from xorg.conf because there's no XSETTINGS manager running at that point, although I don't know why my point (5) wouldn't apply there.

About comment #5:

I don't know why you got those weird fonts in your desktop. Was gnome-settings-daemon running? If not, why did it crash [that would be a bad bug]? I also don't know why my point (5) wouldn't apply.

You can try seeing what resolution values get passed around in the functions in pangocairo-fcfontmap.c.

This can't be a critical bug, BTW, unless you make it for the X server about providing broken DPI values.

Also: I don't know of any code in GNOME that actually queries the X server for the DPI value.

Dan, any chance to convince you to give it simply a try reproducing the issue? All that you need to do would be adding a fresh user and adding a line

  DisplaySize 16 16

to monitor section of your xorg.conf. This should at least break completely
the font sizes for the (Gnome) Xsession of the new user. Not sure if this
will also break gdm itself, but I think so.

Retitling for clarity.

I'm going to add code to gnome-settings-daemon to detect totally broken DPI settings and use a default value (96 DPI).

See also bug #219801, which is about X servers which get DisplaySize wrong.

BUT... why on *earth* does /usr/bin/gnome:

1. use a horrible sed script to extract the resolution from 'xdpyinfo'
2. *overwrite* your gconf key for the DPI!?

(In reply to comment #16)
> BUT... why on *earth* does /usr/bin/gnome:
>
> 1. use a horrible sed script to extract the resolution from 'xdpyinfo'
> 2. *overwrite* your gconf key for the DPI!?

Sigh, that came from the fix for bug #171096.

I'm going to remove that chunk from /usr/bin/gnome (gnome-session package). Then I'm going to make gnome-settings-daemon see if the DPI value provided by X is reasonable, and if not to pick a reasonable default. This will be used unless the user has set an explicit DPI value in gnome-font-properties.

Thanks. could you outline the exact algorithm so that we can make sure that the same (!) is done in KDE (to avoid that we have conflict in font sizes for users that use applications from both environments).

(In reply to comment #18)
> Thanks. could you outline the exact algorithm so that we can make sure that the
> same (!) is done in KDE (to avoid that we have conflict in font sizes for users
> that use applications from both environments).

Sure! What I'm using is in the next attachment.

Created an attachment (id=106649)
dpi.c

This is what I'm using in gnome-settings daemon. You want to look at get_dpi_from_gconf_or_x_server(). First, I see if the DPI value is set in GConf; if so, this means that we should use the user's preference. If not, I compute the DPI from the screen's dimensions and then use a fallback value if it is outside a valid range.

Dirk, I'm not sure what to do about GTK+ apps being run under a KDE session. Do you have an XSETTINGS manager like gnome-settings-daemon which sets the "Xft.dpi" setting? [Note that this has nothing to do with Xresources]

If there is an XSETTINGS manager, GTK+ apps should have no problems; they just pick up that value. Otherwise, I don't know where to pick up KDE's DPI setting; do you know how?

Created an attachment (id=106652)
Updated /usr/bin/gnome script

This is what I'll put in our gnome-session package. It is the same as the old script, minus the part that overwrites the user's GConf key for DPI.

Created an attachment (id=106653)
control-center2-217790-sanitize-dpi.diff

This is the patch I'll use for our control-center2 package.

See bug #168189 for the corresponding bug in GDM.

Couldn't we close this one now? Which issues are still open, Dirk?

(In reply to comment #27)
> Couldn't we close this one now? Which issues are still open, Dirk?

Uh, please don't close the bug. We'll likely ship a hotfix with the patch to gnome-session and to control-center2. I'd like to keep the bug open until that happens; otherwise I'll forget about those patches :)

*** Bug 221494 has been marked as a duplicate of this bug. ***

BTW, I submitted the fixes for control-center2 and gnome-session for SLED 10 SP1.

Submitted gnome-session to STABLE:

* Fri Dec 22 2006 - <email address hidden>
- Removed the part of /usr/bin/gnome that overwrites the
  /desktop/gnome/font_rendering/dpi setting in GConf upon the user's
  first login. With an updated control-center2 package,
  gnome-settings-daemon will take care of figuring out the right DPI
  value. Fixes the gnome-session part of
  https://bugzilla.novell.com/show_bug.cgi?id=217790.

Submitted control-center2 to STABLE:

* Fri Dec 22 2006 - <email address hidden>
- Added control-center2-217790-sanitize-dpi.diff to fix the
  control-center2 part of
  https://bugzilla.novell.com/show_bug.cgi?id=217790. Some X servers
  don't report the screen's physical dimensions correctly, so the DPI
  value is wrong. This can lead to unusably huge or tiny fonts. This
  patch constrains the X server's DPI value to something reasonable.

Not sure if it's relevant to this bug, but I just installed openSUSE from Factory with GNOME. The text size was indeed very big. The DPI setting in GConf was set to 96. After chaning the value to something else, and then back to 96 my fonts finally got the "right" size, ie smaller.

Binary package hint: gnome-control-center

I realise this is largely a matter of opinion, however I think enough people might agree with me that I am going to call it a bug. If the DPI is set correctly in GNOME, then the default font size of 10 is much too big to be usable. I currently have mine set to 7.5, though perhaps I like it smaller than most, and 8 would be a good default.

This issue is not apparent for many users, because they are running on higher DPI screens, but GNOME forces the DPI down to 96 instead of the users actual DPI (see bug #157398), so they see the fonts smaller than they actually should be. Once GNOME defaults to using the actual DPI value, this problem will become much more serious.

To see if you agree with me, find your DPI by running "xdpyinfo | grep resolution", then set your GNOME DPI to an average of the two values in System>Prefs>Appearance>Fonts>Details. Make sure all the GNOME fonts are set to 10pt, and then decide if you think this is usable or if it's too big.

Ryan Niebur (ryan52) on 2008-12-22
Changed in gnome-control-center:
importance: Undecided → Wishlist
Duane Hinnen (duanedesign) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. This bug is being set to Wishlist.
Bug #157398 has been set to wont fix. So at this point making the font smaller would effect everyone who accepts the default. If the setting in the future starts to react to a variable dpi, instead of defaulting to 96dpi, and this problem persists please resubmit this bug.
Thank you for taking the time to submit this bug!

Duane Hinnen (duanedesign) wrote :

This is the second bug I have come across in the last couple of days. I checked brainstorm and someone has submitted this idea where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion!

vote now on this issue:
http://brainstorm.ubuntu.com/idea/12992/

hackel (hackel) wrote :

I don't think the Brainstorm idea was taking into account the use of accurate DPI settings. When running 96dpi on a 85 dpi monitor, I'm sure the font size is fine, if not too small. But when running 96dpi on a 150 dpi monitor, the font is way too big. My argument was that when running the same DPI as the monitor itself, which will produce same-sized fonts on all monitors, the font is still too big.

I imagine most of the people voting for that Brainstorm Idea--and most average users in general--aren't even aware of the DPI problem in Ubuntu/GNOME.

Sebastien Bacher (seb128) wrote :

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Changed in gnome-control-center:
assignee: nobody → desktop-bugs
status: New → Invalid
Sebastien Bacher (seb128) wrote :

The issue is similar to bug #157398 and due to the wrong dpi value

Sebastien Bacher (seb128) wrote :

note that such issues should be discussed on mailing list and not on the bug tracker, there is not many users reading the bugs and the lists are better to discuss such changes

Nicolò Chieffo (yelo3) wrote :

Now I'm on 121 DPI (1440x900) and the font is really too big... Sebastien, can you please link me the discussion in the mailing list? thank you very much

hackel (hackel) wrote :

Nicolò, the DPI is probably correct (you can measure it yourself to be sure). The problem is that all the default fonts in Ubuntu are way too big, because previously everyone defaulted to 96 DPI. That is why I filed this bug, and I am re-opening it now that bug #157398 is fixed in Jaunty.

Changed in gnome-control-center:
status: Invalid → New
Sebastien Bacher (seb128) wrote :

Nicolo there is no discussion on the mailing list that I know, I was encouraging people who want to discuss that to open one

Oh! I will open a new discussion in ubuntu-devel-discuss. Is this ok?

Nicolò Chieffo (yelo3) wrote :
Nicolò Chieffo (yelo3) wrote :
Sebastien Bacher (seb128) wrote :

why would changing the font setting be correct? on a screen which has 96 dpi the font would be smaller after upgrade for no reason

Sebastien Bacher (seb128) wrote :

Nicolo yes that's the appropriate list

Nicolò Chieffo (yelo3) wrote :

Well, isn't the DPI setting supposed to make fonts the same size on
all displays?

hackel (hackel) wrote :

Exactly, Nicolò.

Sebastien, would changing the default font size really affect anyone after upgrading? If they already have specified custom fonts, I certainly don't think they should be overridden upon upgrading. It should only affect new users. It's true that the fonts would be smaller for people using 96 dpi displays, and maybe there is a better solution, but I do believe (as Nicolò's screenshots demonstrate) that 10pt is too large when rendered accurately.

Personally, I believe the DPI setting should only be changable via xorg.conf/HAL (for advanced users) and there should be a general "UI Scale" option for users who simply want things to look bigger or visually impaired, etc. that would scale all UI elements. This is way beyond the scope of this particular bug, though.

Nicolò Chieffo (yelo3) wrote :

I've tried the alpha 5 livecd in a 1280x800 15.4" laptop, and in my 1440x900 14.1" laptop.
The fonts are rendered in a really different way!!!
Here are 2 photos for comparison.
the 1280x800 looks good, while 1440x900 looks BOLD!

Nicolò Chieffo (yelo3) wrote :
hackel (hackel) wrote :

Similar issues on my system.

hackel (hackel) wrote :
Alexander Sack (asac) wrote :

the gconf defaults and values should have px suffix:

e.g. "Sans 13.333px"

this should give proper size considering dpi.

hackel (hackel) wrote :

Alexander, what you are saying would completely defeat the purpose of DPI in the first place, which is to ensure that "10pt" appears exactly the same regardless of what screen you are viewing it on. The gconf defaults should absolutely not have a px suffix, as this would cause incredibly small, unreadable fonts on high-resolution displays like mine (150 dpi).

Marc Deslauriers (mdeslaur) wrote :

My tests seem to show that 10pt varies with size depending on dpi (ie: 10pt on a 135dpi monitor is bigger than 10pt on a 96dpi monitor).

10px is exactly the same size on both, as it seems to be dpi-adjusted.

Martin Pitt (pitti) on 2009-03-17
Changed in gnome-control-center (Ubuntu Jaunty):
milestone: none → ubuntu-9.04-beta
assignee: desktop-bugs → asac
Changed in gnome-control-center (Ubuntu Jaunty):
importance: Wishlist → High
Martin Pitt (pitti) wrote :

After discussing this heavily, it seems that something in GNOME has px and pt exactly reversed. "1 pt" = 1/72 inch, i. e. a 10 pt font should have the same physical ruler height *everywhere*, whereas a 10 px font has 10 physical dots on the monitor and thus its size is dependant on the monitor's DPI resolution.

Fonts should not be the same physical size everywhere; by default they ought to be bigger on big screens than on small ones. Thus I agree that 13.333 px is a reasonable default, at least for standard monitors (mobile phone screens are something different, since they usually have much fewer pixels).

Chris Cheney (ccheney) wrote :

From what I heard in the desktop meeting and from what Marc mentions it sounds like the Gnome font dialog isn't actually using pts but something else entirely. This probably can't be fixed properly for Jaunty but long term it should be using pts and using them properly being 1 pt == 1/72" and should be the same physical size on all displays with DPI set correctly.

Otherwise what was the point in setting DPI correctly to begin with?

Now the bit about font sizes being different for different classes of display is a real issue and should be addressed at some point. There are at least 3 classes of displays, laptops, hdtvs, and regular desktop monitors. The 3 classes exist due to differences in dpi and viewing distance from the screen, both of which affect the usable font size range. laptops typically have much higher DPI (~ 100-150dpi) than desktop monitors (~ 80-100dpi) which in turn have much higher DPI than HDTVs (~ 30-80dpi). You sit closer to laptops than either other class of display as well. Also since HDTVs DPI is so low you have to have a larger size font just be able to have enough pixels in the font to be usable.

Chris Cheney (ccheney) wrote :

To make the above point completely clear.

If you consider 8 pixels to be smallest displayable font size, it is probably something close to this anyway.

Then you end up with the smallest displayable pt size fonts as:

laptop 150 dpi - 4 pt
desktop 100 dpi - 6 pt
hdtv 30 dpi - 20 pt

This does not even take into account the factor of is it readable by the majority of users, but just plain being able to render the font properly at all.

However, as you can see there is clearly no universal correct font size for all use cases...

Marc Deslauriers (mdeslaur) wrote :

Unfortunately, this makes Jaunty uninstallable/unusable for netbooks, as most of the dialog boxes won't have the bottom buttons fit in the screen area.

Marc Deslauriers (mdeslaur) wrote :

Actually, the more I think about it, the more I'm convinced that the actual issue here is that there is a bug somewhere that is making "pt" fonts get dpi-adjusted _twice_, and "px" fonts are being dpi-adjusted once.

Alexander Sack (asac) wrote :

one part of this bug is supposed to be using 13.333px as the defaults - shipped in libgnome2-common.

Changed in libgnome (Ubuntu Jaunty):
importance: Undecided → High
status: New → Triaged
Launchpad Janitor (janitor) wrote :

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

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

  * debian/libgnome2-common.gconf-defaults: use 13.333px as the default fontsize
    used in font_name, document_font_name and monospace_font_name - LP: #310353

 -- Alexander Sack <email address hidden> Wed, 18 Mar 2009 20:49:42 +0100

Changed in libgnome:
status: Triaged → Fix Released
Changed in gnome-control-center (Ubuntu Jaunty):
milestone: ubuntu-9.04-beta → none
milestone: none → ubuntu-9.04

To complete this bug task, the Font settings UI needs to be changed to use px instead of pt. Ideally, this will be transparent to the user. Otherwise, some way of reverting to the default font size in px will need to be added.

Changed in gnome-control-center (Ubuntu Jaunty):
status: New → In Progress

This is why I got this morning very big fonts ?

Bug #345189 was opened about this issue. I had to set all fonts at 10px to get something usable :(

Jens (jens.timmerman) wrote :

how does that fix this bug?

the bug reporter says: default font size of 10 is too _large_
and changing it to 13.333 just makes the problem bigger...

the default of 10 was usable for me, but 13 is just to big (indeed, see bug #345189)

Matthew Paul Thomas (mpt) wrote :

Please remember that attaching screenshots to show problems with the default font size is almost uselessly misleading, since anyone with a different DPI would view the screenshot at their own DPI rather than yours.

Rick, changing Gnome's font settings to use pixels would not make it "transparent to the user", because it would mean either (a) the visible numbers would fluctuate depending on what computer you'd logged in to (and often display awkward values like "13.333"), or (b) Gnome would no longer scale to the DPI at all, which would put Ubuntu at a serious disadvantage when proprietary competitors start using >150dpi displays routinely. (Web browsers use pixel-based preferences for arcane reasons that made a lot of sense in 1999 but that are making steadily less sense over time. They'll probably switch to points a few years after OSes do.)

Iain Lane (laney) wrote :

Just for the record, places in a fresh (as of yesterday's daily) Jaunty install that fonts appear too large to me:

  - Nautilus
  - Window titles
  - Policykit/gksudo prompts ("titles" appear quite huge here

This on a Macbook 5.1 (Aluminium, late 2008)

Hermes (PL) (hermes85pl) wrote :

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.

This is clearly not the way to go.

Changed in libgnome (Ubuntu Jaunty):
status: Fix Released → Confirmed
Åskar (olskar) wrote :

I agree with Hermes. Look for yourself, look in Pidgin, look in Nautilus.

This is what happened;
This bug was about lowering the fontsize. The fontsize was instead increased to an abnormally high value, then the bug is marked as fixed?

With all your respect, if you think "13.333 px is a reasonable default" you should be using the Orca Magnifyer.

Sebastien Bacher (seb128) wrote :

could users there stick to fact and try not using angry tone or suggesting that those who did the changes are doing stupid thing, the value augmented but the unit changed too so it's not as obvious as you seem to think it is and the change has been working fine for several users, there is just some buggy applications which need to be update too and some corner cases to consider

exploder91 (d-cosner) wrote :

My fonts were way too big in Nautilus, Brasero buttons, etc yesterday. I am using a 15" wide screen LCD with a resolution of 1366 x 768. I changed all of the font settings to 10 and everything looks fine again.

Here is a post from the forum on this problem.

http://ubuntuforums.org/showthread.php?t=1101003

I can see that the importance for this bug now is "High" and I am sure it will be resolved in plenty of time for the final release.

Åskar (olskar) wrote :

I am sorry if my tone was angry but there really is more then "just some buggy applications" that is affected by this. Almost every gnomeapplication is affected, is all of them buggy? However I wish you the best of luck in solving this bug, e.g make the fontsize as it was before or smaller.

Matt Zimmerman (mdz) wrote :

I am seeing different behavior on two different systems. On my system at home, my font sizes are "normal", but at work, my terminals are much larger than they had previously been (and too large for the screen in my opinion).

How can I go about diagnosing the problem?

Alexander Sack (asac) wrote :

we don't use native DPI for jaunty anymore because of the regressions you can see in bug 345189.

Changed in libgnome (Ubuntu Jaunty):
status: Confirmed → Won't Fix
Changed in gnome-control-center (Ubuntu Jaunty):
status: In Progress → Won't Fix
Alexander Sack (asac) on 2009-04-07
Changed in gnome-control-center (Ubuntu):
importance: High → Medium
milestone: ubuntu-9.04 → none
soc (simon-ochsenreither) wrote :

Alexander, I think this bug is connected with https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/157398

It seems that your fix made gnome's behaviour more inconsistent than necessary (as described in the last commets on LP#157398) ... could you consider just reverting the fix from LP#157398 (instead of harcoding it somewhere else)?

Thanks

Paul Natsuo Kishimoto (khaeru) wrote :

I am experiencing something related to this bug (specifically Alexander Sack's wontfix in #43) using UNR Karmic Alpha 2 on an Acer Aspire One.

The screen resolution is about 134 dpi, but fonts are rendered by default at 96 dpi:

$ xdpyinfo | grep resolution
  resolution: 133x135 dots per inch
$ gconftool-2 --get /desktop/gnome/font_rendering/dpi
96

...the result is headache-inducing on the very small (~9" diagonal) screen. Setting 134 dpi manually is much better. UI elements *do* eat up a lot more screen real estate, but I personally much prefer that to squinting at the screen or having to lean very close to it.

I don't know what the proper thing to do is, so I will add the 'karmic' and 'ubuntu-unr' tags; if I should report a separate bug, please let me know.

tags: added: karmic ubuntu-unr
Endolith (endolith) wrote :

For some reason my DPI was set as 96 in Gnome Appearance settings, which is totally wrong. After changing it to the correct 128 DPI (which I measured and which I get from "xdpyinfo | grep resolution", the fonts at "10" are way too big. I set them all to "8", and it seems to be about right for a laptop.

Note that "10" is arbitrary and doesn't mean "10px" or "10pt" or anything meaningful like that. http://www.gnome.org/~federico/news-2007-01.html#font-sizes

hackel (hackel) wrote :

Guys, this fix was *reverted* so Ubuntu is still forcing DPI to 96 DPI by default instead of using the auto-detected value. Until that fix is reinstated, this bug is not really relevant. We are basically waiting for all the issues reported in bug #345189 to be fixed, which will allow fixing #157398, and then hopefully this one as well. :)

Alexander Sack (asac) wrote :

On Sat, Jun 27, 2009 at 02:47:06PM -0000, Endolith wrote:
> Note that "10" is arbitrary and doesn't mean "10px" or "10pt" or
> anything meaningful like that.

10 without any unit is supposed to mean point unit.

is 13.333px better for your unit?

 - Alexander

Endolith (endolith) wrote :

> 10 without any unit is supposed to mean point unit.

Well, according to that article it doesn't necessarily have any meaningful units.

> is 13.333px better for your unit?

I'm not sure what this is asking. I think it would be better if it the font settings showed point units instead of being a meaningless number, and I think point units would be better than px units.

On my screen, with 128 pixels per inch, the "8" setting is pretty good. If I create monospace text in Firefox at 8pt or the equivalent 14.2px, it is the same size as text in Gedit.

Alexander Sack (asac) wrote :

On Mon, Jun 29, 2009 at 11:12:43AM -0000, Endolith wrote:
> > 10 without any unit is supposed to mean point unit.
>
> Well, according to that article it doesn't necessarily have any
> meaningful units.

Not sure where you read that. I worked quite a lot on the code
surounding this, and with any units is "point"

>
> On my screen, with 128 pixels per inch, the "8" setting is pretty good.
> If I create monospace text in Firefox at 8pt or the equivalent 14.2px,
> it is the same size as text in Gedit.
>

Right. So no unit == point ;).

 - Alexander

Endolith (endolith) wrote :

> Not sure where you read that.

From the link I posted. http://www.gnome.org/~federico/news-2007-01.html#font-sizes

> Right. So no unit == point ;).

It does seem that way. :)

Paul Larson (pwlars) wrote :

While this bug does seem to affect some UNR users, it does not seem that it is specific to UNR, so I'm removing the ubuntu-unr tag for the time being. If anyone feels like it is specifically a UNR related bug, please feel free to explain further and re-add the tag.

tags: removed: ubuntu-unr
pmes (pmesch) wrote :

The title of this bug should be reworded.

I have a 44 DPI 50" 1080 HDTV running lucid and there are some fonts so small it's crippling. Specifically in Log File Viewer, and the terminal output in Synaptic Package Manager. I have fixed Log File Viewer by manually changing some of the font sizes in /var/lib/gconf/defaults/%gconf-tree.xml, but this is not something a normal person will want to do, and the terminal output in Synaptic Package Manager is still exceedingly small.

Gnome's Appearance font settings do not allow me to go any lower than 50. Setting the /desktop/gnome/font_rendering/dpi gconf key to 44 has really done wonders for display quality except it seems certain sudo'd processes are not aware of the changes I've made in font settings. I know 44 DPI is very low for today's desktop monitors and such, but it makes for an excellent big screen TV. Shouldn't I be able to set this to 44 if that's what my monitor has? If a monitor is not correctly detected by X there should be a user alert/simple DPI config.

Having the correct DPI should not be for advanced users or only those who've got correctly detected monitors.

Lowering the default for the lowest DPI setting would be a good:

http://git.gnome.org/cgit/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c

/* X servers sometimes lie about the screen's physical dimensions, so we
cannot
* compute an accurate DPI value. When this happens, the user gets fonts that
 * are too huge or too tiny. So, we see what the server returns: if it reports
 * something outside of the range [DPI_LOW_REASONABLE_VALUE,
 * DPI_HIGH_REASONABLE_VALUE], then we assume that it is lying and we use
 * DPI_FALLBACK instead.
 *
 * See get_dpi_from_gconf_or_server() below, and also
 * https://bugzilla.novell.com/show_bug.cgi?id=217790
 */
#define DPI_FALLBACK 96
#define DPI_LOW_REASONABLE_VALUE 50
#define DPI_HIGH_REASONABLE_VALUE 500

I just noticed that Ubuntu Software Center also ends up with extremely small fonts in the main viewing area while viewing application details and at the beginning with the icons.

Thank you very much/I don't mean to complain. :-)

Martin Pitt (pitti) on 2011-01-07
Changed in gnome-control-center (Ubuntu Jaunty):
milestone: ubuntu-9.04 → none
Changed in gnome-control-center (Ubuntu):
status: In Progress → Triaged
Changed in libgnome (Ubuntu):
status: Confirmed → Invalid
Changed in gnome-control-center (Ubuntu Jaunty):
assignee: Alexander Sack (asac) → nobody
Changed in gnome-control-center (Ubuntu):
assignee: Alexander Sack (asac) → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti) on 2011-02-21
Changed in gnome-control-center (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → nobody
Adolfo Jayme (fitojb) on 2014-01-01
Changed in gnome-control-center (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.