Created attachment 338786 [details] testcase I'm going to attach a testcase that has two examples that should lead to the same result. They pretty much do, except that the font rasterization ends up being quite a bit different, and, for the lowercase "e", quite disastrous. The difference between the upper and lower examples in the testcase is that the upper example has two transforms on the same element, which means the style code multiplies the matrices, and the lower example has them on two nested elements, which means that cairo multiplies the (same) matrices. (Note that the testcase is trying to work around two different bugs in our handling of skew functions -- (a) that we don't parse the two-argument form of skew(), and (b) that we fill in the second argument, when missing, with the first argument, rather than 0; if those bugs are fixed in the wrong order (b then a) the testcase will stop doing what it currently does for a bit.) Steps to reproduce: load attached testcase Expected results: top and bottom parts look pretty much the same, except for the number Actual results: top is much bolder and has a mangled "e"
I'm testing in a Linux Firefox debug build from http://hg.mozilla.org/mozilla-central/rev/365280a5b548 plus my own patches.
WFM on Ubuntu 7.10
I'm on Ubuntu 8.04.
(In reply to comment #0) > (Note that the testcase is trying to work around two different bugs in our > handling of skew functions -- (a) that we don't parse the two-argument form of > skew(), and (b) that we fill in the second argument, when missing, with the > first argument, rather than 0; if those bugs are fixed in the wrong order (b > then a) the testcase will stop doing what it currently does for a bit.) And for those following along, I filed both of those bugs as bug 455445.
Tomorrow, I'll try to figure out which font is being used. That could be relevant.
I do see the same here with Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b1pre) Gecko/20080915020339 Minefield/3.1b1pre but not deterministically and only at the zoom level that is first used to render the page. (Looks fine at different levels but problem returns when returning to original zoom level. I have seen the bolding and upside down "!" but not the e issue, at the first zoom level in, when the page is first rendered at that level.)
Attachment 338808 [details] [diff] fixes the issue for me.
The gfxFont being used to draw the text has a GetName() of "serif" and a GetUniqueName of "DejaVu Serif".
I don't know what caused this problem but I can't reproduce it since changes in bug 385263 landed.
Yep, works for me now as well.