- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Sat, 17 Mar 2012 15:53:38 -0400
- To: "John Daggett" <jdaggett@mozilla.com>
- Cc: "Public CSS test suite mailing list" <public-css-testsuite@w3.org>
Le Sam 17 mars 2012 3:24, John Daggett a écrit : > > 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. The whole test suite should not require user agents to use, to be using or to implement subpixel positioning technology. This should be loud and clear. 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. Because I create reftests, I have to disable anti-aliasing and then make sure that precise baseline alignment isn't a factor (when using Ahem font): there should be no situation where rounding up or down can become a factor for positioning tested objects on a baseline. E.g.: vertical-align-112 must be corrected in that sense. http://lists.w3.org/Archives/Public/public-css-testsuite/2012Mar/0001.html >> >> 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. Fine. When using Ahem font, I have proposed to only use a font-size which in pixel units will be dividable by 5 without creating fractional remainder so that baseline alignment will be reliable, trustworthy in all browsers. I have adjusted a bunch of tests in that sense. I think we should make this a formal guideline in Test format http://wiki.csswg.org/test/format and http://www.w3.org/Style/CSS/Test/guidelines.html Gérard -- Contributions to the CSS 2.1 test suite: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/ CSS 2.1 Test suite RC6, March 23rd 2011: http://test.csswg.org/suites/css2.1/20110323/html4/toc.html CSS 2.1 test suite harness: http://test.csswg.org/harness/ Contributing to to CSS 2.1 test suite: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Saturday, 17 March 2012 19:54:11 UTC