font rasterization messed up under certain transforms

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
9 years ago
9 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)

(Reporter)

Description

9 years ago
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"
(Reporter)

Comment 1

9 years ago
Created attachment 338788 [details]
screenshot
(Reporter)

Comment 2

9 years ago
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
(Reporter)

Updated

9 years ago
Blocks: 435293
(Reporter)

Comment 4

9 years ago
I'm on Ubuntu 8.04.
(Reporter)

Comment 5

9 years ago
(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.
(Reporter)

Comment 6

9 years ago
Tomorrow, I'll try to figure out which font is being used.  That could be relevant.
(Assignee)

Comment 7

9 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

9 years ago
Attachment 338808 [details] [diff] fixes the issue for me.
Assignee: nobody → mozbugz
Depends on: 385263
(Reporter)

Comment 9

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

Comment 10

9 years ago
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: 9 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → mozilla1.9.1b1
(Reporter)

Comment 11

9 years ago
Yep, works for me now as well.
You need to log in before you can comment on or make changes to this bug.