1757081 - tight kerning for characters rendering on Canvas in Google Sheets

Status: RESOLVED DUPLICATE of bug 1919906

(Core :: Graphics: Canvas2D, defect, P3)

Description

[Karl Dubost💡 :karlcow]

[Tracking Requested - why for this release]:
This has happened for a while already, and its not a breaking behavior, but given this is Google Sheets with a lot of users from a Webcompat priority point of view this is important, but not critical.

0. With Firefox on Windows
1. Go to https://docs.google.com
2. Open a blank sheet.
3. In a cell type "8x version of »

Expected:
Character spacing is good

Actual:
Character spacing is tight

Note:
https://github.com/webcompat/web-bugs/issues/94457
This doesn’t happen on macOS.
This doesn’t happen on Chrome.

Note Google has been contacted already and suspected this is on Firefox side and text rendering in Canvas.

Comment 1

[Karl Dubost💡 :karlcow]

Probably having a test case that would reproduce the issue outside of Google Sheets would help here.

Comment 2

[Karl Dubost💡 :karlcow]

Attachment: test to reproduce the issue

This is an attempt at a test case, but that would require someone with windows to test.
Oana,
could you double check on windows if it's reproducing the issue? Comparing Chrome and Firefox rendering.

Comment 3

[Oana Arbuzov [:oanaarbuzov]]

The issue still occurs on my side.

Tested with:
Browser / Version: Firefox Nightly 99.0a1 (2022-02-27)
Operating System: Windows 10 Pro

Comment 4

[Oana Arbuzov [:oanaarbuzov]]

Attachment: FFvsCh_Spacing.png

Comment 5

[Karl Dubost💡 :karlcow]

So after checking with Oana, my test case doesn't reproduce the issue on windows. Need to create a better test case.

Comment 6

[Ashley Hale [:ahale]]

This came up on gfx bug triage meeting, I can repro the issue and others can as well. It looks to me like the / characters in the string "8/5/21" are one pixel to the left of where it should be, but the placement of the other characters looks the same to me, so I'm not sure if this precisely falls into the concept of a kerning issue because the overall string width is unchanged. Only the rendered cells of the sheet are affected, the edit box above the sheet is correctly spaced.

Comment 7

[Jonathan Kew [:jfkthame]]

In the original screenshot here, I think the more obvious issue is the cells containing "8x version of", where the glyph spacing looks too tight. It feels like what might happen if the glyphs are being measured and rendered with different modes (hinted vs unhinted, GDI-compatible vs "natural", etc). However, I'm not seeing this at all with current Nightly on my Windows machine; entering the same text, with the same Arial 10 font, it looks fine here.

Comment 8

[Ashley Hale [:ahale]]

Per gfx-triage meeting, I'll try to figure out the repro for this and confirm it's still happening with :jfkthame, this definitely looks like something that would deeply bother some significant number of users when using Google Sheets which is a popular app.

Comment 9

[Brad Werth [:bradwerth] | Out until March 3]

I'll take this on.

Comment 10

[Bob Hood [:bhood]]

Karl, looking back through the history, we seem to have a problem reproducing this issue. Is it still happening for you with the most current Nightly (Fx120)?

Lacking reliable STR, I'm flagging this as stalled.

Comment 11

[Karl Dubost💡 :karlcow]

In the past this is what Google replied when contacted. It was in February 2022. If there was a followup, you should ask someone from the Moz webcompat team (I'm not part of Mozilla anymore).

We took a look at the reported issue, and believe the unexpected character spacing is due to how Firefox on Windows handles text rendering on canvas in general and is not specific to Google Sheets.

This JsFiddle demonstrates rendering the same text using HTML and Canvas. We notice that on most browser/platform combinations, the HTML and canvas text are rendered very similarly, whereas on Firefox Windows, the canvas rendering is noticeably different and shows the incorrect character spacing.

There has been some discussion about Firefox Windows' handling of canvas text rendering, and its impact on Sheets, in the past (Bugzilla/890733). Recently, a Firefox change was submitted which did improve the situation in some cases (Bugzilla/1730772) but it looks like there are still some room for improvement. Ideally, rendering text to Canvas would produce the same quality results as rendering that same text to HTML. This seems to be the case on most platforms but I don't know how feasible that is in practice here.

Comment 12

[Brad Werth [:bradwerth] | Out until March 3]

Lee, is this something we can correct in our Canvas text drawing?

Comment 13

[James Graham [:jgraham]]

Based on current prioritization, I don't think this is a Webcompat P1; let's re-triage.

Comment 14

[Dennis Schubert [:denschub]]

We haven't seen a breakage report about this in a while. Let's unset the webcompat-priority flag for now, we can increase the priority if we get reports again.

Comment 15

[MzB]

Attachment: Incorrect kerning in Firefox 115.9.1 on Windows 10

Bug #1757081

Comment 16

[MzB]

Comment on attachment 9394938 [details]
Incorrect kerning in Firefox 115.9.1 on Windows 10

This is an example of overly tight kerning which affects Firefox 115.9.1 running on Windows 10.
The effect is exacerbated in footnotes.

Comment 17

[Daniel Holbert [:dholbert]]

Attachment: screenshot (131 release on left, 133 nightly on right)

I'm pretty sure this is fixed in Nightly by bug 1919906. (I just noticed that similar-ish bug 1769326 was fixed by bug 1919906 and verified the fix-range via mozregression).

In this bug here, I just did a quick spot-check of current Firefox release 131.0.3 which reproduces the bug, vs. current Nightly 133.0a1 (2024-10-21) which does not. Here's a screenshot to demonstrate that comparison.

Comment 19

[Daniel Holbert [:dholbert]]

Attachment: screenshot with text from comment 0 (131 release on left, 133 nightly on right)

For completeness, here's a similar screenshot with the sample-text from comment 0 here.

Comment 20

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.