Bug 17086

Summary: Acid3 positioned generated content overlaps border because of how antialiasing is affecting the Ahem font
Product: WebKit Reporter: Eric Seidel <eric@webkit.org>
Component: CSSAssignee: Dave Hyatt <hyatt@apple.com>
Status: RESOLVED FIXED    
Severity: Normal CC: geoffers+webkit@gmail.com, hyatt@apple.com, ian@hixie.ch, mitz@webkit.org, phiw@l-c-n.com, webkit@blaut.biz, webkit-bugs@gentlyusedunderwear.com, webmaster@keryx.se
Priority: P2 Keywords: HasReduction
Version: 528+ (Nightly build)   
Hardware: Macintosh   
OS: Mac OS X 10.5   
URL: http://acid3.acidtests.org/
Bug Depends on: 17085    
Bug Blocks: 17064    
Attachments:
Description Flags
test case
none
antialiasing - strong
none
antialiasing - standard
none
corrected test case with antialiasing issue
none
Acid 3 test at 108 DPI (1.50 scale factor) none

Description From 2008-01-29 16:29:04 PST
Acid3 positioned generated content test is a few pixels off

This is the CSS in question

  @font-face { font-family: "AcidAhemTest"; src: url(font.ttf); }
  map::after { position: absolute; top: 20px; left: 640px; content: "X"; background: fuchsia; color: white; font: 20px/1 AcidAhemTest; }

The X is a couple pixels left and down of where it should be.

In order for the X to be a white square (like it used to be) bug 17085 needs to be fixed first.
------- Comment #1 From 2008-01-30 00:06:47 PST -------
Created an attachment (id=18790) [details]
test case
------- Comment #2 From 2008-01-31 16:07:18 PST -------
Any idea why it's not positioned right?
------- Comment #3 From 2008-01-31 22:48:14 PST -------
After removing @font-face support dependency on the test case Opera 9.5 fails this test with a same result Webkit.
------- Comment #4 From 2008-01-31 23:14:31 PST -------
Note that this is not dependent on generated content. You get the same (wrong?) rendering if you change div::after to div and add width: 20px; height: 20px; to the style declaration.
------- Comment #5 From 2008-02-01 00:06:15 PST -------
I'm a dumbass. The test was wrong. Fixed it. Terribly sorry about that.
------- Comment #6 From 2008-02-01 00:26:04 PST -------
This test is not yet solved, I think we should reopen this bug.  Now the ahem square overlaps the border ever so slightly.  possibly due to antialiasing.

You'll need to reload the test once or twice if the square is still to low and to the left for you, since the font seems to stay cached.
------- Comment #7 From 2008-02-01 01:22:01 PST -------
(In reply to comment #6)
> This test is not yet solved, I think we should reopen this bug.  Now the ahem
> square overlaps the border ever so slightly.  possibly due to antialiasing.

Eric, antialiasing causes this problem for sure. With antialiasing set to "standard" in Leopard the problem disappears, but I daily use "strong" setting ;) I'll attach screenshots for this case
------- Comment #8 From 2008-02-01 01:25:07 PST -------
Created an attachment (id=18843) [details]
antialiasing - strong
------- Comment #9 From 2008-02-01 01:25:36 PST -------
Created an attachment (id=18844) [details]
antialiasing - standard
------- Comment #10 From 2008-02-01 01:31:33 PST -------
Created an attachment (id=18845) [details]
corrected test case with antialiasing issue
------- Comment #11 From 2008-02-01 12:45:08 PST -------
I'm not sure our behavior isn't "correct" here.  I don't thing we expose a way via CSS to control the antialiasing of a font.  I would be interested in hyatt's thoughts, but I expect this is probably "works correctly".
------- Comment #12 From 2008-02-01 12:59:33 PST -------
In my opinion the test should be updated to exclude antialiasing influence. In this state the Acid3 is unreliable. 
------- Comment #13 From 2008-02-01 15:20:53 PST -------
No antialiasing should be going on here. The character is exactly 1em by 1em, 1em is 20px. Thus the character is _exactly_ 20x20 pixels. The character is an exact square. The character is rendered exactly lined up on a pixel boundary. No part of the character ever overlaps the border. There is thus nothing to antialias, and nothing that can affect the border.

