Re: Feedback on Philip Taylors Canvas Tests

Kris Krueger wrote:
> http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/2d.strokeRect.zero.4.html
> There is nothing in the spec that describes how the stroke width should be applied for a zero-height rect.
> The spec only says "the method will draw a line instead (the path for the outline is just a straight line along the non-zero dimension)."

The normative requirement is where the spec describes "the path that 
must then be closed to get the specified rectangle: (x, y), (x+w, y), 
(x+w, y+h), (x, y+h)". So it's equivalent to:

   beginPath();
   moveTo(x, y);
   lineTo(x+w, y);
   lineTo(x+w, y+h);
   lineTo(x, y+h);
   closePath();
   stroke();

(except without altering the current path).

The definition of stroke() normatively requires: "Zero-length line 
segments must be pruned before stroking a path". If h=0 then the lines 
(x+w,y)-(x+w,y+h) and (x,y+h)-(x,y) will be pruned, so it's equivalent to:

   beginPath();
   moveTo(x, y);
   lineTo(x+w, y);
   closePath();
   stroke();

which is just a closed path consisting of two coincident lines in 
opposite directions (with a line join at each end). So I think the 
behaviour is all defined and the test matches it.

> http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/2d.text.draw.baseline.top.html
> http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/2d.text.draw.baseline.bottom.html
> http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/2d.text.draw.baseline.middle.html
> http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/2d.text.draw.baseline.ideographic.html
> http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/2d.text.draw.baseline.hanging.html

> The tests uses that CanvasTest.ttf font which contains two different
> contradictory sets of values in <OS/2> and <hhea> tables, both can be
> used depending on UA or font system. For example Firefox is using
> different metrics for regular HTML and Canvas. Which one to use is
> not part of the HTML5 or the OpenType spec. It's possible to create a
> Font can be "fixed", so all UAs will use the same value (with high
> probability) and no longer use '_assertPixlelApprox' that seems to
> work around this issue?

Using ttx to dump the font data, it looks like the relevant parts are:

   <hhea>
     [...]
     <ascent value="1745"/>
     <descent value="-805"/>
     [...]
   </hhea>

   <OS_2>
     [...]
     <sTypoAscender value="768"/>
     <sTypoDescender value="-256"/>
     <sTypoLineGap value="92"/>
     <usWinAscent value="1745"/>
     <usWinDescent value="805"/>
     [...]
   </OS_2>

(Also there's the BASE table specifying hang/ideo/math/romn baselines.)

The font and tests are designed to have the baseline 25% up the em box, 
i.e. a 3:1 ratio of ascender:descender, i.e. the Typo values are 
correct. I guess this means both the occurrences of 1745/805 ought to be 
changed to match, though given 
http://www.microsoft.com/typography/otspec/os2.htm#wa and 
http://typophile.com/node/13081 it sounds like there's a bit of a 
compatibility mess here, so I'll have to try it out and see what breaks...

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Tuesday, 4 January 2011 16:30:43 UTC