Bug 17086

Created attachment 18790 [details] test case

Any idea why it's not positioned right?

After removing @font-face support dependency on the test case Opera 9.5 fails this test with a same result Webkit.

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.

I'm a dumbass. The test was wrong. Fixed it. Terribly sorry about that.

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.

(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

Created attachment 18843 [details] antialiasing - strong

Created attachment 18844 [details] antialiasing - standard

Created attachment 18845 [details] corrected test case with antialiasing issue

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

In my opinion the test should be updated to exclude antialiasing influence. In this state the Acid3 is unreliable.

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.

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.

Other tests with antialiasing issue are mentioned in bug 7276.

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.

Using the Windows version in GDI mode the problem doesn't occur.

Hyatt resolved this in r31322.

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

Created attachment 20116 [details] Acid 3 test at 108 DPI (1.50 scale factor)

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

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

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"?

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.

Reopening to track the fact that something should change here (either a better solution or fixing the Acid 3 test itself).

Acid3 itself changed, so this is no longer an issue.