Open
Bug 469208
Opened 16 years ago
Updated 2 years ago
Canvas drawWindow chops off the letter boundaries on Win32
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
NEW
People
(Reporter: ehsan.akhgari, Unassigned)
References
Details
Attachments
(3 files)
3.85 KB,
patch
|
Details | Diff | Splinter Review | |
18.44 KB,
image/png
|
Details | |
18.40 KB,
image/png
|
Details |
I was fighting this issue when writing the unit test for bug 441782. The issue is basically that sometimes, the edges of letters gets chopped off in the output of canvas drawWindow method. This seems to only happen on Windows. It doesn't happen in Linux (tested myself) and doesn't seem to happen on OS X (based on feedback from bug 441782). I'm not really sure how to describe this, but I have a unit test which fails on Windows. I'll attach it to the bug right away.
Reporter | ||
Comment 1•16 years ago
|
||
This test case fails on Windows, and passes on Linux. I have not tested this on OS X. The problem can easily be seen by observing the visual output of the test case. The right side of 3 is chopped off when it is at the end of the text. Adding a ZWNJ to the end of the text shouldn't affect rendering, because ZWNJ is an invisible character, but since it causes 3 not to be the last character any more, it causes a different (and correct) rendering on Windows, so the test will fail.
Related to bug 445087, maybe
Reporter | ||
Comment 3•16 years ago
|
||
(In reply to comment #2) > Related to bug 445087, maybe Yes, this seems to be the case. With Cleartype turned off, both the reftest I attached here, and all of the tests for bug 441782 pass. Should I mark this as a dupe of bug 445087?
Let's mark it dependent on 445087. When we have a patch for that bug, we can see if it fixes this bug too.
Depends on: 445087
Comment 5•16 years ago
|
||
The clipping can be clearly seen on the right-hand edge of the "3" in the 3rd group of digits here.
Comment 6•16 years ago
|
||
After the patch for bug 445087 is applied, I can no longer see any clipping of the glyph here, as shown in the screenshot. However, the mochitest still reports that the images don't match, so there must be a tiny difference somewhere. In other tests, the fix for bug 445087 does resolve a number of reftest failures in the layout/reftests/text directory, where formerly the tests failed with ClearType enabled but passed without it. The only remaining failure there occurs where the ClearType antialiasing pixels for two glyphs actually overlap, and the result differs depending whether the glyphs are drawn as part of the same run, or separately.
Comment 7•16 years ago
|
||
Close examination of enlargements shows that ClearType actually "bleeds" the right-hand side of the lower curve of the "3" into the second column beyond the nominal bounding box of the glyph; in addition to the main antialiasing pixels in the first column, there are two faint cyan pixels in the second, and those account for the remaining difference. Adjusting the patch for bug 445087 to add 2 pixels of slop on the RHS of the bounding box finally makes this test pass successfully. I will update that patch accordingly. I think 1 pixel on the LHS is still OK, as ClearType seems to "smear" glyphs primarily to the right.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•