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

Le Mer 7 août 2013 18:07, Morten Stenshorne a écrit :
> "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.


But the thing is: Ahem font (open-source, free to use, not proprietary)
was designed to be used for creating tests (in a reliable manner) where
the glyphs occupy a predictable width and a predictable height.

Ahem font was created to overcome § 10.6.1:
"
The height of the content area should be based on the font, but this
specification does not specify how. A UA may, e.g., use the em-box or the
maximum ascender and descender of the font. (The latter would ensure that
glyphs with parts above or below the em-box still fall within the content
area, but leads to differently sized boxes for different fonts; the former
would ensure authors can control background styling relative to the
'line-height', but leads to glyphs painting outside their content area.)
"
10.6.1 Inline, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced


"
The Ahem font was developed by Todd Fahrner to help test writers
develop predictable tests. The font's em square is exactly square.
Its ascent and descent is exactly the size of the em square. This
means that the font's extent is exactly the same as its line-height,
meaning that it can be exactly aligned with padding, borders, margins,
and so forth.
"
http://www.w3.org/Style/CSS/Test/Fonts/Ahem/

The only characters in the Ahem font to be careful about (when creating a
text string) are: "p" and "É".

As long as computed font-size is dividable by 5px without a remainer (so
that baseline-alignment of glyphs can be reliable, trustworthy across
platforms), then there shouldn't be any problems.

I personally have updated dozens and dozens of Microsoft submitted CSS2.1
tests so that computed font-size would be dividable by 5px without a
remainer.

In IE10 and in all browsers, the presumed default medium font-size must be
16px. Because in all the tests I make or update or adjust, I often/usually
use 1.25em as font-size. (reasoning: 16px is not dividable by 5px without
a remainer; 20px is though)

"
The 'medium' font-size computes to 16px.
"
http://test.csswg.org/suites/css3-multicol/nightly-unstable/#uncommon
http://test.csswg.org/suites/css2.1/20110323/#uncommon
http://test.csswg.org/suites/css2.1/nightly-unstable/#uncommon



> BTW, on the computer I use now (Ubuntu something), Presto

Which version of Presto?

Over here, I have (and use) Opera 12.16, build revision 1860, Presto
version 2.12.388
user agent string:
Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16

> displays an
> ugly half pixel wide vertical stripe between the characters in your
> test.

For your info: I use Kubuntu 13.04 (codename raring), KDE 4.10.5, i686
(32bits), linux kernel 3.8.0-27-generic .


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

Hm... IE10 inside a VirtualBox running under Debian... can't say I use
that :)

> That might be a
> clue, I suppose.
>
>> Are you using a color LCD display?
>
> Yes.

Okay. This may be (not sure) an important info. Because ClearType Text
Tuner is originally intended for color LCD display.

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

I would be very appreciative if you could check the test again in IE10
with IE10 with factory default settings.
In Internet Options/Advanced tab/Reset button (label of button says:
"Reset Internet Explorer's settings to their default condition.")

If the test was off by 5px or 10px in a few spots, then we would conclude
something different: eg the test is wrong, eg the UA has not implemented
the 2011 version or eg the UA has not implemented the tested
feature/property/property_value. But when a test is off by half a pixel,
then the issue involved is - usually - in the browser settings or the
underlying platform font APIs.

Prince9, for instance, shows a lot of tiny lines between Ahem glyphs and
png swatch images but those, I think, have nothing to do with the test
itself.

"
(...) most PDF readers will render the output with very thin 'cracks'
between the different layers. (...)
"
http://www.princexml.com/samples/acid2/

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:20:41 UTC