Canvas textFill with an embedded font changes position between different OSes (and WebGL support?)




8 years ago
8 years ago


(Reporter: janesconference, Unassigned)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Firefox 4.0

I have a canvas element on which I draw text with the fillText function. textBaseline is set to "top" and textAlignment is set to "left". The font I use is an embedded one (I use @font-face).

If I try to launch the linked demo on FF 4.0 / ubuntu, FF 4.0 / W7 or FF 3.x / ubuntu, I get a certain text position, pictured in the screenshot below (look at the green LCD box):
[ Note: None of these browsers has WebGL (Mozilla showcase tells me I must check my drivers) ]

The very same demo on Firefox 4, Windows Vista with WebGL is displayed like that:

As you can see, the embedded-font text is a little bit higher in this last example, while its position is unchanged in the code.

Reproducible: Always

Steps to Reproduce:
Open the demo with different browsers, and see the differences in the embedded font text rendering.
Actual Results:  
FF 4.0 on Vista with WebGL enabled rendered the text in a position higher than the other FF 4.0 I tried.

Expected Results:  
FF 4.0 on Vista with WebGL enabled should have rendered the text in the same position the other FF 4.0 I tried.
What happens if you turn off DirectWrite in about:config?

For what it's worth, I see the rendering from your screenshot on Mac, where WebGL is very much enabled.  So I really doubt this has to do with WebGL.
I'm guessing the Vista machine is *not* using directwrite by default, whereas the Win7 one is. Setting gfx.font_rendering.directwrite.enabled to true on the Vista machine may therefore make them match better.

(If I'm right, this is essentially the _opposite_ of the complaints we've had about D2D/DW giving larger line spacing; here, the problem is that the tighter line spacing used under GDI doesn't match the behavior on other platforms.)

This raises the question of what the textBaseline values "top" and "bottom" are supposed to mean. says that " the top of the em square", but " the bottom of the bounding box", which is a strange and inconsistent way to define them, and probably not what we actually do in practice.

Ah.... is more consistent, saying that "top" and "bottom" are "The [top/bottom] of the em square" respectively. I suspect we're not using the right metrics here, then.

Comment 3

8 years ago
gfx.font_rendering.directwrite.enabled was false on my Vista box. I set it to true, but nothing changed at all (I tried several times to reload the demo, even after a few reboots). The text is still at the center of its box, like in the second screenshot.
Please let me know if I can do something else to make this bug reproducible for you.

(Johnatan: the W7 machine was run in VirtualBox, while all the others are physical machines. Unfortunately, I lost its data and can't check if gfx.font_rendering.directwrite.enabled was true right now).

Comment 4

8 years ago
Any chanche that someone could confirm this bug?
Ever confirmed: true

Comment 5

8 years ago
Created attachment 530912 [details]
Testing Arial and Arial Black rendering on Canvas

Comment 6

8 years ago
I'm experiencing an issue which might be related to that one: Certain fonts are displayed too far at the bottom when using fillText() on a <canvas> element.

I've attached a demo using Arial and Arial Black (where Arial Black is rendered wrong).

Here are the results for FF 4.0.1 on Linux (Arial Black too far at the bottom)

and here on Chrome (11.0.696.65, also on Linux)
Attachment #530912 - Attachment mime type: text/plain → text/html
You need to log in before you can comment on or make changes to this bug.