W3C home > Mailing lists > Public > public-css-testsuite@w3.org > March 2012

Re: Test harness and test suite assumptions wrt anti-aliasing (font smoothing, clearType)

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>
Message-ID: <1935775371.12818368.1331969092323.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>

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

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.



[1] https://bugzilla.mozilla.org/show_bug.cgi?id=604836
Received on Saturday, 17 March 2012 07:25:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:18 UTC