K Chayka Reporter
	Description • 24 years ago

build 2001021420 and every other build I've used on win98SE

The default value for pref browser.display.screen_resolution is 96 dpi. This is
fine when using Windows Small Fonts, which is 96 dpi. When I use a screen
resolution 1280x1024 Large Fonts (120 dpi), text on many web pages becomes
unreadably small. Changing the browser.display.screen_resolution pref to 120 dpi
or any other setting has absolutely no effect with either Modern or Classic
skin. Shutting mozilla down and restarting after the pref change has no effect.
I've tried various settings from 0 to 200 with no effect on either the mozilla
UI or text size on any web page.

The expected result is that text size on web pages is adjusted for the higher
resolution.

	sairuh (rarely reading bugmail)
	Comment 1 • 24 years ago

dup of bug 5599 or bug 20391...?

	K Chayka Reporter
	Comment 2 • 24 years ago

I think not. bug 5599 is about changing the UI for setting the pref. bug 20391
is about calculating dialog window sizes based on the pref. Neither of these is
the problem.

In the fonts prefs dialog, the description of Screen Resolution reads: "Choose a
screen resolution. A larger value can improve text readability on some
displays." The default value is 96 dpi.

Changing this setting to 120 dpi has absolutely no effect on either the text
size in the UI, nor the text size on any web page. Everything looks exactly the
same regardless of the pref value, even after mozilla is shut down and
restarted. I even tried a value 0 (bug 36894) in the off chance it would do
something. Nada.

If this pref has some purpose other that adjusting text size for the specified
resolution, then the description in the pref dialog should be reworded to
indicate what it really does, or document somewhere what its limitations are. If
this pref does not apply to the Windows OS, then it should be removed or
disabled in the Win32 prefs dialog. I haven't found a bug that indicates it's
just plain busted on all OS's.

Incidentally, the browser.display.screen_resolution pref is not listed in all.js
or any other default/pref/ file. I went there first looking for a clue.

	sairuh (rarely reading bugmail)
	Comment 3 • 24 years ago

okay.

	Chris McAfee
	Comment 4 • 24 years ago

mac needs 96 dpi default.

	K Chayka Reporter
	Comment 5 • 24 years ago

The value of the default is not being questioned. 96dpi is probably OK for the
majority of Windows users as well. It just doesn't cut it when the screen
resolution is actually something other than 96dpi, like 120dpi in my case.

	Keyser Sose
	Comment 6 • 24 years ago

Moving to preferences:backend...

	Daniel Veditz [:dveditz]
	Comment 7 • 24 years ago

Preferences: Backend is for the raw mechanism of getting and setting prefs. 
Please reassign this to whichever group ought to be interpreting this 
particular pref.

Putting back the "Preferences" component who could solve the problem by 
removing the broken option, or else can forward on to whomever is supposed to 
be supporting the pref.

	sairuh (rarely reading bugmail)
	Comment 8 • 24 years ago

back to ben, for the nonce...

	Dave Huang
	Comment 9 • 23 years ago

While it does seem to be the case that browser.display.screen_resolution is 
ignored in the Win32 version, this probably isn't terribly important, because 
Mozilla calls GetDeviceCaps(..., LOGPIXELSY) to get the screen resolution from 
Windows.

From what I can tell, the problem is that the default font size is specified 
in pixels, not points. If you load a page that uses CSS to specify a font size 
in some physical unit (0.5in, for example), you'll notice that the text is the 
right size. However, regular old text without any stylesheets uses the font 
size from the Fonts Preferences dialog, and contrary to expectations, those 
sizes are pixels, not points. I notice that nsPresContext::GetFontPreferences
() looks at the font.size.unit pref to interpret font sizes that don't have an 
explicit unit--if I set it to "pt", my 133dpi screen is actually legible :)

I don't know what the right fix for this is, but I do know that users don't 
want to specify font sizes in pixels: the font size set by the Fonts 
Preferences dialog should be in points.

This probably explains why the Unix Xlib version seems to ignore the screen 
resolution setting too.

	timeless
	Comment 10 • 23 years ago

there's a bug to change the font preferences panel behavior, i'll encourage rbs 
to comment about it.

	David Baron :dbaron: Assignee
	Comment 11 • 23 years ago

This pref should do something on at least Mac and Unix (it's arguable whether we
should have it on Windows), and I know it used to work.  It's currently
implemented on the GTK, Mac, BeOS, Photon, QT, and Xlib ports.

However, I can also say that it's currently broken on GTK.

	David Baron :dbaron: Assignee
	Comment 13 • 23 years ago

We still have the problem that we won't pick up the pref changed callback after
the first device context goes away.  I'm still thinking about the best way to
fix that...

	Javier Pedemonte
	Comment 15 • 23 years ago

Shouldn't the handling of this preference be in nsFontMetrics, since it applies
mainly to fonts?  Since it is in the fonts preference panel, I expect the size
of fonts to change when I change this preference, but I don't expect the size of
the dialogs and windows to also change.  It seems to me that the latter is what
some people are hinting at with regards to this pref.  If it's only for fonts,
then I would expect it to be handled in nsFontMetrics.

	David Baron :dbaron: Assignee
	Comment 16 • 23 years ago

