Firefox renders oversized Unicode 'ballot box with a cross' character (☒)
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: tony.seebregts, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
Open a web page with the Unicode 'ballot box with check' and 'ballot box with cross' characters (☑ and ☒ respectively). e.g.:
- https://www.unicodepedia.com/unicode/miscellaneous-symbols/2611/ballot-box-with-check
- https://www.unicodepedia.com/unicode/miscellaneous-symbols/2612/ballot-box-with-x
Consistently reproducible with the following minimal HTML:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>ballot-with-cross bug sample</title>
<meta charset="UTF-8">
</head>
<body>
<span>☑</span>
<span>☒</span>
</body>
</html>
Actual results:
The 'ballot box with cross' is rendered significantly larger than the 'ballot box with check' (and also significantly larger than other characters).
Expected results:
'ballot box with cross' should be rendered a similar size to 'ballot box with check'.
Additional information:
- Chrome renders both characters the same size
- Safari renders a larger 'ballot box with cross' character
Reporter | ||
Comment 1•3 years ago
|
||
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
This is a question of font selection: different fonts may render these glyphs (or any others) at varying visual sizes within any given font-size. Because these characters are probably not supported by the default text fonts (e.g. Times Roman), the browser has to find a fallback font to display them. If it chooses different fallback fonts for the two characters, they're unlikely to match well.
In my particular case (results may vary, depending on OS version and installed fonts), it looks like ☒ gets rendered using the STIXGeneral font, which we try as a fallback as it supports a lot of the Unicode symbol characters; but as it happens, ☑ is not available in STIXGeneral, and we end up rendering it with Apple Symbols instead. Overall, the glyphs in Apple Symbols tend to be designed at a smaller size than in STIXGeneral; hence the result we see here.
To ensure symbols like this are displayed more consistently, the author should explicitly include a font that includes the characters in the font-family
list, rather than leaving it to the (potentially unpredictable) browser font fallback.
Reporter | ||
Comment 4•3 years ago
|
||
Thanks for the detailed explanation!
It appears Apple also uses STIXGeneral with Apple Symbols as a fallback which explains why Safari has the same problem (and sadly the latest version of STIX Two has ballot box
, ballot box with check
but not ballot box with cross
).
Please feel free to close this.
Comment 5•3 years ago
|
||
Curiously, I'm not seeing the same thing in Safari (on macOS 12.0 beta) -- it seems to be using Apple Symbols for both ☒ and ☑. This is probably a system/browser version difference.
Anyhow, the basic point remains: when there are characters present that aren't supported by the specified (or default) fonts, the browser will attempt to find some other font to display them; the result may not always look very good, because of mismatches between the mixture of fonts that end up getting used.
Closing as Invalid, as there's not really a Firefox bug here; it's just the somewhat erratic results that can happen from (inadvertently) mixing fonts in an unplanned fashion.
Description
•