1692791 - Canvas.measureText returns wrong actualBoundingBox values for colored glyphs

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Karl Kraus]

Attachment: measureTextRectBug.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Html file in the attachment:

• Render isolated colored unicode glyphs using context.fillText()
• Measure the same text using context.measureText() and render/print the resulting actualBoundingBox values

Actual results:

• The actualBoundingBox values of colored glyphs are inconsistent with the actualBoundingBox values of black&white glyphs. This prevents drawing a correct bounding box around the glyph.
• The difference between ascent/descent (even when flipping signs) is only about half the glyph height for colored glyphs.

Expected results:

• All actualBoundingBox values should have consistent values to easily allow drawing the bounding box.
• The ascent/descent values for colored glyphs should be usable without scaling/guesswork.

Comment 1

[Karl Kraus]

Attachment: measureTextGood.png

Comment 2

[Karl Kraus]

Attachment: measureTextBad.png

Comment 3

[Karl Kraus]

This bug might have solved a similar issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1646926

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Canvas: 2D' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 5

[Sotaro Ikeda [:sotaro]]

:jfkthame, can you comment to the bug?

Comment 6

[Jonathan Kew [:jfkthame]]

I guess this means we're failing to get bounding boxes at all for bitmapped glyphs on Linux. This might be an internal FreeType issue, or maybe a problem with how we're using its API.

(On macOS it seems to work reasonably well - the bounding box doesn't exactly match the image but it's fairly close - and on Windows the emoji font uses outlines, not bitmaps, so probably won't be an issue there.)

Comment 8

[Teal Dulcet [:tdulcet] (TB Council)]

Attachment: measureText Twemoji Mozilla.html

(In reply to Jonathan Kew [:jfkthame] from comment #6)

and on Windows the emoji font uses outlines, not bitmaps, so probably won't be an issue there.)

It is an issue on Windows for any emojis that use the "Twemoji Mozilla" fallback font bundled with Firefox (Bug 1714632). Windows does not currently implement any of the flag emojis, so all of them are affected, as well as any of newer emojis (up to Unicode 13.0) for users on older systems that do not support them natively.

On both Windows and Linux when the fallback font is in use, the emojis are also off center (too high), which is not reflected by the TextMetrics properties.

I added two new columns to Karl's demo (see attached), which show the results when forcing the "Twemoji Mozilla" fallback font.

Comment 9

[Teal Dulcet [:tdulcet] (TB Council)]

Attachment: measureText Twemoji Mozilla.html

Karl's demo in comment 0 marks any symbols/emojis with negative actualBoundingBox values as bad. I updated it again to test all 4,733 emojis in the Unicode 15.0 (see attached) and for a few (namely 🕳, 🏎️, 👓, 🕶️, 🥿and ™️) it seems either the ascent or descent value is supposed to be negative, as they are when testing the updated demo in Chrome. However, for the vast majority of the emojis (4,725 of the 4,733 or over 99.8%), these values should always be positive.

When using the "Twemoji Mozilla" fallback font, I also noticed that for some emojis that include the zero-width joiner or a skin tone modifier character, the left and right actualBoundingBox values are both zero, which makes the bounding box a straight line.

The issue I mentioned in comment 8 with the flag emojis on Windows seems to be a regression, as it does not occur in Firefox 91 ESR. I would be happy to attach screenshots if that would be helpful for anyone.

Comment 10

[Teal Dulcet [:tdulcet] (TB Council)]

Attachment: measureText Bug 1692791.html

Now that it has been a full year since I last updated the demo, I updated it again to test all 5,034 emojis (both fully-qualified and minimally-qualified) in Unicode 15.1 (see attached). I also added two columns for the "EmojiOne Color" font for comparison, which seems to be installed on many systems.

Other than the known issues with the "EmojiOne Color" font (e.g. bug 1752881), it seems to produce the expected bounding box values. However, for the "Twemoji Mozilla" font, it produces incorrect bounding box values for 5,004 of the 5,034 emojis on both Windows and Linux. Those 30 emojis that are correct are from Unicode 15.0 and not yet supported by Twemoji (bug 1796880 and bug 1824298).

(Note that the performance of this demo on Windows seems to have regressed over time, which cannot be fully explained by the ~300 additional emojis. It now takes over 2 minutes to fully load in Firefox on Windows, whereas in Firefox on Linux and in Chrome it only takes a few seconds. Here is a profile if someone wants to investigate: https://share.firefox.dev/3ZQOlap.)