This is for anything sized in physical units.  Our dialogs shouldn't have
anything that uses physical units, and they really should never be used for
screen media.  This pref is a workaround for the fact that many Web authors
don't know that.

	timeless
	Comment 17 • 23 years ago

why are you casting to (void*)?

	Brian Ryner (not reading)
	Comment 18 • 23 years ago

r=bryner

	David Baron :dbaron: Assignee
	Comment 19 • 23 years ago

taking

	David Baron :dbaron: Assignee
	Comment 20 • 23 years ago

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

	David Baron :dbaron: Assignee
	Comment 21 • 23 years ago

I think the long-term solution is to move the code implementing this into the
cross-platform nsDeviceContext.  However, I want to get attachment 46928 [details] [diff] [review] in to
get this working for 0.9.4.

	Chris Waterson
	Comment 22 • 23 years ago

sr=waterson

	David Baron :dbaron: Assignee
	Comment 23 • 23 years ago

Actually, I changed my mind about wanting to get this in for 0.9.4.  It hasn't
worked for a while, so we don't really know whether it does bad things or not. 
If anyone disagrees, I'll just push this out and try to come up with the real
fix later...

	David Baron :dbaron: Assignee
	Comment 24 • 23 years ago

Oh, and I forgot to mention, I checked in the GTK fix (attachment 46928 [details] [diff] [review]) last night.

	Igor Pruchanskiy
	Comment 25 • 23 years ago

Slackware Linux with xfree86 4.1.0.
install of 0.9.5 borked fonts and made then _really_ small....
I am using 1920x1440 screen resolution and it made the fonts completely
unreadable. Going back to 0.9.4 with the same prefs.js works fine.
0.9.5 does not, i can deal with 0.9.4 for a while but Ctrl+T in 0.9.5 rocks my
world... Btw, changing browser.display.screen_resolution does not do anything...

	Deven Corzine
	Comment 26 • 23 years ago

I don't understand this (it doesn't make sense), but the patch in attachment
46928 [details] [diff] [review], checked in as revision 1.80 of gfx/src/gtk/nsDeviceContextGTK.cpp,
SOMEHOW caused (or at least triggered) bug 103145.  Reversing the patch on the
current version of the code in CVS "fixes" that bug, or more likely masks a
deeper bug of some sort.

I know it appears impossible on the surface.  A seemingly-innocuous change to
the SetDPI() calls in nsDeviceContextGTK.cpp somehow causes wildly inappropriate
scaling values to be generated by gfx/src/ps/nsPostScriptObj.cpp when printing
images to a PostScript file or printer.

I wish someone could explain this, because currently I can't.  It's very complex
and difficult to backtrace where the values are coming from when printed, yet
that bug is only exhibited when the patch for this bug is applied.  I agree in
advance that it's counterintuitive and it shouldn't happen, yet I have verified
conclusively that it does.

Can anyone here explain what's going on?  (You might want to reference my notes
under bug 103145 for more information...)

	Deven Corzine
	Comment 27 • 23 years ago

I've determined that I can only replicate bug 103145 with settings from 71 dpi
to 73 dpi; 70 dpi and under don't trigger that bug and neither do 74 dpi and up.
 Since the code from before this patch effectively left mozilla always using 96
dpi regardless of the setting of browser.display.screen_resolution, that bug was
never seen until this one was fixed.

I still don't know why this GTK code affects the PostScript printing, and I
don't think this "screen resolution" value should affect printing size, but
maybe that's another bug...

	David Baron :dbaron: Assignee
	Comment 28 • 23 years ago

Please discuss bug 103145 on bug 103145, not here.

	HARUNAGA Hirotoshi
	Comment 29 • 22 years ago

Mac build has same problem.
FreeBSD build has no problem.

	Felix Miata
	Comment 30 • 22 years ago

OS/2 offers a functional choice between "system setting", 96, & 120.

	Felix Miata
	Comment 31 • 21 years ago

This probably should be changed from Win98 to all, since more than just it is
affected. Comment 30 was made obsolete shortly after I made it. Mike Kaply made
the OS/2 ports behave just like the Win ports, getting DPI from the system and
ignoring the pref setting.

RedHat/Fedora is badly impacted by the use of this pref. I filed a Fedora Core
bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107803 even though some
think the problem is Mozilla rather than RedHat/Fedora. In that bug's 1.4.1-7
http://www.mozilla.org/ screenshot attachments
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=95414&action=view and
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=95415&action=view you can
see that some fonts (pt sized) are the same, while others (e.g. x-small) are
_smaller_ at _higher_ DPI.

http://www.mozilla.org/ uses points mostly for font sizing. Bad, bad, bad.
Someone on the Mozilla.org payroll needs to point Ben Goodger (that page's
author, already cc'd here, and who if I'm reading what I think I am in this
bug's activity, was this bug's previous assignee) and Dave Shea (author of its
tentative replacement) to comment 16, or find a new author that understands and
uses it.

	Stefan Borggraefe
	Comment 32 • 21 years ago

