RE: Microsoft's Chapter_9/positioning-float-002.htm

Hi,

I have been trying to get the 'Filler text' positioned in 61px, however I have no idea how to do this, can somebody please let me know where I make any mistake.

This is what I am doing (we have written our own TTF parser):

I am using times.ttf (from WinXP SP3, x86 [32 bit])

First I convert the text into glyphs ids (notice that this string doesn't contain any ligatures, so the mapping is staid forward and 1-to-1).

Then I retrieve the (advance) widths from the horizontal metrics table, see the table below:

Char		glyph-id	advanceWidth
F		41		1139
i		76		569
l		79		569
l		79		569
e		72		909
r		85		682
[space]	3		512
T		87		569
e		72		909
x		91		1024
t		87		569

total				8020


This total should be divided by fontHeader.UnitsPerEM, which is 2048, and multiplied by the font size, which is 12.

So 8020/2048*12 = 46.992 (pt), which is 62.656px (multiplied by 96/72).

How does this relates to the 61px you found? 

I also checked the kern[ing] table, but the left-right combinations from the 'Filler text' is not present, so this can be skipped/ignored. When using e.g. the text FAIL, then the kerning table should be used, because F-A is present (the A should be a positioned a little to the left, underneath the F)

We are converting HTML into PDF documents, so we not really need to get the characters mapped on real pixels, maybe a grid-fit algorithm is doing this.

Some insight into how maps this into 61px is highly appreciated. 

If you have any further questions - or need more details - please do not hesitate to contact me. 
 

Best Regards,
Robert Stam
 
TallComponents


> -----Original Message-----
> From: "Gérard Talbot" [mailto:css21testsuite@gtalbot.org]
> Sent: Monday, April 26, 2010 9:15 PM
> To: public-css-testsuite@w3.org
> Cc: Robert Stam; Arron Eicholz
> Subject: Microsoft's Chapter_9/positioning-float-002.htm
> 
> Hello all,
> 
> Testcases involved are:
> 
> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_9/po
> sitioning-float-002.htm
> (using a width of 15em == 240px)
> 
> and
> 
> http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-
> 002.htm
> (using a width of 2in == 192px)
> 
> 
> Robert Stam wrote on jan. 27th 2010
> >> 5) ---------
> >> chapter_9\positioning-float-002.xht
> >>
> >> The width of the container is not big enough to fit all the text.
> >> Besides that the test is rendered correctly.
> 
> Arron Eicholz replied on feb. 1st 2010:
> >At the default font size the text is able to fit  correctly. It seems
> as >if you are not running at the browser default font setting.
> 
> coming from:
> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Feb/0003.html
> 
> 
> There are at least 4 problems with the 2 versions of the same testcase.
> 
> 1- As soon as you try the testcase in non-Windows operating systems, the
> testcase fails because the font-family in use is not Times New Roman. I
> conducted many tests and I definitely side with Robert Stam.
> 
> As soon as the span "Filler text" exceeds 61px in width (for
> http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-
> 002.htm
> ), the testcase, as far as the pass/fail condition of the testcase is
> involved, automatically fails. The only 2 font-family which did not
> exceed 61px are Times New Roman and Impact.
> 
> Under Linux KDE
> ---------------
> The span "Filler text" is 86px wide in Firefox 3.5.9 under Linux KDE,
> 83px in Opera 10.10, 86px in Konqueror 4.4.2 under Linux KDE ("DejaVu
> Serif" is the default font-family under Linux KDE's Konqueror 4.x
> browser). 192px or 240px are not wide enough if the span "Filler text"
> is 83px (or greater) wide. A simple arithmetic calculation will
> demonstrate this. 192px is a lot more constraining, restraining, giving
> almost no leeway for the testcase, font-family in use.
> 
> All 3 "Filler text" plus the 2 blank white spaces easily exceeds the
> containing block's specified width of 192px. There is only 9px left for
> the 2 white blank spaces.
> 
> Under Windows XP with Times New Roman
> (Tools/Internet Options.../General tab/Fonts button/Language script:
> Latin based/Webpage font), "Filler text" is 61px wide in Firefox 3.6.3,
> in Opera 10.51 and in Safari 4.0.5.
> 
> In this testcase:
> http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-
> 002.htm
> (using a width of 2in == 192px)
> 
> With Tahoma, it is 70px in IE8 and the 3 "Filler text" plus the 2 blank
> white spaces easily exceeds the containing block's specified width of
> 192px.
> With Arial, it is 67px in IE8 and the 3 "Filler text" plus the 2 blank
> white spaces easily exceeds the containing block's specified width of
> 192px.
> With Comic Sans MS, it is 81px.
> With Courier New, it is 110px.
> With Georgia, it is 75px.
> With Impact, it is 61px in IE8 and the 3 "Filler text" plus the 2 blank
> white spaces do not exceed the containing block's specified width of
> 192px.
> With Microsoft Sans Serif, it is 67px in IE8 and the 3 "Filler text"
> plus the 2 blank white spaces easily exceeds the containing block's
> specified width of 192px.
> With Trebuchet MS, it is 73px.
> With Verdana, it is 82px.
> With Code2000, it is 82px.
> 
> My conclusion is that if the font-family is not Times New Roman or is
> not Impact, the testcase (
> http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-
> 002.htm
> ) fails in Windows and fails in IE8 as well.
> 
> 2- The second problem with the testcase is that the containing block has
> a fixed, specified width. One says 2in (192px), the other says 15em
> (240px); but even at 240px, it may still fails depending on the
> font-family in use. In both cases, such specified widths are
> unneedlessly, unnecessarly constraining, restraining to begin with. In
> such testcase, the width of the containing block is irrelevant.
> 
> A demonstration of this is:
> http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/CSS21Section95FloatExa
> mple.html
> which comes from the CSS 2.1 spec itself:
> http://www.w3.org/TR/CSS21/visuren.html#float-position
> 
> Without a defined, fixed width, the testcase would not fail because of
> font-family in use.
> 
> 3- The testcase does not distinguish visually any of the 3 "Filler
> text". So, if a browser would fail the provided pass/fail condition, it
> could still nevertheless pass the testcase-ed, targeted behavior of the
> spec. And that is the case with Linux browsers using a font-family with
> wider glyphs. None of the 3 "Filler text" is identifiable in the
> testcase, say, by color or background-color or some other visual cues.
> 
> 4- The testcase passes - always - if CSS support is disabled or if the
> browser does not support CSS. Now, that's a sign that such testcase has
> a limited relevance, reliability.
> 
> 
> For all these reasons, the testcases
> 
> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_9/po
> sitioning-float-002.htm
> (using a width of 15em == 240px)
> 
> and
> 
> http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/positioning-float-
> 002.htm
> (using a width of 2in == 192px)
> 
> should be reviewed again, corrected, adjusted.
> 
> regards, Gérard
> --
> Contributions to the CSS 2.1 test suite:
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/
> 
> CSS 2.1 test suite (alpha 2; March 16th 2010):
> http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/toc.html
> 
> CSS 2.1 test suite contributors:
> http://test.csswg.org/source/contributors/

Received on Tuesday, 27 April 2010 09:05:39 UTC