If it was another character from another font I would agree. However, in this particular case, the metrics are really precise and I don't see how one could argue that the character could legitimately be rendered beyond the 20x20 box.
------- Comment #14 From 2008-02-03 16:04:19 PST -------
Ian, I don't know how fonts are rendered but it wasn't the first time I noticed odd antialiasing influence on Ahem font and how your test cases are displayed with the font. The issue is for example present in this test http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t100303-c412-blockw-00-d-ag.htm as well. Not only on Mac OS X, but also on Windows. If you turn on Cleartype on Windows or Strong antialiasing on Mac OS X the above green box in above mentioned test will have small red dashes inside a green area. If you turn antialiasing off the above box will be perfect green.
------- Comment #15 From 2008-02-05 13:15:44 PST -------
Other tests with antialiasing issue are mentioned in bug 7276.
------- Comment #16 From 2008-02-10 13:45:53 PST -------
I really think Acid3 should be amended to place overflow:hidden on the map::after rule.  This will ensure that any antialiased edges are clipped out.  Even though I agree that it's odd that LCD antialiasing does this on OS X (other antialiasing modes do not), I don't think Acid3 has the right to dictate that the glyph *not* be antialiased.

Going further, I'm not even sure it's fair for Acid3 to test using @font-face with ttf as I know of no specification from 2004 or earlier that mandates what font format a browser must support with @font-face.
------- Comment #17 From 2008-03-26 11:14:27 PST -------
Using the Windows version in GDI mode the problem doesn't occur. 
------- Comment #18 From 2008-03-26 19:49:16 PST -------
Hyatt resolved this in r31322.
------- Comment #19 From 2008-03-26 23:17:47 PST -------
"No antialiasing should be going on here. The character is exactly 1em by 1em, 1em is 20px. Thus the character is _exactly_ 20x20 pixels."

This is a very bad assumption to make. If the user has a user scale factor enabled (you can set this in Mac OS X by changing it in /Developer/Applications/Performance Tools/Quartz Debug.app)

If you set the user scale factor to something like 1.25 or 1.50 or anything else that causes 20px to NOT lie on device boundaries, the test fails.

Apple has stated in the past they plan to make the user scale factor an end-user feature sometime "this spring".

For embedded system, like the iPhone and iPod touch, that have arbitrary user scale factors a main part of the UI, then 20px would definitely not fall on  pixel boundaries.

And since there's no CSS property available currently to define an antialias method, this test is making even more assumptions.

I'm including a screenshot of what Acid3 looks like at 108DPI (1.50 Scale Factor)
------- Comment #20 From 2008-03-26 23:19:09 PST -------
Created an attachment (id=20116) [details]
Acid 3 test at 108 DPI (1.50 scale factor)
------- Comment #21 From 2008-03-27 00:21:19 PST -------
(In reply to comment #19)
> 
> This is a very bad assumption to make. If the user has a user scale factor
> enabled

...then you aren't using default settings, and the test doesn't apply. As the test says, "to pass the test, a browser must use its default settings".


> If you set the user scale factor to something like 1.25 or 1.50 or anything
> else that causes 20px to NOT lie on device boundaries, the test fails.

Sure. But at 1.0, what I said holds.


And frankly, it holds at other zoom factors too. I understand what the LCD antialiasing algorithm is doing. It's trying to use the LCD's characteristics to obtain a higher quality rendering than normal antialiasing. However, in the screenshot, what you see is a LOWER quality rendering. There's no purple in that corner, you shouldn't see any purple. That you can see any is a BUG. The LCD antialiasing is making the rendering WORSE. The correct solution is to fix the LCD antialiasing to detect such cases and not screw up.

Hard-coding Ahem isn't a high-quality solution.
------- Comment #22 From 2008-03-27 07:16:15 PST -------
(In reply to comment #21)
> ...then you aren't using default settings, and the test doesn't apply. As the
> test says, "to pass the test, a browser must use its default settings".
> 

The user scale DPI setting is a system setting, not a browser setting. So a user with a system user scale setting of 108 DPI could still be using the browser default settings.
------- Comment #23 From 2008-03-27 09:58:14 PST -------
I would have preferred that if Hyatt et al. really felt the test shouldn't be testing this case, that they stood their ground and refused to change any behavior until both sides could agree.  The current behavior, where WebKit's font rendering changes based on font name, seems like the worst of all worlds to me.  Is there another bug covering "back this out or else do something more general"?
------- Comment #24 From 2008-03-27 10:18:30 PST -------
This is just retaliating against a bad decision with a worse one. Different graphics systems make different choices when they antialias: Windows chooses to not antialias on pixel boundaries, and Mac OS X chooses to do so to make text appearance more even. If you want to make arguments for or against either approach, fine, but acid3 should be about testing web standards, not AA algorithms.

And I'd prefer to not even comment on 31322.
------- Comment #25 From 2008-03-27 11:36:22 PST -------
Reopening to track the fact that something should change here (either a better solution or fixing the Acid 3 test itself).
------- Comment #26 From 2008-04-02 02:30:29 PST -------
Acid3 itself changed, so this is no longer an issue.