333970 - Text sized in pts different size in cairo vs. non-cairo

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[dolphinling]

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.

Comment 1

[dolphinling]

Attachment: testcase

Comment 2

[dolphinling]

DOM Inspector shows a computed font-size of 26.6667px in pre-cairo builds but 33.3333px in cairo builds.

Comment 3

[kmike]

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.

Comment 4

[kmike]

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.

Comment 5

[Philip Withnall (unavailable)]

Attachment: Screenshot of a Cairo build rendering

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

[Boris Zbarsky [:bzbarsky]]

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?

Comment 7

[dolphinling]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[dolphinling]

$ xrdb -query | grep dpi
Xft.dpi:        96.000000

Comment 10

[Boris Zbarsky [:bzbarsky]]

Weird... Given that, we should totally be ending up with the 26.6667px value.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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...

Comment 12

[dolphinling]

My window manager is metacity. I don't have any others installed right now, but if it'll help I could.

Comment 13

[Boris Zbarsky [:bzbarsky]]

No, that shouldn't be necessary, since that's the default GNOME window manager...

Comment 14

[dolphinling]

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.

Comment 15

[dolphinling]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #14)
> In minefield,

which version, exactly?  (build id?)

Comment 17

[dolphinling]

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... :(  )

Comment 18

[dolphinling]

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.

Comment 19

[dolphinling]

Attachment: Testcase

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.

Comment 20

[dolphinling]

Attachment: Screenshot, 2007-08-01-04 build

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).

Comment 21

[dolphinling]

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

Comment 22

[dolphinling]

Attachment: Reftestable version - pts

Comment 23

[Boris Zbarsky [:bzbarsky]]

Eli, any idea what's going on here?

Comment 24

[dolphinling]

Attachment: Reftestable version - px

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.

Comment 25

[dolphinling]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I don't see anything more likely in http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-26+02%3A00&maxdate=2007-08-27+05%3A00&cvsroot=%2Fcvsroot

Comment 27

[Boris Zbarsky [:bzbarsky]]

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...

Comment 28

[dolphinling]

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.

Comment 29

[dolphinling]

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...

Comment 30

[dolphinling]

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

Comment 31

[dolphinling]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 33

[dolphinling]

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).

Comment 34

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Cc'ing behdad on this, in case he has any ideas (he's the pango maintainer)

Comment 35

[Behdad Esfahbod]

No idea what may be causing that.  Lets get back to this after the pango patch I'm working on now lands.

Comment 36

[dolphinling]

It'd be good to have this in the testsuite, even if we didn't do anything to "fix" the bug.

Comment 37

[Boris Zbarsky [:bzbarsky]]

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

[Behdad Esfahbod]

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

[Boris Zbarsky [:bzbarsky]]

> 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

[Behdad Esfahbod]

No idea then.  I don't see anything between 1.16.4 and 1.16.5 that can cause this...

Comment 41

[Boris Zbarsky [:bzbarsky]]

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

[Takanori MATSUURA]

As far as I tested 2007102304 trunk on Fedora 7, attachment 275544 [details] and attachment 275546 [details] have the same view.

Comment 43

[Francois Ingelrest]

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

Comment 44

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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?

Comment 45

[dolphinling]

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

Comment 46

[Karl Tomlinson (:karlt)]

Enabled test on Linux.  in-testsuite on all platforms now.
http://hg.mozilla.org/mozilla-central/rev/60eedb77a169