font rasterization messed up under certain transforms

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
11 years ago
11 years ago

People

(Reporter: dbaron, Assigned: karlt)

Tracking

Trunk
mozilla1.9.1b1
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Posted file 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.
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.
(Assignee)

Comment 7

11 years ago
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.)
(Assignee)

Comment 8

11 years ago
Attachment 338808 [details] [diff] fixes the issue for me.
Assignee: nobody → mozbugz
Depends on: 385263
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → mozilla1.9.1b1
Yep, works for me now as well.
You need to log in before you can comment on or make changes to this bug.