Closed Bug 1702882 Opened 4 years ago Closed 4 years ago

Unicode curved arrow rendering has changed / broken

Categories

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

Firefox 87
Desktop
macOS
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: joshua.selsky, Unassigned)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

I am developing a site that uses ⤵ and ⤴ and in Firefox 87, the rendering of the curved arrows has been compacted. I don't know if this is a bug or a feature. The arrows render at their correct larger size in Safari and Chrome.

I am using the ⤴︎ trick to force platform-neutral rendering. E.g., <span>⤴︎</span>

Actual results:

Instead of the larger usual size, the arrows were compacted. Please see the attached image.

Expected results:

The arrows should have rendered normally.

Component: Untriaged → Layout: Text and Fonts
OS: Unspecified → macOS
Product: Firefox → Core
Hardware: Unspecified → Desktop

Presumably this depends on the font that is used. Could you point to the specific page, or attach a testcase that shows the styling you're using? You might need to explicitly specify the font you want to use for these symbols, otherwise you're at the mercy of whatever font fallback in the browser happens to find -- which is likely to differ between browsers and platforms.

Flags: needinfo?(joshua.selsky)

Thank you for the quick response.

I'm using IBM's Plex and the font data is served from my web server.

Here is a test case. It works "correctly" in Chrome. And the Chrome rendering is how FF used to render it prior to 87.0.

<!DOCTYPE HTML>
<html>
<head>
<title>test</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel = "stylesheet"
type = "text/css"
href = "https://fonts.googleapis.com/css?family=IBM+Plex+Sans" />
</head>
<style>
body {
margin: 0 auto;
font-family: IBM Plex Sans, serif;
font-size: 1.2em;
background-color: #fefefa;
}
.section-box-note {
font-size: .9em;
padding-left: 1.5em;
margin-bottom: .5em;
flex-grow: 0;
border-bottom: gray solid .25px;
}
</style>
<body>
<div class="section-box-note">
<p><span>⤵︎</span><span style="margin-left: .5em;">Also check</span></p>
</div>
</body>
</html>

Flags: needinfo?(joshua.selsky)

The issue here is that the character ⤵︎ U+2935 ARROW POINTING RIGHTWARDS THEN CURVING DOWNWARDS (and similar characters) is not supported by the IBM Plex Sans font you're explicitly loading; nor is it supported by the browser's default serif font (probably Times, unless you've modified the font preferences). So the browser ends up doing a "fallback" search to try and find some font that can display it, rather than showing you nothing (or an undefined-character "box"), but what font you get will depend on exactly how that search is handled, and what fonts happen to be available on the system.

What Firefox 86 ended up using was actually a Japanese font -- some of those include a large collection of miscellaneous symbols in addition to actual Japanese characters -- and in that font, the ⤵︎ glyph is quite large, basically filling the em square like a typical Japanese kanji glyph.

In Firefox 87, the font fallback code has been updated (rationalized somewhat, I would say!) to make such fallback font searches more consistent and efficient. (For the record, this was done in bug 1687622.) A result of this is that we're now finding these arrow characters in the Apple Symbols font. In general that seems logical; that's the font provided by the system for miscellaneous symbols like this, and there's nothing Japanese about this character or the context where it appears, so there's no real basis for picking a Japanese font to display it.

However, the glyph for U+2935 ⤵︎ in Apple Symbols is much smaller than in the Japanese fonts. That's what you're seeing here.

You can confirm this by explicitly including Apple Symbols in the font-family list; if you change it to font-family: IBM Plex Sans, Apple Symbols, serif; then the same small arrow will appear in Chrome as well.

(Or if you explicitly tag the content as being Japanese, by making it <span lang=ja>⤵︎</span>, then Firefox will revert to choosing the Japanese font that has the larger glyph, because this will result in serif being mapped to a Japanese font that includes the ⤵︎ character, and so a fallback search leading to Apple Symbols no longer happens.)

In conclusion, then: I don't think this is a bug, it's simply a result of leaving the font choice for the arrow character underspecified; it's not supported by IBM Plex Sans, and there's a good chance that the default serif font won't support it either, at which point you're basically rolling the dice and accepting whatever comes up. You can avoid this risk by explicitly choosing a symbol font with glyphs that suit your needs.

Rolling the dice is a good way to put it. I originally thought that using the HTML entity for the curved arrow glyph was a safe way to go but it turns out that it is rather brittle. Thanks for allowing me to rubber-duck my design then! At least there is another test case attached to the original FF enhancement.

It would be nice if there was a standard set of glyphs all browsers could bundle and use when an HTML entity for a "non-text symbol" is explicitly referenced, but I am sure there are tradeoffs there and it might be surprising to users of custom fonts if one of the default glyphs appeared when they desired, or more importantly, specified, a custom font like I am doing. From that perspective the change definitely seems more rational.

FWIW, the larger rendering is also the default on iOS Chrome, FF Focus and Brave. I have not tested Windows or Linux or Android yet and based on this discussion I'm sure that's where the brittleness will really show.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

Yes; I'm not sure offhand what you'll see on Windows, but on Linux there's a good chance (depending on the specific distro and its font choices) you'll encounter something like DejaVu Serif as the serif font, which again has a smaller version of the curved arrows; or perhaps you'll get Symbola as a fallback, which also has a small glyph.

The "large" size that you were hoping for seems to be characteristic of Japanese/Chinese fonts, but outside of those it's more likely you'll get a small/medium-sized glyph more like the Apple Symbols one. Indeed, checking the Unicode chart at https://www.unicode.org/charts/PDF/U2900.pdf shows a representative glyph that is definitely well short of filling the em square.

Using the Unicode character (or equivalently the HTML entity) is indeed a simple and robust way to get the symbol (provided the system has any kind of support for it), but does not in itself give you precise control of the appearance. If the exact look is important, I think your options are either to explicitly provide a font that you know has the glyph you want, or use a different technique such as an SVG icon.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: