455441 - font rasterization messed up under certain transforms

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

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

Attachment: 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"

Comment 1

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

Attachment: screenshot

Comment 2

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

I'm testing in a Linux Firefox debug build from http://hg.mozilla.org/mozilla-central/rev/365280a5b548 plus my own patches.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

WFM on Ubuntu 7.10

Comment 4

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

I'm on Ubuntu 8.04.

Comment 5

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

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

Comment 6

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

Tomorrow, I'll try to figure out which font is being used.  That could be relevant.

Comment 7

[Karl Tomlinson (:karlt)]

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

Comment 8

[Karl Tomlinson (:karlt)]

Attachment 338808 [details] [diff] fixes the issue for me.

Comment 9

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

The gfxFont being used to draw the text has a GetName() of "serif" and a GetUniqueName of "DejaVu Serif".

Comment 10

[Karl Tomlinson (:karlt)]

I don't know what caused this problem but I can't reproduce it since changes in bug 385263 landed.

Comment 11

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

Yep, works for me now as well.