So what is the right fix here? Just hide the pref-UI for Mac, OS/2 and Windows?
 This should be easy with the XUL-preprocessor.

Is there a way to get the system's resolution setting for all platforms? In this
case I would vote for removing the pref altogether and always use the system's
value, since Mozilla runs on the same display as all the other applications, or? ;-)

	Scott Richesson
	Comment 33 • 21 years ago

I have Windows XP, a very high resolution LCD (1920x1200), Gforce Go 5200, DPI
set to 144.  IE is working fine.  Mozilla is basically unusable, because the
fonts are microscopic.  Changing the minimum font size in Mozilla to 24 or so
produces a readable font, but web pages look horrible.  I have tried various
values for the display resolution in Mozilla.  Nothing has any effect. 
Unfortunately, I have to go back to IE until this is fixed.  Thanks.

	Felix Miata
	Comment 34 • 21 years ago

Scott, which fonts are you having a problem with? Is what you see on XP
different from this? What happens if you set XP to 168 (175%) or 192 (200%)
DPI? I can't see much difference between IE and Mozilla. For us to see what you
see we either need example URLs or screenshot(s) or both.

	David Baron :dbaron: Assignee
	Comment 35 • 21 years ago

comment 33 and comment 34 are not related to this bug and should be discussed
elsewhere.

	Owen Marshall
	Comment 36 • 20 years ago

This bug still exists in the Windows version of Firefox 1.0 (running under
WinXP) (it does not affect the linux build).  There are two issues here: first,
that Firefox does not recognize the Windows system default resolution (set in
Display Properties -> Settings -> Advanced -> General -> Font size); second,
that even setting the "display resolution" setting in the Firefox preferences
correctly and then restarting the browser still does not change either the UI
font size or the page font size.

This is not a problem with 1024x768 resolution, but on modern laptop SXGA
screens (1400x1050) it makes Firefox basically unusable as the UI fonts are
unreadably small.  This is an issue that is going to become increasingly
annoying as higher resolution screens become more popular!

(In contrast, IE and other Windows applications detect the system DPI setting
and display correctly.)

	David Baron :dbaron: Assignee
	Comment 37 • 20 years ago

The problem described in this bug isn't that we don't detect the system display
resolution; it's that we don't allow the user to override it.

	Owen Marshall
	Comment 38 • 20 years ago

> The problem described in this bug isn't that we don't detect the system display
> resolution; it's that we don't allow the user to override it.

Erm ... from the initial bug description: 

"The default value for pref browser.display.screen_resolution is 96 dpi. This is
fine when using Windows Small Fonts, which is 96 dpi. When I use a screen
resolution 1280x1024 Large Fonts (120 dpi), text on many web pages becomes
unreadably small."

i.e. the display resolution that the user had set (120 dpi) was not detected.

Not detecting the system resolution is a problem; but not allowing the user to
override it is a far bigger problem (as without the system display resolution
being detected, the finer the resolution the more unreadable the UI fonts
become).  Personally it doesn't affect me as I use Linux, which scales the fonts
just fine.  But I had to recommend to a Windows user that they use IE over
Firefox the other day simply because the Firefox interface font was impossibly
small at 1400x1050, and that hurt!  This issue isn't one that's going to go away
- many laptops are now being made with SXGA screens and I'm sure desktop LCD
monitors can't be far behind.  (This is exactly the same problem as described in
Comment 33)

Is there any move to implement this feature in Windows?  I notice in Comment 11
that the appropriateness of this preference option in Windows is questioned,
without any explanation as to why it would not be usefull.

	David Baron :dbaron: Assignee
	Comment 39 • 20 years ago

That statement in comment 0 is not true and has not been for a long time. 
nsDeviceContextWin::CommonInit initializes mPixelsToTwips based on
::GetDeviceCaps(aDC, LOGPIXELSY).  It's only the pref that allows the user to
override the system that's not implemented.

	Joshua Weage
	Comment 40 • 19 years ago

This bug still exists in 1.0.4 on Windows XP.  User defined display resolution
does nothing, as apparently it should according to the comments here, so remove
the option from the fonts panel as it just confuses users!

The second problem is that Windows users select fonts based on points, not
pixels, so unless they read very closely, the font size selection doesn't do
what they expect.  This should be changed to Points in the Windows (and maybe
all) version.

	Felix Miata
	Comment 41 • 19 years ago

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

	Hiro
	Comment 42 • 19 years ago

FYI.
Today, UI removed.(bug326329)

	Felix Miata
	Comment 43 • 16 years ago

layout.css.dpi replaced browser.display.screen_resolution in bug 327406 so either this summary should be changed and bug 477213 duped to this, or this should be expired and bug 477213 confirmed. This applies also to W2K & WXP, not just Win9x.

	Felix Miata
	Comment 44 • 13 years ago

versions supporting browser.display.screen_resolution have been out of support for years -> INVALID