Closed
Bug 333970
Opened 19 years ago
Closed 14 years ago
Text sized in pts different size in cairo vs. non-cairo
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: aguertin+bugzilla, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(4 files, 2 obsolete files)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060413 Firefox/3.0a1
Text sized in points (pts) is larger in cairo builds than non cario builds. Text sized in px, with a keyword, or not sized at all is identical.
This affects all fonts, or at least all that I've seen.
Builds tested were 20060406 (non-cairo) and 20060413 (cairo), both on the same Gentoo Linux system.
Testcase coming.
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
DOM Inspector shows a computed font-size of 26.6667px in pre-cairo builds but 33.3333px in cairo builds.
Confirming using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060413 SeaMonkey/1.5a
Also, Cairo build selects sans-serif font by default when rendering testcase (using new profile). Plain gtk2 build uses serif font.
Actually, I'm holding back my confirmation. Using DOM inspector, I see that the computed font-size's are equal in both builds: 30.7692px, as well as font-family: serif. But because of visual difference of sans-serif font cairo build has choosen, it looks like the font sizes are different.
Updated•19 years ago
|
Comment 5•19 years ago
|
||
Attached a screenshot of a Cairo (and Pango) build rendering of the testcase.
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060418 Firefox/3.0a1 - Build ID: 0000000000
Comment 6•19 years ago
|
||
Is this still an issue in today's builds? If so:
1) Are you running GNOME?
2) What version of pango are you using?
3) What's your X server DPI
4) What's your Mozilla DPI pref set to, if anything?
Reporter | ||
Comment 7•19 years ago
|
||
1) Yes
2) 1.10.3 (Gentoo default, don't know what if any patches it comes with)
3) $ xdpyinfo | grep resolution
resolution: 123x127 dots per inch
4) filtering about:config for dpi only gives layout.css.dpi default integer -1
Comment 8•19 years ago
|
||
What does:
xrdb -query | grep dpi
output?
Note that 20pt at 96 dpi is 20 / 72 * 96 = 20 / 3 * 4 = 26.666667px
while 20pt at 120 dpi is 20 / 72 * 120 = 20 / 3 * 5 = 33.333333px
Your actual screen dpi is pretty close to 120. So it might be that our idea of what your DPI is has changed; that would be consistent with the numbers you see.
Reporter | ||
Comment 9•19 years ago
|
||
$ xrdb -query | grep dpi
Xft.dpi: 96.000000
Comment 10•19 years ago
|
||
Weird... Given that, we should totally be ending up with the 26.6667px value.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.9a1?
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Comment 11•18 years ago
|
||
dolphinling, what window manager are you using? Do you get this problem with other window managers? Apparently, at least sometimes we now rely on window properties for DPI stuff...
Reporter | ||
Comment 12•18 years ago
|
||
My window manager is metacity. I don't have any others installed right now, but if it'll help I could.
Comment 13•18 years ago
|
||
No, that shouldn't be necessary, since that's the default GNOME window manager...
Reporter | ||
Comment 14•18 years ago
|
||
I am now very confused. Compare the following two testcases:
data:text/html,<style>.pt{font-size:12pt;} .px16{font-size:16px;} .px20{font-size:20px;}</style><p class="pt">This text is 12 pts</p><p class="px16">This text is 16px</p><p class="px20">This text is 20px</p>
data:text/html,<style>.pt{font-size:18pt;} .px24{font-size:24px;} .px30{font-size:30px;}</style><p class="pt">This text is 18 pts</p><p class="px24">This text is 24px</p><p class="px30">This text is 30px</p>
The second is merely a larger version of the first: the scale for each line is identical.
In firefox 2, the first and second lines are identical in both testcases, and the DOM inspector reports identical computed font sizes for them. The third line is bigger.
In minefield, in the first testcase DOMI reports computed font sizes of 18.6667px, 16px, 20px, and renders lines one and three the same. In the second testcase it reports computed font sizes of 28px, 24px, and 30px, and renders lines one and two the same.
I have no idea where the 18.6667 / 28 number is coming from, but at least the ratio is consistent: it's 7/6ths of the smaller px value, which is 14/15ths of the larger one.
Also, even stranger, when I increase or decrease the font size with Ctrl-+ or Ctrl--, the pts line alternates between displaying the same size as each of the px lines, although for the smaller testcase one time it displays a size between the two.
Reporter | ||
Comment 15•18 years ago
|
||
I forgot to mention, the info requested earlier has changed slightly:
Pango is now version 1.14.9
xdpyinfo | grep resolution has gone to 122x122 dpi (from 123x127)
xrdb -query | grep dpi still gives 96.000000
Comment 16•18 years ago
|
||
(In reply to comment #14)
> In minefield,
which version, exactly? (build id?)
Reporter | ||
Comment 17•18 years ago
|
||
Er, sorry, current trunk
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070212 Minefield/3.0a3pre
(I keep forgetting to post that... :( )
Reporter | ||
Comment 18•17 years ago
|
||
This may have been fixed with the cairo 1.5 landing. It's hard to tell because a lot of text just flat-out won't display with cairo 1.5 (see bug 390787) but I'm making a better testcase and will attatch screenshots.
Reporter | ||
Comment 19•17 years ago
|
||
This testcase has a number of different size fonts. As far as I can tell, one pt = 1/72 inch, and one px = 1/96 inch, so one pt = 4/3 px.
The underlines are there only to facilitate checking.
Attachment #218405 -
Attachment is obsolete: true
Attachment #218887 -
Attachment is obsolete: true
Reporter | ||
Comment 20•17 years ago
|
||
I'm not able to get a screenshot of a current build with cairo 1.5, but it turns out that it did NOT change then. However, it did change sometime in the past--but is still incorrect. I'll work on finding out when it changed (may have been when I changed something on my system).
Reporter | ||
Comment 21•17 years ago
|
||
So indeed it has changed several times, and has gotten progressively worse. I tested with 18.75pt text, which should be 25px. With nightlies up until the 2007-02-06-04 nightly, it was 31.25px. From 2007-02-07-04 until 2007-02-27-04 it was 32.0333px, and starting with 2007-02-28-04 it was 40.5px (and still is).
The first change, from 31.25 to 32.0333, was almost certainly because of bug 177805 Fix the use of units in Gecko.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-06+03&maxdate=2007-02-07+05&cvsroot=%2Fcvsroot
For the second change, from 32.0333 to 40.5, I can't see what caused it:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-27+03&maxdate=2007-02-28+05&cvsroot=%2Fcvsroot
Reporter | ||
Comment 22•17 years ago
|
||
Comment 23•17 years ago
|
||
Eli, any idea what's going on here?
Reporter | ||
Comment 24•17 years ago
|
||
I don't know if we have any reftests that cover this (and the testboxen just don't hit this bug), but if not here's a pair of pages that should be identical. I didn't check pixel for pixel, but I did flip back and forth in Firefox 2 and to my eye they were the same. And theoretically, of course, they *should* be.
Reporter | ||
Comment 25•17 years ago
|
||
So I think this was somehow fixed by bug 379886 (???!). It's fixed between 2007-08-26-04 and 2007-08-27-04, and I can't see anything else that would have done it. Does that make sense to anyone?
Comment 26•17 years ago
|
||
Comment 27•17 years ago
|
||
Is it a matter of which font is used or something? Did the font being used change with that checkin? The patch changed font default prefs...
Reporter | ||
Comment 28•17 years ago
|
||
Yes, it looks like the font did change. I'll see if I can figure out what font the old one used and if it's still a problem with that font.
Reporter | ||
Comment 29•17 years ago
|
||
Okay, what?? The old builds now pass the testcase too. They have the old font, but it's sized correctly.
Checking if I changed something on my system around that time...
Reporter | ||
Comment 30•17 years ago
|
||
Pango was upgraded from 1.16.4 to 1.16.5.
The changelog [1] doesn't give any reason that would have fixed it, and I don't have time right now to try reverting, but I'll check later.
[1] http://svn.gnome.org/viewcvs/pango/tags/PANGO_1_16_5/ChangeLog?view=log&pathrev=2381
Reporter | ||
Comment 31•17 years ago
|
||
Confirmed that reverting to pango 1.16.4 shows the bug again. Do we want to bother figuring out why, or just resolve this?
Comment 32•17 years ago
|
||
Given that we support pango versions before that one, might be good to figure out why, yes. That is, if it's a pango bug maybe we can work around it. And maybe it's a bug in the way we use pango.
Reporter | ||
Comment 33•17 years ago
|
||
http://ftp.gnome.org/pub/GNOME/sources/pango/1.16/pango-1.16.5.changes seems to be just the changes since 1.16.4 (still don't see anything that looks like it would fix this).
Cc'ing behdad on this, in case he has any ideas (he's the pango maintainer)
Comment 35•17 years ago
|
||
No idea what may be causing that. Lets get back to this after the pango patch I'm working on now lands.
Reporter | ||
Comment 36•17 years ago
|
||
It'd be good to have this in the testsuite, even if we didn't do anything to "fix" the bug.
Flags: in-testsuite?
Comment 37•17 years ago
|
||
I tried checking in a reftest for this, and it failed on Linux (centos5), which presumably doesn't have a new enough pango.
I've marked the test random on Linux for now, but once this bug is fixed we should make it run on Linux and set this bug as in-testsuite+.
Behdad, any idea when you'll be able to look at the pango end of things here?
Comment 38•17 years ago
|
||
Humm, helps if someone confirms the bug with latest builds first. Currently we are using gdk_pango_context_get(), which means it should pick up the right dpi, however, we're also using pango_font_description_set_absolute_size() only (as opposed to pango_font_description_set_size()), so whatever dpi pango sees is bypassed anyway. Here's the code:
mPangoFontDesc = pango_font_description_new();
pango_font_description_set_family(mPangoFontDesc, NS_ConvertUTF16toUTF8(mName).get());
gfxFloat size = mAdjustedSize ? mAdjustedSize : GetStyle()->size;
pango_font_description_set_absolute_size(mPangoFontDesc, size * PANGO_SCALE);
pango_font_description_set_style(mPangoFontDesc, ThebesStyleToPangoStyle(GetStyle()));
pango_font_description_set_weight(mPangoFontDesc, ThebesStyleToPangoWeight(GetStyle()));
//printf ("%s, %f, %d, %d\n", NS_ConvertUTF16toUTF8(mName).get(), GetStyle()->size, ThebesStyleToPangoStyle(GetStyle()), ThebesStyleToPangoWeight(GetStyle()));
mPangoCtx = gdk_pango_context_get ();
So, is GetStyle()->size supposed to be in points or pixels? If pixels, I don't see anything wrong here.
Comment 39•17 years ago
|
||
> Humm, helps if someone confirms the bug with latest builds first
See comment 37. That reproduced the bug with the tinderbox builds on CentOS 5 last night.
The documentation for GetStyle()->size says:
95 // The logical size of the font, in pixels
What's really interesting, really, is that the 1.16.4 to 1.16.5 update changes the behavior...
Comment 40•17 years ago
|
||
No idea then. I don't see anything between 1.16.4 and 1.16.5 that can cause this...
Comment 41•17 years ago
|
||
dolphinling, do you think you can add some printfs to the quote Behdad quoted and see what it's up to with the older pango and how that compares to the newer one?
Comment 42•17 years ago
|
||
As far as I tested 2007102304 trunk on Fedora 7, attachment 275544 [details] and attachment 275546 [details] have the same view.
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Comment 43•17 years ago
|
||
I don't know whether it's needed, but I can confirm this bug still exists on Ubuntu Gutsy with the latest beta of FF3 (b3).
Here's a simple test page I've made: http://www.silent-blade.org/test.html
FF2: http://www.silent-blade.org/FF2.png
FF3: http://www.silent-blade.org/FF3.png
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3
I almost marked this as WFM, and then realized I was on Windows. We've changed font code a bunch in the last 2.5 years, does this still reproduce for people on X?
Reporter | ||
Comment 45•14 years ago
|
||
I've seen nothing in a long time to indicate that I'm getting incorrect font sizes. The tests I posted long ago seem to pass. Pango 1.16 is not in any currently available Ubuntu release, even the LTS.
As far as I'm concerned, it's WFM.
The reftest is still marked random. That should be changed.
http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/reftest.list#402
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Comment 46•14 years ago
|
||
Enabled test on Linux. in-testsuite on all platforms now.
http://hg.mozilla.org/mozilla-central/rev/60eedb77a169
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•