Re: [css3-multicol] Test with excessively wide column-gaps

Le Mer 7 août 2013 18:33, Dirk Pranke a écrit :
> On Wed, Aug 7, 2013 at 3:07 PM, Morten Stenshorne
> <mstensho@opera.com>wrote:
>
>> "Gérard Talbot" <www-style@gtalbot.org> writes:
>>
>> > We have hundreds of tests which use Ahem font and correspondent
>> reference
>> > test files using images. This is the first I hear about what you say.
>> So,
>> > this is somehow worrisome.
>>
>> OK, maybe my setup is weird. :)
>>
>> Can't say I'm too fond of the Ahem font. I try to avoid it when writing
>> tests. I guess I've seen too many Ahem tests with expectations that not
>> all font engines can live up to (like now). In my pessimistic mind, an
>> Ahem rendering can only be compared with another Ahem rendering, and not
>> with images, filled squares, etc. I usually end up using (inline-)blocks
>> with a background instead, or if I really have to use text, I just use
>> the default font, since I don't expect to be able to assume anything
>> about how Ahem text is going to be rendered (or even laid out), anyway.
>>
>> BTW, on the computer I use now (Ubuntu something), Presto displays an
>> ugly half pixel wide vertical stripe between the characters in your
>> test. There are so many ways to "fail". :)
>>
>> > Do you have ClearType on or off? Do you use ClearType default, initial
>> > setting?
>>
>> I don't think I've changed anything. I don't have access to that
>> computer right now, so I can't tell you more. I was running Windows 7
>> with IE10 inside a VirtualBox that runs under Debian. That might be a
>> clue, I suppose.
>>
>> > Are you using a color LCD display?
>>
>> Yes.
>>
>> > Is the phenomenon still occuring in all/every ClearType Text Tuner
>> > situations?
>>
>> I could check.
>>
>> > If you reset all IE10 settings to factory default, is there still a
>> half
>> > pixel offset affecting test versus reftest ?
>>
>> I could try that as well.
>>
>>
> As another data point, in Blink (Chromium), we see a large number of test
> failures on Mac OS 10.8 when rendering tests containing the Ahem font with
> text antialiasing enabled; when I turned off antialiasing, the failures
> went away.
>
> It's possible this is some weirdness in the font definitions for Ahem that
> could be corrected.

Hmm... I usually create reference files with images (swatch-*.png in
/support/ folder) as associated reftest for tests using Ahem font.

Could it be that anti-aliasing is affecting Ahem glyphs (or fonts only) in
a way that is (or would be) different for adjacent .png images?

And there is more than 1 anti-aliasing technology out there...

> It's also possible that this is a bug in Core Graphics
> or our graphics libraries. However, we also turn off antialiasing by
> default on our other platforms when running tests (and I believe Apple
> also
> turns off antialiasing by default in WebKit).

Opera 12.x, by default, turns ON anti-aliasing under Linux.

Opera 12.x, by default, turns OFF anti-aliasing under Windows and Mac.

opera:config, User Prefs section, Draw Anti Aliased Fonts setting, click
Default and the checkbox will get checked under Linux.

Clicking the "?" button gives: "Enable anti-aliasing. UNIX only"

> I think it is fairly safe to say that antialiasing text can cause
> reference
> tests to fail in ways that you wouldn't expect by simply looking at the
> tests and assuming that everything just has integer precision and
> quantization.
>
> -- Dirk

I have in the past worried about anti-aliasing affecting tests (unexpected
smaller-than-1px distorsions) which could make automated checking
unreliable.

Dirk, I appreciate your feedback on this matter.

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Wednesday, 7 August 2013 23:50:46 UTC