Bug 75582

Summary: gconf-editor crashes on dpi option
Product: [Retired] Red Hat Linux Reporter: Gérard Milmeister <gemi>
Component: gconf-editorAssignee: Mark McLoughlin <markmc>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 8.0CC: otaylor
Target Milestone: ---Keywords: MoveUpstream, Triaged
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:49:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gérard Milmeister 2002-10-09 23:29:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809

Description of problem:
When I first started the gnome desktop, the fonts were much too large. To get a
reasonable a display I had to set the font size to something ridiculously small.
So I set the gconf value to 75, the only value that delivers good results for
all X apps.
Unfortunately I couldn't use gconf-editor, as it crashed on this particular option.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
N/A	

Additional info:

Comment 1 Havoc Pennington 2002-10-10 00:31:12 UTC
I think we had a fairly compelling rationale for the current default dpi 
(including that both mac and windows use it, but there were other reasons also), 
but gconf-editor should be fixed.

If your fonts were really wrong it may have been some non-dpi-related issue, I
don't know.

Comment 2 Havoc Pennington 2002-10-10 00:32:18 UTC
*** Bug 75583 has been marked as a duplicate of this bug. ***

Comment 3 Gérard Milmeister 2002-10-10 18:46:56 UTC
Here is my configuration:
I have a 17" monitor and resolution 1280x1024. The ddc detects a resolution of x
times y dpi, where x and y are different and between 90 and 100 or so. This is
the right thing to do of course, e.g. to display real circles correctly in a
graphics program.
However, GNOME 1.4 apps and most other 'legacy' apps use the Helvetica 12pt
bitmap font for its menus (which I still find the best-looking font for
non-antialiased display). So it is really unsettling to see that if you select
for example Arial 12 pt in GNOME 2.0, its real size is very different from the
usual Helvetica 12pt font.
I had to set both the X server dpi setting and the gconf setting to 75, so that
I get the former, in my opinion, consistent setting.
I hope you understand that I see this as a problem?
So in short, I expect that Arial 12pt in GNOME 2.0 has the size that I have in
other apps.


Comment 4 Owen Taylor 2002-10-10 19:52:41 UTC
We are working on making all font rendering on the system use fontconfig
and Xft, so that will make Helvetica 12 the same size in all programs.

The separation of physical DPI from the "logical" DPI used to convert
font points into pixels:

 a) Generally is the right thing to do - appropriate font sizes depend more
    on angular resolution than linear resolution - think of a handheld
    that you view the image from a foot away, or a projector where you view
    the image from 30 feet away.
 b) Is needed because using a fixed logical DPI is needed to get good
    looking user interfaces unless all elements (images, lines, etc)
    in the interface are scalable. 
 c) Is what windows does (as well as a default logical dpi of 96), so is 
    needed to correctly display web pages.
 d) Is needed because physical resolution is often autoprobed incorrectly
    by X.


Comment 5 Gérard Milmeister 2002-10-10 22:38:44 UTC
Well, as I said this is true, but currently the result seems to be less than
optimal, and from discussion forums I see, that I am not the only one
disatisfied with the resulting, actual font sizes.


Comment 6 Havoc Pennington 2002-12-20 00:02:19 UTC

*** This bug has been marked as a duplicate of 70687 ***

Comment 7 Red Hat Bugzilla 2006-02-21 18:49:50 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.