Open
Bug 1029327
Opened 10 years ago
Updated 2 years ago
Font Problems rendering fonts to canvas using ctx.fillText
Categories
(Core :: Graphics: Text, defect)
Tracking
()
NEW
People
(Reporter: eclipsechasers2, Unassigned)
References
Details
Attachments
(3 files)
Snip of Google Sheets as seen in Firefox
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243
Steps to reproduce:
1. View spreadsheet uploaded to Google sheets:
https://docs.google.com/spreadsheets/d/1BLfoDcHTq7bXjNUGHD9dGRfY9AS4JHAJEhc48SEPMa8/edit#gid=487641178
2. View same spreadsheet uploaded with old Google Docs spreadsheet interface:
https://docs.google.com/spreadsheet/ccc?key=0AmBbEu7mnIGDdC1ybTUyUGh4d2Z5OGw4SjZnbEFxRVE#gid=0
Actual results:
New interface - things look okay on Chrome and IE. Some fonts rendered terribly in Firefox. Easiest to notice are Arial Black and Lucida Sans Typewriter, which are written across cell boundaries. However, the most important problem is with Calibri, Excel's default font. It appears bold and condensed, neither of which is desirable. The same is true for Cambria, Consolas (all 3 are on my system), and fonts not on my system (e.g. Hoefler Text).
Old interface - things look okay (with suitable default fonts substituted for fonts missing from system) on Firefox (and Chrome and IE).
This is all on Windows 7. If it matters, my Firefox default font is Arial 16-point.
Expected results:
Font rendering should make Google Sheets version look like Google docs version, and like Google sheets in Chrome and IE.
|
||
Comment 1•10 years ago
|
||
It looks like new google spreadsheets uses a canvas drawing library instead of a normal HTML table to draw its text onto. This makes it really hard to figure out why the fonts aren't drawn correctly. It would be best if there was something of a more reduced testcase. At a guess, this would be related to canvas' font metrics APIs...
(NB: I don't see the issues you're describing on OS X, although there are other rendering differences - I don't know enough about the fonts in question to know which rendering is 'right')
|
Reporter | |
Comment 2•10 years ago
|
||
This is a capture using the Windows "snipping tool" of the Google Sheets spreadsheet as viewed in Firefox.
|
|
Reporter | |
Comment 3•10 years ago
|
||
This is a capture of the Google Sheets spreadsheet as viewed in IE. This capture is essentially the same as what I see in Chrome, and also what I see if I upload the spreadsheet, using the old Google docs interface, in all of Firefox, IE, and Chrome.
|
|
Reporter | |
Comment 4•10 years ago
|
||
I will be glad to create a smaller test case if need be. I was only going to file the bug about Calibri, the default font. However, I first investigated a Google Sheets add-on called "More Fonts" which supports other fonts to see if it fixed the problem. It didn't, but, since the problem showed up so much more clearly for Arial Black (as you can see in the snips), I decided to expand what I was reporting.
In the FF snip, note that all of Calibri, Cambria, and Big Caslon appear to be bold. The first 2 are on my system; Big Caslon is not (and appears to be using the same font as Cambria, which appears to be a generic default font used by several other fonts not on my system but on my spreadsheet).
|
|
Reporter | |
Comment 5•10 years ago
|
||
FWIW, when I viewed the problematic spreadsheet on an old Linux system (FF26 on Ubuntu 12.04), the Calibri problem did not appear, although the Arial Black problem did. Also, because I tried that on a slow connection, I noticed that the spreadsheet was initially displayed correctly, then a "working" pop-up (of sorts) appeared, after which the sheet was erroneously formatted. Trying this same connection on Windows showed the same thing. That same pop-up does appear with the other browsers, but the reformat is harmless for them.
|
||
Comment 6•10 years ago
|
||
Confirmed on Windows 7 64bit Firefox 30
|
|
||
Updated•10 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here is a simple test case:
<!DOCTYPE html>
<html>
<body>
<span style='font-family:Arial; font-size:11pt'>
Normal text: abcABC
</span>
<br/>
<canvas id="myCanvas" width="*" height="20"/>
<script>
var c = document.getElementById("myCanvas");
var ctx = c.getContext("2d");
ctx.font = "11pt Arial";
ctx.fillText("Canvas text: abcABC",0,20);
</script>
</body>
</html>
|
|
||
Comment 8•10 years ago
|
||
Jonathan, are you the right person to ask where this issue belongs and/or what we can do to fix it? :-)
(not sure if this is a canvas or a font issue...)
(In reply to mik from comment #7)
> Here is a simple test case:
> <snip>
This is helpful - but at least on my mac, while the rendered text looks different from the text in the span, it looks identical on e.g. Google Chrome (on my retina mac, with Firefox 32, at least). I'm not sure if this is the same issue that's manifesting on Google Sheets...
Component: Untriaged → Graphics: Text
Flags: needinfo?(jfkthame)
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86_64 → All
Summary: Font Problems with Google Sheets → Font Problems rendering fonts to canvas using ctx.fillText
|
||
Comment 9•10 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #8)
> Jonathan, are you the right person to ask where this issue belongs and/or
> what we can do to fix it? :-)
>
> (not sure if this is a canvas or a font issue...)
>
The basic problem is that canvas and HTML do not render text identically - either in terms of appearance or metrics - and this is unlikely to get "fixed", given that canvas is (by default, at least, unless you mess with scaling etc) rendering text to a bitmap with CSS-pixel resolution, whereas HTML text renders at the screen's device-pixel resolution, which may be significantly different.
If you select one of the spreadsheet cells and then double-click to get an insertion point and edit the contents, you get an HTML element where the text rendering often looks significantly better - but may also be substantially different. In many cases, it shifts upwards a bit compared to the "background" canvas rendering, though occasionally it may shift down; and the glyph spacing is often slightly different, too. These effects can also be seen in Chrome or IE, though they're generally more subtle; Firefox seems to have the more severe mismatch between HTML text and canvas text.
Comparing the rendering of the actual glyphs, the canvas text does not use subpixel antialiasing (cleartype), whereas the HTML rendering does, and so this significantly affects the appearance. Firefox also seems to use quite different glyph hinting for the two environments; indeed, with some fonts we're even getting aliased (un-smoothed) glyphs in canvas. In contrast, with Chrome the canvas and HTML glyphs look as though they've been hinted the same (or very similarly), though the canvas version is rendered in grayscale only.
A reduced (understandable!) testcase that exhibits the Arial Black positioning discrepancy would be interesting; I don't know how the Google sheet is going about its text measurement and drawing for the canvas, but it looks like it's getting inappropriate metrics somehow.
cc'ing some graphics people who may know more about how we render and composite stuff, as I think that's what leads to text (in particular, antialiasing) looking so different between the two contexts.
Flags: needinfo?(jfkthame)
|
||
Comment 10•10 years ago
|
||
A testcase for hanging Arial Black (both texts should have the same vertical position):
<!DOCTYPE html>
<html>
<body>
<canvas id="myCanvas" style="border:black;"/>
<script>
var c = document.getElementById("myCanvas");
var ctx = c.getContext("2d");
ctx.textBaseline = "top";
ctx.font = "11pt Arial";
ctx.fillText("Arial",0,0);
ctx.font = "11pt Arial Black";
ctx.fillText("Arial Black",30,0);
</script>
</body>
</html>
|
|
||
Comment 11•10 years ago
|
||
Ah, I see ... this is dependent on the use of textBaseline="top". So the Google spreadsheet rendering is presumably using that, too. I wonder why they didn't use the default "alphabetic" baseline, to make it easier to align text in different fonts with potentially differing vertical metrics.
In general, you can NOT expect that text in different fonts will align nicely (at the baseline) if using textBaseline="top", as this will depend on the ascent and descent of the fonts. And indeed, comparing Arial and Arial Black, I notice that the faces do have different metrics.
As for why Arial Black is so drastically misaligned -- worse than one might reasonably expect due to variations between the ascent/descent of different faces -- I think this is because the version of Arial Black shipped with Windows has a bug in the "typographic metrics" fields of the 'OS/2' table.
Dumping the OS/2 table from arial.ttf (regular face), we see
<sTypoAscender value="1491"/>
<sTypoDescender value="-431"/>
<sTypoLineGap value="307"/>
but in ariblk.ttf (Arial Black), the corresponding fields are
<sTypoAscender value="1466"/>
<sTypoDescender value="434"/>
<sTypoLineGap value="291"/>
Note the sign of the sTypoDescender field! That's wrong, and I suspect that is the primary cause of the "mis-positioned" Arial Black text, as it's messing up our font metrics and line spacing calculations.
|
|
||
Comment 12•10 years ago
|
||
There is already a bug for canvas text problems in Windows:
https://bugzilla.mozilla.org/show_bug.cgi?id=890733
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•