551734 - Unicode hair space (U+200A) is too wide if style="font: x-small sans-serif"

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect)

Description

[Brandon Mitchell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

A Unicode hair space (U+200A) should be thinner than a Unicode thin space (U+2009), but Firefox renders it wider than a normal SPACEBAR space when an x-small sans-serif style of font is specified via "font: x-small sans-serif". (With no font style, or with just x-small or just sans-serif, the hair spaces render correctly.)

Please see the attached test case for gory details, reproducibility, etc...


Reproducible: Always

Actual Results:  
...

Expected Results:  
...

Comment 1

[Brandon Mitchell]

Attachment: Test case

Comment 2

[Brandon Mitchell]

Attachment: Comparison of Firefox vs IE8

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is the problem that a particular font has a bad glyph for that codepoint?

Comment 4

[Brandon Mitchell]

I'm not sure if I know how to determine if the problem is that a particular font has a bad glyph for the codepoint. On Windows, does "font: x-small sans-serif" default to a small size of Arial? If so, the Windows XP character map doesn't show a U+200A for Arial (nor Times New Roman); it jumps from U+1EF9 to U+200C. So I guess that means Arial doesn't have a glyph for U+200A?

I also note that the test case renders correctly in IE8, and it renders correctly in Firefox if "font: sans-serif" without "x-small" is used for the style.

In IE6, U+200A renders as a box, which suggests that the font doesn't have a glyph for U+200A.

I think Firefox is supposed to find a substitute glyph for U+200A (as IE8 does and as Firefox does for U+2009, I presume), but it doesn't seem to be selecting an appropriately narrow substitute in this case. It needs to be an x-small version of what is used for default-sized sans-serif.

Comment 5

[Brandon Mitchell]

Attachment: How IE6 renders the test case

Interestingly, it looks like Firefox is doing with U+200A what IE used to do with U+2009. Though IE6 renders U+200A as a box, in Example 2 of the test case it renders U+2009 (thin space) as a wide space - very similar to what Firefox sometimes does with U+200A (hair space). These problems appear to be fixed in IE8; I don't know about IE7.

Comment 6

[Tim]

This web page at w3schools demonstrating the measureText method of the Canvas, shows all major browsers, except Firefox, agreeing on the size of \u200A when measured for various font-sizes:

http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_canvas_measuretext

Note that all browsers except FF return an integer from the measureText method of the Canvas element; FF returns float values like 1.666666....  Not sure if that is relevant, but it is a difference. One expects an integer because the measurement is supposed to be in pixels.

I'd like to use this "hair space" in a text-justification algorithm in the Canvas, so it's important that it be rendered correctly.

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Tim from comment #6)
> This web page at w3schools demonstrating the measureText method of the
> Canvas, shows all major browsers, except Firefox, agreeing on the size of
> \u200A when measured for various font-sizes:
> 
> http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_canvas_measuretext
> 
> Note that all browsers except FF return an integer from the measureText
> method of the Canvas element; FF returns float values like 1.666666....  Not
> sure if that is relevant, but it is a difference. One expects an integer
> because the measurement is supposed to be in pixels.

No, measurements may be fractional pixels - note the "double" parameters all over the place in the spec[1]. Some implementations may round positions/sizes/etc to integer pixels, but that is a limitation, not a feature.

> I'd like to use this "hair space" in a text-justification algorithm in the
> Canvas, so it's important that it be rendered correctly.

Given that some implementations round its width (and other glyph widths) to integer pixel widths, while others support fractional widths, you can't count on it being consistent across environments.

In any case, this sounds like a bad way to implement justification; better to explicitly position the visible runs of text exactly where you want them (remembering that their width, too, will differ among implementations depending on the capabilities of the font-rendering technology - as well as the particular fonts that are available).

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvas-context-2d

Comment 8

[Jonathan Kew [:jfkthame]]

Brandon: do you still see this problem in a current FF version, or is this bug resolved? I'm thinking it may have been fixed by bug 33032, in which case we should close this report.