Closed Bug 1607672 Opened 4 years ago Closed 4 years ago

[mac] Combination of unicode flower symbols displays profile names half-height for ✿❀✾❀✿ / improper glyphicons

Categories

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

All
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla74
Tracking Status
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- verified

People

(Reporter: cfogel, Assigned: jfkthame)

Details

Attachments

(2 files)

Note

Affected versions

  • 73.0b2, 72.0, 74.0a1 (2020-01-07)

Affected platforms

  • macOS 10.12, macOS 10.15

Steps to reproduce

  1. Launch Firefox profile manager;
  2. Input ✿❀✾❀✿ as profile name;

Expected result

  • all glyphicon for the characters are properly displayed;

Actual result

  • height and glyphicon differs;

Regression range

  • will provide one asap;

Additional notes

  • attached screenshot with the issue, to the left it's the profile manager and in the right it's a screenshot from the about:profiles page;
  • moving ✾ around appears to "reset" to the expected glyph ussage;

Given that the symbols also display the same way in the bug report I suspect this is a font or rendering issue.

Component: Startup and Profile System → Layout: Text and Fonts
Product: Toolkit → Core

It appears you might be right, in an attempt to get a regression range tried with older builds and had the same result.
Thanks for the redirect.

This isn't really a bug, it's just a result of how font fallback works. The "flower" symbols aren't available in the default font being used, and so the browser looks for a fallback. In Firefox on macOS, I'm getting a Japanese font (Hiragino Kaku Gothic ProN) for the first couple of symbols "✿❀"; but then it doesn't support the "✾" character, and that falls back to Menlo, which has significantly smaller glyphs for the same nominal point-size.

Moving the "✾" to the beginning of the string affects the following glyphs because when fallback is occurring, we try to maintain the same font for successive characters where possible. So once Menlo has been chosen for "✾", we try it as the first fallback option for a following "✿", and end up with Menlo for all five of the symbols. When "✿" was the first character, font fallback didn't have a "previous character's fallback" to guide its choice, and ended up picking the Hiragino font, which in isolation was a reasonable choice.

What would help here, I suspect, is to add Zapf Dingbats to the "common fallback fonts" on macOS for the Dingbats block in Unicode, as that's more likely to support all the dingbats in a consistent style; the CJK fonts, although they have wide character coverage, tend to be less complete/consistent in coverage of specific blocks like this.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6d8acea22d1d
Improve font fallback for Dingbats block on macOS. r=lsalzman
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74

Fix verified with 74.0a1(2020-01-15).
Good job on this! :D

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.