Closed Bug 384090 Opened 17 years ago Closed 16 years ago

[GTK+] incorrect logical resolution for converting font sizes in pt, etc.

Categories

(Core :: Graphics, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: marek78uk, Assigned: caillon)

Details

Attachments

(4 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070611 Minefield/3.0a6pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070611 Minefield/3.0a6pre

I have just downloaded and started the newest version of Firefox - on various pages the font sizes are different from what I was expecting. What I have noticed - when the font is specified in px, it is shown properly, but if it is specified in pt/em/whatever except px, it has incorrect size. Usually serif font is too big, monospaced font is to small.

I have also started newest firefox with a clean profile and the result is exactly the same. What I have noticed ealier - after upgrade of my Fedora from version 6 do version 7, shipped firefox version 2.0 has similar bug - serif font is slightly bigger, but monospaced font is too small.

Reproducible: Always

Steps to Reproduce:
Go to any website, for example http://jakilinux.org/ 
Actual Results:  
the font size is bigger then expected

Expected Results:  
smaller, proper size font

my screen resolution is 1440x900px, I am using Gnome version 2.18.1 (shipped with Fedora 7), font settings are:

Application font: Sans, 8pt
Document font: Sans, 8pt
Desktop font: Sans Bold, 10pt
Window title font: Sans Bold, 10pt
Fixed width font: Monospace, 8pt

I haven't had changed any font settings in a browser.
probably Core > Layout: Fonts
Component: General → Layout: Fonts and Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
This is the reporter's screenshot he posted in a comment to my blog:
http://pub.matulka.net/f2vsf3a.png
Firefox 2.0.0.4 (from ftp.mozilla.org) on the left vs Firefox 3alpha 20070709 on the right.

TinyMCE uses iframe to render editor's content, so its content is independent from site html/css - as you can see, in latest Firefox fonts are bigger then they should be. And also they are rendered in different way.

I use Fedora 7, screen resolution is 1440x900.
I can't reproduce this on Mac, so it might be Linux only.

jakilinux.org breaks for me on a 3.0a7 nightly, but font sizes seem to be the same.

I'll try to reproduce it on Linux later today.
I have prepared a test case (screenshot shows a result).

test case is accessible at http://pub.matulka.net/fontcase/ - it's a simple and valid html with one tiny mce - as you can see font sizes are different in both Firefox 2.0.0.4 and latest Minefield.
Attachment #271585 - Attachment is obsolete: true
Version: unspecified → Trunk
Comparision of font size rendering between Gran Paradiso Alpha 7 and Firefox 2.0.0.6
Ok, I can see the problem is ignored by mozilla dev team, but I have actually found a solution.

1. Go to the about:config page

2. find layout.css.dpi

3. change the value to 96

4. reload page and voila - correct font sizes :) although it still renders ugly fonts (ugly windows-style, while I prefer mac-style font rendering - more information can be found here: http://antigrain.com/research/font_rasterization/index.html )

my solution is based on: http://kb.mozillazine.org/Layout.css.dpi

now my confusion is - why it happened? because I have a screen resolution 1440x900 and screen size 14 inches? or maybe it is a problem with Fedora default settings? in my opinion browser should always use default value which is 96 and allow change of this if user wants it. Unfortunately it the ability to set up dpi was removed in Firefox 2.0.
WFM per reporter's comment 7.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
It's not fixed as it makes pages look incorrectly in certain cases (small screens with larger resolutions) and it doesn't answer my question too.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Hi,
What version of Pango do you have?
Pango versions before 1.16.5 have known problems with text size in some cases, see bug 333970. Can you try upgrading to pango 1.16.5 or newer, and if so, does that fix the problem?
it was 1.16.4 so I have upgraded it to 1.18.1 and problem remains.


with layout.css.dpi set to -1 Firefox thinks it's 120 dpi

with layout.css.dpi set to 0 it's the same

with layout.css.dpi set to 96 I get correct font sizes, now also monspaced fonts have correct size, as they were too small before upgrade of Pango.

in the font preferences I have dpi set to 96 so I don't know why Firefox still thinks, I should have 120 dpi...

My screen size is 14", resolution is 1440x900.

and also - how to change ugly font rendering to the nice one? :) as you can see on attached screenshots (or here: http://pub.matulka.net/Firefox-vs-Minefield.png ) new Firefox renders fonts in a different (ugly for me) way, the latest version is even worse unfortunately :(
(closing the downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=244384 against this one)
It is probably worthy to note, that reporter's meaning of ugly is "different/too strong hinting than with the rest of the desktop".
This bug is definitely real. I opened an html file containing
<span style="font-family:serif; font-size:14pt">This should be 14-pt DejaVu Serif</span>
in current Minefield, Firefox-2, and Konqueror-3.5.9. I also wrote some 14-pt serif text in a bunch of Gnome and KDE apps (Tomboy, Gedit, Kate). Now, look at the resulting screenshot.

It's obvious that Minefield renders text at the wrong DPI, compared to every other application on the Linux desktop.
We intentionally handle conversion from physical units (e.g., points, which are 1/72 of an inch) to pixels using the larger of 96dpi or the resolution used by GNOME, since many Web pages are written assuming Windows's behavior of 96dpi.

However, that's not related to this bug, which is about *random* behavior, so it doesn't belong here.
Er, sorry, I assumed the bug was about what the summary said.

Is this still present in betas of Firefox 3?  I think a bunch of issues like this were fixed.  (It doesn't help that there are half a dozen different ways to get the DPI within the GTK+/pango/Xft/X stack and they often yield different results.)
Er, sorry, you're already talking about Firefox 3.

Anyway, moving to the right component, and going to sleep before I say anything else silly.
Component: Layout: Fonts and Text → GFX: Thebes
QA Contact: layout.fonts-and-text → thebes
Summary: Wrong font sizes displayed on websites randomly → [GTK+] incorrect logical resolution for converting font sizes in pt, etc.
(In reply to comment #15)

This bug is present in the latest nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040304 Minefield/3.0pre
and it has definitely been there since before beta4.

As for the bug description, "random" is a very good way of describing the effect: font sizes that are specified in pixels are rendered like in all other browsers, while fonts that are in points are suddenly 25% larger. And many people mix pixels and points in their stylesheets.
This is a feature, not a bug.  Just because windows fixes resolution at 96 doesn't mean firefox should do the same.  Having reliable resolution-independent fonts (and graphics) is a must as we see more high-res lcd panels.  The OLPC screen for example is 200dpi.  A 12px or a 10pt at a fixed 96 dpi setting is simply unreadable there.  How many websites set their text font to 24pt?

If you don't like what you are getting, just set your X resolution to 96.
There are couple of issues here, some of them - they are already sorted, others not.

First issue - font to large with dpi set to -1 - it can be simply changed to 96 and everything looks ok. Got that already and understand why it has to be like that.

Second issue - Firefox 3 uses broken pango to render fonts - on windows everything looks fine, pango serves Helvetica as Helvetica, but on Linux (Fedora, Ubuntu) pango serves wrong fonts (for serif, sans-serif) - simple example - wikipedia.org - it looks totally different in Firefox 2 and Firefox 3 (on linux) - especially on linux it looks really odd, when system is reporting for example 120dpi.

Third issue - Firefox 3 uses bronek pango which renders fonts incorrectly - I mean there subpixel hinting - it looks totally awful - new pango's "slight" looks like almost **** default Fedora 8 installation, I am not sure if new Firefox actually uses settings from the system and just renders in its own way.

Overall, Firefox 3 on Windows works flawlessly, but on Linux it has issues with font rendering. I am sure they are not going to be resolved before final release and it's a real pity as for me it's quite difficult to use latest Firefox.
(In reply to comment #18)
> The OLPC screen for example is 200dpi.  A 12px or a 10pt at a
> fixed 96 dpi setting is simply unreadable there.  How many websites set their
> text font to 24pt?

May I suggest that since there are hundreds of millions of 133dpi LCD panels out there in the real world, and only half a million OLPCs, perhaps Firefox's defaults should cater to the former and not to the latter?

> If you don't like what you are getting, just set your X resolution to 96.

Well, the correct way to set font DPI on the Linux desktop is with the 
/desktop/gnome/font_rendering/dpi
gconf key. Mine is set to 96.0 - and that value is picked up by all Gnome and gtk programs.

I think the *correct* way to solve this issue is for Firefox to read this gconf key, and use its value when layout.css.dpi is set to -1.
(In reply to comment #20)
> (In reply to comment #18)
> > The OLPC screen for example is 200dpi.  A 12px or a 10pt at a
> > fixed 96 dpi setting is simply unreadable there.  How many websites set their
> > text font to 24pt?
> 
> May I suggest that since there are hundreds of millions of 133dpi LCD panels
> out there in the real world, and only half a million OLPCs, perhaps Firefox's
> defaults should cater to the former and not to the latter?

This is missing the point.  I use a 120dpi panel myself.  And hardcoding to 96 make the fonts too small for me.

> > If you don't like what you are getting, just set your X resolution to 96.
> 
> Well, the correct way to set font DPI on the Linux desktop is with the 
> /desktop/gnome/font_rendering/dpi
> gconf key. Mine is set to 96.0 - and that value is picked up by all Gnome and
> gtk programs.
> 
> I think the *correct* way to solve this issue is for Firefox to read this gconf
> key, and use its value when layout.css.dpi is set to -1.

That's a useful thing to do, yes.

(In reply to comment #20)
> (In reply to comment #18)
> > The OLPC screen for example is 200dpi.  A 12px or a 10pt at a
> > fixed 96 dpi setting is simply unreadable there.  How many websites set their
> > text font to 24pt?
> 
> May I suggest that since there are hundreds of millions of 133dpi LCD panels
> out there in the real world, and only half a million OLPCs, perhaps Firefox's
> defaults should cater to the former and not to the latter?
> 
> > If you don't like what you are getting, just set your X resolution to 96.
> 
> Well, the correct way to set font DPI on the Linux desktop is with the 
> /desktop/gnome/font_rendering/dpi
> gconf key. Mine is set to 96.0 - and that value is picked up by all Gnome and
> gtk programs.
> 
> I think the *correct* way to solve this issue is for Firefox to read this gconf
> key, and use its value when layout.css.dpi is set to -1.
> 

I vote for that solution - Firefox *shoud* read this gconf key.
Firefox doesn't use gconf.  But I believe there's an XSETTING for this that gnome-session sets and gtk+ reads.  Simply use gdk_screen_get_resolution().
I don't exactly know, how firefox works. I've been reading about ongoing integration with Gnome desktop, so I wish Firefox could read a gconf property.

When I run Fedora for the first time, it sets screen dpi to 121 dpi so I am changing that in fonts properties to 96. All fonts are getting smaller - I've changed that, so they did what I expected them to do. Now I wish Firefox could do the same - just read this settings and that's it. If not, I still need to set dpi within firefox, which is fine, but not perfect (lack of integration with a desktop).

What about other issues? what about bronek pango? is it going to be fixed any time soon? It is ridiculous that on Windows Firefox works fine, but on linux it renders fonts in a different, incorrect a unwanted way.
Marek, you have been repeating those words again and again and again.  We typically understand on the first read.  Repeating doesn't help.  Just makes people like me ignore the bug.  That's what I did with your Fedora report.

If firefox doesn't render fonts the way you want, that's another issue that doesn't belong in this bug.  Period.
I am repeating, because a) I haven't got any info about when it is going to be fixed or why it is not going to be fixed b) it is an important issue for me.

If you want, I will file a new bug for it.

If I am adoing anything wrong, just put it in words. I hate being ignored, but I can see, mozilla developers can do only that - to ignore users. I repeated that many times, that I am happy to help, give information, etc. But I need to know what to do.

Thanks for ignoring me :-/
Don't take it personally dude.  There are millions of users, thousands of bugs open, and just so many developers.  The ones that are relevant to a specific bug are probably in the numbers like 2 or 3.  And they are either doing this on their volunteer time or are paid to do what their employer wants them to do.

Just because you use firefox and love it doesn't mean developers owe you anything btw.  You reported the bug.  Thank you.  It will be processed when it will be processed.  That's why bugzilla is there, to keep track of issues.  If every bug was to be processed as soon as reported, an email alias could do as well.
Now, back to figuring out how to set the resolution...

(In reply to comment #23)
> Firefox doesn't use gconf.  But I believe there's an XSETTING for this that
> gnome-session sets and gtk+ reads.  Simply use gdk_screen_get_resolution().

No, this doesn't work. On both of my systems (one is 98dpi, the other is 129dpi), both in gnome and in a failsafe X session, gdk_screen_get_resolution() returns -1. And pango_cairo_context_get_resolution() also returns -1.

So there must be some other mechanism for getting font dpi.
Attached patch Possible patch for this (obsolete) — Splinter Review
If you're getting -1, you probably haven't run gtk_init() yet.  Adding this bit of code should force the issue, and get the correct value.  I think this might also be a more correct fix for bug 394103, and in fact, this fix might not be visible on screens under 192dpi without first reverting that.
Attachment #316261 - Flags: superreview?(roc)
Attachment #316261 - Flags: review?(mozilla)
I see. I did run gtk_init(), but I didn't know I had to also run gtk_settings_get_for_screen() before using gdk_screen_get_resolution().

I tested your patch on 3.0-beta5, seems to work fine. Fonts are the correct size now. Thank you for fixing this!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 316261 [details] [diff] [review]
Possible patch for this

As pointed out by Owen on IRC, should round the double instead of plain cast.  Other than that, looks good.
Attachment #316261 - Flags: review?(mozilla) → review+
Comment on attachment 316261 [details] [diff] [review]
Possible patch for this

Do the rounding, and if you need a cast use a PRInt32() constructor-style cast. The (void) is really not necessary either.
Attachment #316261 - Flags: superreview?(roc) → superreview+
(In reply to comment #29)
> Created an attachment (id=316261) [details]
> Possible patch for this
> 
> If you're getting -1, you probably haven't run gtk_init() yet.  Adding this bit
> of code should force the issue, and get the correct value.  I think this might
> also be a more correct fix for bug 394103, and in fact, this fix might not be
> visible on screens under 192dpi without first reverting that.

Actually I think this fix *will* affect screens under 192dpi, because any change in DPI values will affect the sizing of lengths in physical units, including 'pt'.
Carrying over reviews, and seeking approval.  Low risk patch verified to fix the problem (comment 30).
Assignee: nobody → caillon
Attachment #316261 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #317780 - Flags: superreview+
Attachment #317780 - Flags: review+
Attachment #317780 - Flags: approval1.9?
Is there a test?

re-request approval once addressed.
Attachment #317780 - Flags: approval1.9?
We can't write an automated test for this.

A manual Litmus test would be:
-- Set /desktop/gnome/font_rendering/dpi to 192 in gconf-editor
-- Restart Firefox
-- Ensure that all icons and other UI have doubled in size
Flags: in-testsuite-
Flags: in-litmus?
Comment on attachment 317780 [details] [diff] [review]
Updated to comments

a1.9+=damons
Attachment #317780 - Flags: approval1.9? → approval1.9+
Checking in nsThebesDeviceContext.cpp;
/cvsroot/mozilla/gfx/src/thebes/nsThebesDeviceContext.cpp,v  <--  nsThebesDeviceContext.cpp
new revision: 1.77; previous revision: 1.76
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → FIXED
great.  i wonder what all the linux users that don't use gnone will do.
Yeah, Not a gnome user myself. I did not see a problem installing gconf-editor though hoping I would only have to do this once. I do not see /desktop/gnome/font_rendering/dpi though. I also see no way of adding this if its missing either. Have to assume you only see this if you are running gnome? Really need a friendly way of handling this. Firefox does not respect dpi settings in Xdefaults?

Xft.dpi: 96 



Firefox-3 (now that the patch is applied) will behave like Gtk, i.e. it will read the font dpi from any standards-compliant XSETTINGS manager. If Gtk programs have the right font dpi on your system, then so will firefox.

As for the gconf key, it won't help you unless you are also running gnome-settings-daemon (the default XSETTINGS manager for the Gnome desktop).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: