- From: John Daggett <jdaggett@mozilla.com>
- Date: Sat, 17 Mar 2012 00:24:52 -0700 (PDT)
- To: css21testsuite@gtalbot.org
- Cc: Public CSS test suite mailing list <public-css-testsuite@w3.org>
Gérard Talbot wrote: > > Browsers typically render text with > > subpixel antialiasing *and* with subpixel or integer-pixel > > positioning. All browsers support subpixel anti-aliasing but only > > Firefox/IE9 use subpixel positioning, Webkit/Opera use integer-pixel > > positioning. Line metrics may be calculated with precise or rounded > > metrics and where exactly the rounding occurs is not defined > > precisely. Under Windows, hinting will also affect these metrics for a > > given font size, depending on the font. All of these factors will > > affect the > > precise placement. Only disabling subpixel anti-aliasing will still > > leave you with other factors that affect placement. > > Of course it will leave the other factors that affect placement. Why > should we want to have many factors affect precise placement of text > when automated checking of tests start? Why not eliminate sources of > differential rendering, especially if such sources are entirely outside > the realm of CSS spec? If you're seeing subpixel anti-aliasing affect a test, then it's a sign that the text in question isn't placed precisely such that it lands on integer pixel boundaries. So that's either a bug in the browser or a bug in the test. For example, many tests I've seen are in subtle ways dependent upon the metrics of the default font when they really shouldn't be. > I create reftests and there are quite a lot razor sharp tests in the > test suite, you know. That's fine as long as the tests are constructed such that placement will always be precise, independent of default font choice or locale for example. > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/absolute-non-replaced-width-017-ref.xht > > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/absolute-non-replaced-width-017.xhtml > > 10 min. ago, I had anti-aliasing turn off (under Linux KDE 4.8.1) and > both these webpages looked perfectly identical in Firefox 11.0. > > Then I re-enabled anti-aliasing, rebooted and reloaded these 2 webpages > and, this time, there is a 1px height of difference for the black > stripe. Clearly noticeable. I don't have a Linux build handy right now, but I would say there's either a bug in the test, such that there's a subpixel overlap, or it's a bug in the browser. Turning off subpixel anti-aliasing is just masking whatever the underlying bug is, either in the test or in the browser. In this case, my guess is that this is a bug in Firefox/Linux, bug 604836, which you're aware of. [1] > > The other reason for not doing this is that it's not an > > environment users typically use and so you won't be testing the > > main codepath that browsers use, you'll be using a modified > > non-subpixel-AA path. > > It's certainly a valid reason... but machines, softwares doing > automated checking of tests with reftests won't be understanding: > it's identical or not. I think whether the testing is automated or not is somewhat orthogonal, the underlying codepath should be similar to the one being used to render layouts in a given user's environment. My point is simply that the tests should be testing only what they are trying to test, for example "does the size of a box 16px x 16px match the rendering of 16px Ahem". If the baseline is not on a pixel boundary then whether it lines up will depend on rounding rules that aren't precisely defined in CSS and we shouldn't have tests that rely on those rules. Regards, John [1] https://bugzilla.mozilla.org/show_bug.cgi?id=604836
Received on Saturday, 17 March 2012 07:25:21 UTC